Re: POLL: 802.1x deployment
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/Eduroam However, that would be more a confederation of deployments than one single large deployment. But each participating institution (more than 5000 universities and research centres) deployed 802.1x in their premises. Big bonus that they work together seamlessly (inter organisation roaming and 802.1x usage). Have look at the official homepage of eduroam: http://www.eduroam.org/ Best Regards, Janos Mohacsi
Re: POLL: 802.1x deployment
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+or+on+campus Fairly decent wiki on their site, bet others would find this helpful for non-eduroam dot1x On Wed, Sep 26, 2012 at 12:27 AM, Mohacsi Janos moha...@niif.hu wrote: 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/Eduroam However, that would be more a confederation of deployments than one single large deployment. But each participating institution (more than 5000 universities and research centres) deployed 802.1x in their premises. Big bonus that they work together seamlessly (inter organisation roaming and 802.1x usage). Have look at the official homepage of eduroam: http://www.eduroam.org/ Best Regards, Janos Mohacsi -- Brent Jones br...@brentrjones.com
Re: POLL: 802.1x deployment
I've (re)sent this to the list as no-one else has noted it g Possibly a game-changer in the (academic) 802.1x space ... http://www.project-moonshot.org/diary http://www.painless-security.com/blog/
Ethernet OAM BCPs Please are there any yet???
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 Level 6 for customers and carrier-customers respectfully -would this be enough please? I'm also interested on what's the rule of thumb for CCMs Frequency, Number of Packets, Interpacket Interval, Packet Size and Lifetime for the particular operation Thanks a lot for any inputs adam
What are qatesttwai.gov/fttesttwai.gov?
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 qatesttwai.gov. NS IN: no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 199.169.196.64 for key qatesttwai.gov. while building chain of trust Sep 26 13:07:04 alita unbound: [28931:0] info: validation failure fttesttwai.gov. NS IN: no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 199.169.196.64 for key fttesttwai.gov. while building chain of trust Does anyone know what these are? There are placeholder https sites at these hosts but nothing else. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: What are qatesttwai.gov/fttesttwai.gov?
Date: Wed, 26 Sep 2012 14:46:04 +0200 From: Sebastian Wiesinger na...@ml.karotte.org To: NANOG nanog@nanog.org Subject: What are qatesttwai.gov/fttesttwai.gov? 'TWAI' is the U.S. gov't Treasury Web Applications Infrastructre, run by the Federal Reerve, for a number of secure Treasury-wide application. Parallel production and 'test' environments. looks like these are parts of the 'test' environment. z
Cisco Security Advisory: Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerability
-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) +- Summary === Cisco Unified Communications Manager contains a vulnerability in its Session Initiation Protocol (SIP) implementation that could allow an unauthenticated, remote attacker to cause a critical service to fail, which could interrupt voice services. Affected devices must be configured to process SIP messages for this vulnerability to be exploitable. Cisco has released free software updates that address this vulnerability. A workaround exists for customers who do not require SIP in their environment. This advisory is available at: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-cucm Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html Cisco IOS Software and Cisco IOS XE Software are affected by the vulnerability described in this advisory. A separate Cisco Security Advisory has been published to disclose the vulnerability that affects Cisco IOS Software and Cisco IOS XE Software at the following location: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-sip -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgiVQACgkQUddfH3/BbTqDrAD9GKw11Pk/9nwMJBzSQ7znHH8u JzDBtraEHMNDkyEacLAA/2ZbaNvWDOhuly4XCs84hvZhUtxnaHFCNheFGI3Go8nj =0fGN -END PGP SIGNATURE-
Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability
-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) +- Summary === A vulnerability exists in the Session Initiation Protocol (SIP) implementation in Cisco IOS Software and Cisco IOS XE Software that could allow an unauthenticated, remote attacker to cause an affected device to reload. Affected devices must be configured to process SIP messages and for pass-through of Session Description Protocol (SDP) for this vulnerability to be exploitable. Cisco has released free software updates that address this vulnerability. There are no workarounds for devices that must run SIP; however, mitigations are available to limit exposure to the vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-sip Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html Cisco Unified Communications Manager is affected by the vulnerability described in this advisory. A separate Cisco Security Advisory has been published to disclose the vulnerability that affects the Cisco Unified Communications Manager at the following location: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-cucm -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeEAACgkQUddfH3/BbTob/wD/Qp0Y5YKNdLu4RUcBgkHojBc+ EQQQyJVSQTrHNG6GJcoA/jXiO1Lic8HzNUQdmusjvD+dIdKjQd8GrMOwAhKOQWpU =vIHn -END PGP SIGNATURE-
Cisco Security Advisory: Cisco IOS Software Intrusion Prevention System Denial of Service Vulnerability
-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) +- Summary === Cisco IOS Software contains a vulnerability in the Intrusion Prevention System (IPS) feature that could allow an unauthenticated, remote attacker to cause a reload of an affected device if specific Cisco IOS IPS configurations exist. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-ios-ips Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD8ACgkQUddfH3/BbTpJqQD+IN51ZWVrBuSFzCEOb3hRHC+o i093jjXqPMmZ90pvT8wA/2LNuyuDuc7hat0gxy02+ZQbwKfDwaFFsJQ7UnV3WQf/ =QlOw -END PGP SIGNATURE-
Cisco Security Advisory: Cisco IOS Software Tunneled Traffic Queue Wedge Vulnerability
-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) +- Summary === Cisco IOS Software contains a queue wedge vulnerability that can be triggered when processing IP tunneled packets. Only Cisco IOS Software running on the Cisco 1 Series router has been demonstrated to be affected. Successful exploitation of this vulnerability may prevent traffic from transiting the affected interfaces. Cisco has released free software updates that addresses this vulnerability. There are no workarounds for this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-c10k-tunnels Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD4ACgkQUddfH3/BbTpLigD/fKng67LLI/XQ0AkD8l6YyPct /hYpJdygEEIqvm2htS8BAIGs1zHnI0iD1w9RTmKc+uaeopmfO8F7qsutxUFX4KhJ =cGGl -END PGP SIGNATURE-
Cisco Security Advisory: Cisco IOS Software Malformed Border Gateway Protocol Attribute Vulnerability
-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) +- Summary === Cisco IOS Software contains a vulnerability in the Border Gateway Protocol (BGP) routing protocol feature. The vulnerability can be triggered when the router receives a malformed attribute from a peer on an existing BGP session. Successful exploitation of this vulnerability can cause all BGP sessions to reset. Repeated exploitation may result in an inability to route packets to BGP neighbors during reconvergence times. Cisco has released free software updates that address this vulnerability. There are no workarounds for this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-bgp Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD0ACgkQUddfH3/BbTpwbwD+IkJ8uofSPxpZwUFgVu8dVRWq 6OpD4B6w1i+wGN5IOEQA/1o7VdakD9PFvIZODdfcptJSRK4k4SbeAf46KMFAiSYM =/DrE -END PGP SIGNATURE-
Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerabilities
-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 === The Cisco IOS Software Network Address Translation (NAT) feature contains two denial of service (DoS) vulnerabilities in the translation of IP packets. The vulnerabilities are caused when packets in transit on the vulnerable device require translation. Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-nat Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD8ACgkQUddfH3/BbTrGtwD8CaC1pyjW+b1ltiGIsvX+jMfG jEEqlzr6VT/F1vjvaDgA/2pAjCs0T5rcGdJUhyKRlQH+PjVLBRVQaQTp/kk5T4+i =q0VJ -END PGP SIGNATURE-
Cisco Security Advisory: Cisco IOS Software DHCP Version 6 Denial of Service Vulnerability
-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) +- Summary === Cisco IOS Software and Cisco IOS XE Software contain a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. An attacker could exploit this vulnerability by sending a crafted request to an affected device that has the DHCP version 6 (DHCPv6) server feature enabled, causing a reload. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-dhcpv6 Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD4ACgkQUddfH3/BbTpTmwD/aWSNsmnurhMHzokzSTJUI4/B 428bYcAKinMffKT+bgIA/20BRb6rR7qCoIK0ynVDnbtYiNjwCMy+EQFEUrDWhpl1 =kAhj -END PGP SIGNATURE-
Cisco Security Advisory: Cisco IOS Software DHCP Denial of Service Vulnerability
-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 === Cisco IOS Software contains a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. An attacker could exploit this vulnerability by sending a single DHCP packet to or through an affected device, causing the device to reload. Cisco has released free software updates that address this vulnerability. A workaround that mitigates this vulnerability is available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-dhcp Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD4ACgkQUddfH3/BbTrJBgD8D/YGAbTV2hF3i3v0Gg8nFc2x jVoS/mVfTMurWAYQflIA/0HU8TpFR6A9Oegidg2Cjc27Vyx2RbAqah6Y57BceTco =WgD1 -END PGP SIGNATURE-
Cisco Security Advisory: Cisco Catalyst 4500E Series Switch with Cisco Catalyst Supervisor Engine 7L-E Denial of Service Vulnerability
-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) +- Summary === The Catalyst 4500E series switch with Supervisor Engine 7L-E contains a denial of service (DoS) vulnerability when processing specially crafted packets that can cause a reload of the device. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-ecc Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD8ACgkQUddfH3/BbTptGQD+LJo6CaOPouQRBuPy+1jpi5SB EvY/pXj/6kA47NIeQtMA/A/K7sSoBEfEn/baeeTcOOvyJ4Yo4I9wekRMSMJFzxoz =kR+l -END PGP SIGNATURE-
RE: Ethernet OAM BCPs Please are there any yet???
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 steps, with 1s being the midpoint. So we use 1s intervals. I'm not sure if the other parameters you mention are configurable for CCM. I think the packet has a constant size. Are you wanting to also do Y.1731 performance management? Jonathon -Original Message- From: Adam Vitkovsky [mailto:adam.vitkov...@swan.sk] Sent: Wednesday, 26 September 2012 9:29 p.m. To: nanog@nanog.org Subject: Ethernet OAM BCPs Please are there any yet??? 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 Level 6 for customers and carrier-customers respectfully -would this be enough please? I'm also interested on what's the rule of thumb for CCMs Frequency, Number of Packets, Interpacket Interval, Packet Size and Lifetime for the particular operation Thanks a lot for any inputs This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).
Anyone from Verizon/TATA on here? Possible Packet Loss
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 trace routes from our firewall to the client's IP and most of the time they look fine, however I occasionally see some packet loss. Good trace route: 1 65.61.0.97 0 msec 0 msec 0 msec 2 107.1.118.217 0 msec 10 msec 0 msec 3 69.139.194.21 0 msec 0 msec 0 msec 4 68.86.147.129 10 msec 10 msec 20 msec 5 68.86.94.169 20 msec 30 msec 20 msec 6 68.86.86.26 20 msec 20 msec 10 msec 7 216.6.87.97 10 msec 20 msec 20 msec 8 216.6.87.34 10 msec 20 msec 10 msec 9 152.63.34.22 20 msec 10 msec 20 msec 10 130.81.28.255 30 msec 30 msec 20 msec Traceroutes with packet loss (8th hop): 1 65.61.0.97 0 msec 0 msec 0 msec 2 107.1.118.217 0 msec 10 msec 0 msec 3 69.139.194.21 0 msec 0 msec 0 msec 4 68.86.147.129 20 msec 10 msec 10 msec 5 68.86.94.169 20 msec 20 msec 30 msec 6 68.86.86.26 20 msec 20 msec 10 msec 7 216.6.87.97 10 msec 20 msec 30 msec 8 216.6.87.34 10 msec * 10 msec 9 152.63.34.22 140 msec 110 msec 20 msec 10 130.81.28.255 20 msec 30 msec 30 msec 1 65.61.0.97 10 msec 0 msec 0 msec 2 107.1.118.217 0 msec 10 msec 0 msec 3 69.139.194.21 0 msec 0 msec 0 msec 4 68.86.147.129 20 msec 20 msec 10 msec 5 68.86.94.169 30 msec 20 msec 20 msec 6 68.86.86.26 20 msec 20 msec 20 msec 7 216.6.87.97 20 msec 10 msec 20 msec 8 216.6.87.34 20 msec 40 msec * 9 152.63.34.22 20 msec 10 msec 10 msec 10 130.81.28.255 30 msec 30 msec 20 msec It appears the 8th hop occasionally has packet loss. Thanks, Derek
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
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 what you think it does. -Blake On Wed, Sep 26, 2012 at 11:59 AM, Derek Ivey de...@derekivey.com wrote: 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 trace routes from our firewall to the client's IP and most of the time they look fine, however I occasionally see some packet loss. Good trace route: 1 65.61.0.97 0 msec 0 msec 0 msec 2 107.1.118.217 0 msec 10 msec 0 msec 3 69.139.194.21 0 msec 0 msec 0 msec 4 68.86.147.129 10 msec 10 msec 20 msec 5 68.86.94.169 20 msec 30 msec 20 msec 6 68.86.86.26 20 msec 20 msec 10 msec 7 216.6.87.97 10 msec 20 msec 20 msec 8 216.6.87.34 10 msec 20 msec 10 msec 9 152.63.34.22 20 msec 10 msec 20 msec 10 130.81.28.255 30 msec 30 msec 20 msec Traceroutes with packet loss (8th hop): 1 65.61.0.97 0 msec 0 msec 0 msec 2 107.1.118.217 0 msec 10 msec 0 msec 3 69.139.194.21 0 msec 0 msec 0 msec 4 68.86.147.129 20 msec 10 msec 10 msec 5 68.86.94.169 20 msec 20 msec 30 msec 6 68.86.86.26 20 msec 20 msec 10 msec 7 216.6.87.97 10 msec 20 msec 30 msec 8 216.6.87.34 10 msec * 10 msec 9 152.63.34.22 140 msec 110 msec 20 msec 10 130.81.28.255 20 msec 30 msec 30 msec 1 65.61.0.97 10 msec 0 msec 0 msec 2 107.1.118.217 0 msec 10 msec 0 msec 3 69.139.194.21 0 msec 0 msec 0 msec 4 68.86.147.129 20 msec 20 msec 10 msec 5 68.86.94.169 30 msec 20 msec 20 msec 6 68.86.86.26 20 msec 20 msec 20 msec 7 216.6.87.97 20 msec 10 msec 20 msec 8 216.6.87.34 20 msec 40 msec * 9 152.63.34.22 20 msec 10 msec 10 msec 10 130.81.28.255 30 msec 30 msec 20 msec It appears the 8th hop occasionally has packet loss. Thanks, Derek
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap iki...@gmail.com 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 in regards to packet loss, as what you posted does not indicate what you think it does. Agreed. Derek should read A Practical Guide to (Correctly) Troubleshooting with Traceroute: http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Darius Jahandarie
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
Thanks guys. That was an informative read. I will do some more troubleshooting. Derek On Sep 26, 2012, at 1:16 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap iki...@gmail.com 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 in regards to packet loss, as what you posted does not indicate what you think it does. Agreed. Derek should read A Practical Guide to (Correctly) Troubleshooting with Traceroute: http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Darius Jahandarie
The optimistically named Project Moonshot (was Re: POLL: 802.1x deployment)
- Original Message - From: Peter J. Cherny pet...@luddite.com.au I've (re)sent this to the list as no-one else has noted it g 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 going to look into it more deeply tonight; if it is -- as it appears to be -- a framework for globally federated identification/authentication, then it will probably hit the same walls (of theory, not merely implementation) which other earlier attempts have hit: privacy and non-correlation being prime among them. It's orthogonal to 802.1x, though, unless anyone's shipping code to hook a dot1x server to it as you would, say, a Radius server. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
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: ??!!!??!!!?!!?!!!? !!?!!!?!!! Success rate is 91 percent (91/100), round-trip min/avg/max = 20/26/30 ms I had my client send me the output of the ping command (100 pings) and a trace route. Their 5th hop is 130.81.28.254 and one of the response times in their trace route was 175ms so the issue seems to be around there. I asked them to open a ticket with Verizon to take a look. Thanks, Derek On Sep 26, 2012, at 1:54 PM, Derek Ivey de...@derekivey.com wrote: Thanks guys. That was an informative read. I will do some more troubleshooting. Derek On Sep 26, 2012, at 1:16 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap iki...@gmail.com 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 in regards to packet loss, as what you posted does not indicate what you think it does. Agreed. Derek should read A Practical Guide to (Correctly) Troubleshooting with Traceroute: http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Darius Jahandarie
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
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). 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: ??!!!??!!!?!!?!!!? !!?!!!?!!! Success rate is 91 percent (91/100), round-trip min/avg/max = 20/26/30 ms I had my client send me the output of the ping command (100 pings) and a trace route. Their 5th hop is 130.81.28.254 and one of the response times in their trace route was 175ms so the issue seems to be around there. I asked them to open a ticket with Verizon to take a look. Thanks, Derek On Sep 26, 2012, at 1:54 PM, Derek Ivey de...@derekivey.com wrote: Thanks guys. That was an informative read. I will do some more troubleshooting. Derek On Sep 26, 2012, at 1:16 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap iki...@gmail.com 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 in regards to packet loss, as what you posted does not indicate what you think it does. Agreed. Derek should read A Practical Guide to (Correctly) Troubleshooting with Traceroute: http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Darius Jahandarie -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
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/26/2012 04:02 PM, Jo Rhett wrote: 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). 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: ??!!!??!!!?!!?!!!? !!?!!!?!!! Success rate is 91 percent (91/100), round-trip min/avg/max = 20/26/30 ms I had my client send me the output of the ping command (100 pings) and a trace route. Their 5th hop is 130.81.28.254 and one of the response times in their trace route was 175ms so the issue seems to be around there. I asked them to open a ticket with Verizon to take a look. Thanks, Derek On Sep 26, 2012, at 1:54 PM, Derek Ivey de...@derekivey.com wrote: Thanks guys. That was an informative read. I will do some more troubleshooting. Derek On Sep 26, 2012, at 1:16 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap iki...@gmail.com 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 in regards to packet loss, as what you posted does not indicate what you think it does. Agreed. Derek should read A Practical Guide to (Correctly) Troubleshooting with Traceroute: http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Darius Jahandarie
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
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/26/2012 04:02 PM, Jo Rhett wrote: 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). 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: ??!!!??!!!?!!?!!!? !!?!!!?!!! Success rate is 91 percent (91/100), round-trip min/avg/max = 20/26/30 ms I had my client send me the output of the ping command (100 pings) and a trace route. Their 5th hop is 130.81.28.254 and one of the response times in their trace route was 175ms so the issue seems to be around there. I asked them to open a ticket with Verizon to take a look. Thanks, Derek On Sep 26, 2012, at 1:54 PM, Derek Ivey de...@derekivey.com wrote: Thanks guys. That was an informative read. I will do some more troubleshooting. Derek On Sep 26, 2012, at 1:16 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap iki...@gmail.com 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 in regards to packet loss, as what you posted does not indicate what you think it does. Agreed. Derek should read A Practical Guide to (Correctly) Troubleshooting with Traceroute: http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Darius Jahandarie
Re: Verizon FIOS troubleshooting
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/smokeping.cgi?target=people.bryan I worked with Brian offline and can confirm there's definitely an issue, at least on his particular node/area (W.D.C.). Anyone from Verizon lurking? -- Randy M
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
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 and took 2 screenshots (http://imgur.com/a/RDyXO). What do you guys think? Most of the time the ping times seem fairly low, however I occasionally see these spikes. It seems sporadic... My boss also has FiOS and he is seeing the same thing. Pages load quick most of the time and sometimes take awhile to load. Thanks, Derek On 9/26/2012 3:19 PM, Pellitteri Alexis wrote: 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/26/2012 04:02 PM, Jo Rhett wrote: 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). 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: ??!!!??!!!?!!?!!!? !!?!!!?!!! Success rate is 91 percent (91/100), round-trip min/avg/max = 20/26/30 ms I had my client send me the output of the ping command (100 pings) and a trace route. Their 5th hop is 130.81.28.254 and one of the response times in their trace route was 175ms so the issue seems to be around there. I asked them to open a ticket with Verizon to take a look. Thanks, Derek On Sep 26, 2012, at 1:54 PM, Derek Ivey de...@derekivey.com wrote: Thanks guys. That was an informative read. I will do some more troubleshooting. Derek On Sep 26, 2012, at 1:16 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap iki...@gmail.com 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 in regards to packet loss, as what you posted does not indicate what you think it does. Agreed. Derek should read A Practical Guide to (Correctly) Troubleshooting with Traceroute: http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Darius Jahandarie
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
- Original Message - From: Derek Ivey de...@derekivey.com 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 and took 2 screenshots (http://imgur.com/a/RDyXO). What do you guys think? Most of the time the ping times seem fairly low, however I occasionally see these spikes. It seems sporadic... To recap, traceroute, mtr, and similar utilities work by talking to each succesive router along a path. Because this is so, and because Any Given Router may be too busy to deal with such packets in favor of real traffic (most routers handle data packets on the line cards, while they may have to expend actual CPU on things like ICMP), it's possible for a path with perfect connectivity to show some intermediate hops completely missing -- No Reply At All, you might say -- to diagnostic tools. The traces you show look pretty decent; I've seen much worse on links with fine interactive shell session response. The time you have to worry is when one router *and everything past it* shows packet loss of roughly the same amount, or when ping times jump markedly at a given spot (by which I mean, say, from 32 to 800ms, rather than from 32 to 125). The short version, though, which most people are are being uncharacteristically too nice to say (:-) is that this is still a tier 1 problem, and NANOG is generally tier 3 or 4. :-) You're welcome to take the issue up over on outa...@outages.org, if you like... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
Thanks guys. Sorry for the noise... Derek On 9/26/2012 9:11 PM, Jay Ashworth wrote: - Original Message - From: Derek Ivey de...@derekivey.com 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 and took 2 screenshots (http://imgur.com/a/RDyXO). What do you guys think? Most of the time the ping times seem fairly low, however I occasionally see these spikes. It seems sporadic... To recap, traceroute, mtr, and similar utilities work by talking to each succesive router along a path. Because this is so, and because Any Given Router may be too busy to deal with such packets in favor of real traffic (most routers handle data packets on the line cards, while they may have to expend actual CPU on things like ICMP), it's possible for a path with perfect connectivity to show some intermediate hops completely missing -- No Reply At All, you might say -- to diagnostic tools. The traces you show look pretty decent; I've seen much worse on links with fine interactive shell session response. The time you have to worry is when one router *and everything past it* shows packet loss of roughly the same amount, or when ping times jump markedly at a given spot (by which I mean, say, from 32 to 800ms, rather than from 32 to 125). The short version, though, which most people are are being uncharacteristically too nice to say (:-) is that this is still a tier 1 problem, and NANOG is generally tier 3 or 4. :-) You're welcome to take the issue up over on outa...@outages.org, if you like... Cheers, -- jra
