Thanks guys. Sorry for the noise...
Derek
On 9/26/2012 9:11 PM, Jay Ashworth wrote:
- Original Message -
From: "Derek Ivey"
I'm at home now. I also have Verizon FiOS and believe I am seeing the
same thing our client saw. So you guys are saying that the response
times in traceroutes mi
- Original Message -
> From: "Derek Ivey"
> I'm at home now. I also have Verizon FiOS and believe I am seeing the
> same thing our client saw. So you guys are saying that the response
> times in traceroutes might not always be accurate because routers
> prioritize ICMP messages. Does that
I'm at home now. I also have Verizon FiOS and believe I am seeing the
same thing our client saw. So you guys are saying that the response
times in traceroutes might not always be accurate because routers
prioritize ICMP messages. Does that mean values from MTR aren't
accurate? I fired up MTR an
On 09/25/2012 7:11 pm, Bryan Seitz wrote:
Recently began seeing things like this to the default GW from
inside and outside the FIOS network. Called tech support but all
they
could do was put a ticket in for the NetEng team.
http://pastie.org/4800421
http://www.bsd-unix.net/smokeping/smoke
That router might be experiencing a high CPU load, thus not being able
to reply ICMP on a timely manner or maybe QoS policies are influencing
depending on the kind of traffic the router deals with.
If packets are only being delayed/lost on that segment, I would start my
analysis there.
On 0
That router might be experiencing a high CPU load, thus not being able
to reply ICMP on a timely manner or maybe QoS policies are influencing
depending on the kind of traffic the router deals with.
If packets are only being delayed/lost on that segment, I would start my
analysis there.
On 09
Many (most?) routers deprioritize ICMP meesages. Direct pings against the
router are not informative re transit failures.
On Sep 26, 2012, at 11:37 AM, Derek Ivey wrote:
> After some further troubleshooting, I believe I have narrowed down the issue
> to one of Verizon's routers (130.81.28.255).
After some further troubleshooting, I believe I have narrowed down the issue to
one of Verizon's routers (130.81.28.255).
ping 130.81.28.255 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 130.81.28.255, timeout is 2 seconds:
??!!!??!!
- Original Message -
> From: "Peter J. Cherny"
> I've (re)sent this to the list as no-one else has noted it
>
> Possibly a game-changer in the (academic) 802.1x space ...
> http://www.project-moonshot.org/diary
> http://www.painless-security.com/blog/
I did see that come in, and was go
Thanks guys. That was an informative read. I will do some more troubleshooting.
Derek
On Sep 26, 2012, at 1:16 PM, Darius Jahandarie wrote:
> On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap wrote:
>> This is not the proper way to interpret traceroute information. Also, 3
>> pings is not sufficie
On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap wrote:
> This is not the proper way to interpret traceroute information. Also, 3
> pings is not sufficient to determine levels of packet loss statistically.
>
> I suggest searching the archives regarding traceroute, or googling how to
> interpret them
This is not the proper way to interpret traceroute information. Also, 3
pings is not sufficient to determine levels of packet loss statistically.
I suggest searching the archives regarding traceroute, or googling how to
interpret them in regards to packet loss, as what you posted does not
indicate
Hi guys,
We host a web application for a client and they've been complaining that it's
been slow since yesterday. It seems fast from the locations I've tested and the
system looks fine, so I suspected there was packet loss going on somewhere
between them and our colo facility.
I did a few tra
The ITU recommend the following levels:
5,6,7 = Customer
3,4 = Provider
1,2 = Operator
0= Local segment
I don't know if there are any rules of thumb for the CCM interval - faster is
more sensitive & unstable, slow is sluggish but stable. The spec allows between
3.33 ms and 10 minutes in 7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco Catalyst 4500E Series Switch with Cisco Catalyst Supervisor Engine 7L-E
Denial of Service Vulnerability
Advisory ID: cisco-sa-20120926-ecc
Revision 1.0
For Public Release 2012 September 26 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software DHCP Denial of Service Vulnerability
Advisory ID: cisco-sa-20120926-dhcp
Revision 1.0
For Public Release 2012 September 26 16:00 UTC (GMT)
+-
Summary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software DHCP Version 6 Server Denial of Service Vulnerability
Advisory ID: cisco-sa-20120926-dhcpv6
Revision 1.0
For Public Release 2012 September 26 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Network Address Translation Vulnerabilities
Advisory ID: cisco-sa-20120926-nat
Revision 1.0
For Public Release 2012 September 26 16:00 UTC (GMT)
+-
Summary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Malformed Border Gateway Protocol Attribute Vulnerability
Advisory ID: cisco-sa-20120926-bgp
Revision 1.0
For Public Release 2012 September 26 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Tunneled Traffic Queue Wedge Vulnerability
Advisory ID: cisco-sa-20120926-c10k-tunnels
Revision 1.0
For Public Release 2012 September 26 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Intrusion Prevention System Denial of Service Vulnerability
Advisory ID: cisco-sa-20120926-ios-ips
Revision 1.0
For Public Release 2012 September 26 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability
Advisory ID: cisco-sa-20120926-sip
Revision 1.0
For Public Release 2012 September 26 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco Unified Communications Manager Session Initiation Protocol Denial of
Service Vulnerability
Advisory ID: cisco-sa-20120926-cucm
Revision 1.0
For Public Release 2012 September 26 16:00 UTC (GMT
> Date: Wed, 26 Sep 2012 14:46:04 +0200
> From: Sebastian Wiesinger
> To: NANOG
> Subject: What are qatesttwai.gov/fttesttwai.gov?
>
'TWAI' is the U.S. gov't reasury eb pplications nfrastructre,
run by the Federal Reerve, for a number of secure Treasury-wide application.
Parallel production and
Hello,
my resolver running on a dedicated server is warning about DNSSEC
validation failure for these two .gov domains 7 minutes after every
full hour:
Sep 26 13:07:04 alita unbound: [28931:0] info: validation failure
: no keys have a DS with algorithm
RSASHA1-NSEC3-SHA1 from 199.169.196.64 for k
Hi
Are there any best common practices for the CFM levels use
Since my pure Ethernet aggregation layers are small I believe I only need
two CFM levels
I plan on using Level 5 between CPEs managed by us and Level 4 between
Aggregation devices -that's where MPLS PWs kicks in
So leaving Level 7 and L
I've (re)sent this to the list as no-one else has noted it
Possibly a game-changer in the (academic) 802.1x space ...
http://www.project-moonshot.org/diary
http://www.painless-security.com/blog/
That is quite impressive that 5,000 orgs got 802.1x working correctly
in this fashion.
I had a lot of questions how they handled auth, but it appears auth is
distributed according to a roaming user's realm/domain suffix.
https://confluence.terena.org/display/H2eduroam/How+to+deploy+eduroam+on-site
On Tue, 25 Sep 2012, valdis.kletni...@vt.edu wrote:
On Wed, 26 Sep 2012 00:37:38 +0200, Carsten Bormann said:
The entirety of eduroam is on 802.1X (better known as WPA Enterprise).
That must be an 8-digit number of users.
If you need a list of sites, start with http://en.wikipedia.org/wiki/E
29 matches
Mail list logo
