- NANOG - lists.nanog.org

Cisco Security Advisory: Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability
by Cisco Systems Product Security Incident Response Team 18 Aug '09

18 Aug '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability Advisory ID: cisco-sa-20090818-bgp http://www.cisco.com/warp/public/707/cisco-sa-20090818-bgp.shtml Revision 1.0 For Public Release 2009 August 18 1500 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco IOS XR will reset a Border Gateway Protocol (BGP) peering session when receiving a specific invalid BGP update. The vulnerability manifests when a BGP peer announces a prefix with a specific invalid attribute. On receipt of this prefix, the Cisco IOS XR device will restart the peering session by sending a notification. The peering session will flap until the sender stops sending the invalid/corrupt update. This is a different vulnerability to what was disclosed in the Cisco Security Advisory "Cisco IOS Software Border Gateway Protocol 4-Byte Autonomous System Number Vulnerabilities" disclosed on the 2009 July 29 1600 UTC at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml Cisco is preparing to release free software maintenance upgrade (SMU) that address this vulnerability. This advisory will be updated once the SMU is available. A workaround that mitigates this vulnerability is available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20090818-bgp.shtml Affected Products ================= This vulnerability affects all Cisco IOS XR software devices after and including software release 3.4.0 configured with BGP routing. Vulnerable Products +------------------ To determine the Cisco IOS XR Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS XR Software by displaying text similar to "Cisco IOS XR Software". The software version is displayed after the text "Cisco IOS XR Software". The following example identifies a Cisco CRS-1 that is running Cisco IOS XR Software Release 3.6.2: RP/0/RP0/CPU0:CRS#show version Tue Aug 18 14:25:17.407 AEST Cisco IOS XR Software, Version 3.6.2[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 1.49(20080319:195807) [CRS-1 ROMMON], CRS uptime is 4 weeks, 4 days, 1 minute System image file is "disk0:hfr-os-mbi-3.6.2/mbihfr-rp.vm" cisco CRS-8/S (7457) processor with 4194304K bytes of memory. 7457 processor at 1197Mhz, Revision 1.2 17 Packet over SONET/SDH network interface(s) 1 DWDM controller(s) 17 SONET/SDH Port controller(s) 8 TenGigabitEthernet/IEEE 802.3 interface(s) 2 Ethernet/IEEE 802.3 interface(s) 1019k bytes of non-volatile configuration memory. 38079M bytes of hard disk. 981440k bytes of ATA PCMCIA card at disk 0 (Sector size 512 bytes). Configuration register on node 0/0/CPU0 is 0x102 Boot device on node 0/0/CPU0 is mem: !--- output truncated The following example identifies a Cisco 12404 router that is running Cisco IOS XR Software Release 3.7.1: RP/0/0/CPU0:GSR#show version Cisco IOS XR Software, Version 3.7.1[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 12.0(20051020:160303) SOFTWARE Copyright (c) 1994-2005 by cisco Systems, Inc. GSR uptime is 3 weeks, 6 days, 3 hours, 20 minutes System image file is "disk0:c12k-os-mbi-3.7.1/mbiprp-rp.vm" cisco 12404/PRP (7457) processor with 2097152K bytes of memory. 7457 processor at 1266Mhz, Revision 1.2 1 Cisco 12000 Series Performance Route Processor 1 Cisco 12000 Series - Multi-Service Blade Controller 1 1 Port ISE Packet Over SONET OC-48c/STM-16 Controller (1 POS) 1 Cisco 12000 Series SPA Interface Processor-601/501/401 3 Ethernet/IEEE 802.3 interface(s) 1 SONET/SDH Port controller(s) 1 Packet over SONET/SDH network interface(s) 4 PLIM QoS controller(s) 8 FastEthernet/IEEE 802.3 interface(s) 1016k bytes of non-volatile configuration memory. 1000496k bytes of disk0: (Sector size 512 bytes). 65536k bytes of Flash internal SIMM (Sector size 256k). Configuration register on node 0/0/CPU0 is 0x2102 Boot device on node 0/0/CPU0 is disk0: !--- output truncated Additional information about Cisco IOS XR software release naming conventions is available in the "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html#t6 Additional information about Cisco IOS XR software time-based release model is available in the "White Paper: Guidelines for Cisco IOS XR Software" at the following link: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8803/ps5845/product_b… BGP is configured in Cisco IOS XR software with the configuration command router bgp [AS Number] or router bgp [X.Y]. The device is vulnerable if it is running affected Cisco IOS XR version and has BGP configured. The following example shows a Cisco IOS XR software device configured with BGP: RP/0/0/CPU0:GSR#show running-config | begin router bgp Building configuration... router bgp 65535 bgp router-id 192.168.0.1 address-family ipv4 unicast network 192.168.1.1/32 ! address-family vpnv4 unicast ! neighbor 192.168.2.1 remote-as 65534 update-source Loopback0 address-family ipv4 unicast ! !--- output truncated Products Confirmed Not Vulnerable +-------------------------------- The following Cisco products are confirmed not vulnerable: * Cisco IOS Software * Cisco IOS XR Software prior to release 3.4.0 * Cisco IOS XR Software not configured for BGP routing No other Cisco products are currently known to be affected by this vulnerability. Details ======= On August 17th, 2009, a widely-distributed Border Gateway Protocol (BGP) route update contained an BGP Update message with a specific invalid attribute. When the invalid BGP Update message was processed by Cisco IOS XR software, it began resetting BGP peering sessions over which the update was received. When receiving the invalid update the receiving Cisco IOS XR software device will display a log message like the following example: RP/0/RP0/CPU0:Aug 17 13:47:05.896 GMT: bgp[122]: %ROUTING-BGP-5-ADJCHANGE : neighbor 192.168.0.1 Down - BGP Notification sent: invalid or corrupt AS path The peering session will flap until the sender stops sending the invalid/corrupt prefix. This vulnerability is documented in Cisco Bug ID CSCtb42995 ( registered customers only) and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2055. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCtb42995 - Cisco IOS XR Software Border Gateway Protocol Vulnerability +----------------------------------------------------- CVSS Base Score - 4.3 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Partial CVSS Temporal Score - 3.9 Exploitability - Functional Remediation Level - Unavailable Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may result in BGP peering sessions continuously being reset. This may lead to routing inconsistencies and a denial of service for those affected networks. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. +---------------------------------------+ | Cisco IOS XR Version | SMU ID | |----------------------+----------------| | 3.2.X | Not Vulnerable | |----------------------+----------------| | 3.3.X | Not vulnerable | |----------------------+----------------| | 3.4.0 | Pending | |----------------------+----------------| | 3.4.1 | Pending | |----------------------+----------------| | 3.4.2 | Pending | |----------------------+----------------| | 3.4.3 | Pending | |----------------------+----------------| | 3.5.2 | Pending | |----------------------+----------------| | 3.5.3 | Pending | |----------------------+----------------| | 3.5.4 | Pending | |----------------------+----------------| | 3.6.0 | Pending | |----------------------+----------------| | 3.6.1 | Pending | |----------------------+----------------| | 3.6.2 | Pending | |----------------------+----------------| | 3.6.3 | Pending | |----------------------+----------------| | 3.7.0 | Pending | |----------------------+----------------| | 3.7.1 | Pending | |----------------------+----------------| | 3.7.2 | Pending | |----------------------+----------------| | 3.7.3 | Pending | |----------------------+----------------| | 3.8.0 | Pending | |----------------------+----------------| | 3.8.1 | Pending | +---------------------------------------+ Workarounds =========== There are no workarounds on the affected device itself. Co-ordination is required with the peering neighbor support staff to filter the invalid update on their outbound path. The following procedure explains how to help mitigate this vulnerability: Using the peer IP address in the log message that was generated when the Cisco IOS XR software device received the invalid update; capture the notification message hex dump from the CLI command show bgp neighbor and contact the Cisco TAC whom can assist with a decode. Details on how to contact Cisco TAC are contained within the section "Obtaining Fixed Software" of this advisory. The following example show an example generated log message when receiving the invalid update, and the details to be captured to be sent to the Cisco TAC for decoding: Log message generated when receiving invalid update: RP/0/RP0/CPU0:Aug 17 13:47:05.896 GMT: bgp[122]: %ROUTING-BGP-5-ADJCHANGE : neighbor 192.168.0.1 Down - BGP Notification sent: invalid or corrupt AS path Information to capture for decoding by the Cisco TAC, is the output from show bgp neighbors [ip address of neighbor from above log message]. RP/0/RP0/CPU0:CRS#show bgp neighbors 192.168.0.1 <capture output and provide to Cisco TAC> Working with Cisco TAC, the decode of the above will display the AS path in a manner illustrated below. ATTRIBUTE NAME: AS_PATH AS_PATH: Type 2 is AS_SEQUENCE AS_PATH: Segment Length is 4 (0x04) segments long AS_PATH: 65533 65532 65531 65531 Working cooperatively with your peering partner, request that they filter outbound prefix advertisements from the identified source AS (in this example 65531) for your peering session. The filters configuration methods will vary depending on the routing device operating system used. For Cisco IOS XR the filters will be applied using Routing Policy Language (RPL) policies or with Cisco IOS software via applying route-maps that deny advertisements matching that AS in their AS-PATH. Once these policies are applied, the peering session will be re-established. For further information on Cisco IOS XR RPL consult the document "Implementing Routing Policy on Cisco IOS XR Software" at the following link: http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.0/routing/configuration/… For further information on Cisco IOS route maps with BGP, consult the document "Cisco IOS BGP Configuration Guide, Release 12.4T" at the following link: http://www.cisco.com/en/US/docs/ios/12_2sr/12_2srb/feature/guide/tbgp_c.html Obtaining Fixed Software ======================== Cisco will be releasing free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt(a)cisco.com or security-alert(a)cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac(a)cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== On August 17, 2009 around 16:30-17:00 UTC several ISP's began experiencing connectivity issues as BGP sessions were being repeatedly reset. Cisco TAC was engaged with a number of customers all seeing similar issues. Stability came a few hours afterward as workarounds were applied. At this time, it is not believed that the connectivity issues were the result of malicious activity. Status of this Notice: INTERIM ============================== THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. CISCO EXPECTS TO UPDATE THIS DOCUMENT AS NEW INFORMATION BECOMES AVAILABLE. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20090818-bgp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce(a)cisco.com * first-bulletins(a)lists.first.org * bugtraq(a)securityfocus.com * vulnwatch(a)vulnwatch.org * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * full-disclosure(a)lists.grok.org.uk * comp.dcom.sys.cisco(a)newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-August-18 | public | | | | release. | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.… This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFKitOJ86n/Gc8U/uARAlpUAJ95EA/XmiFntl4XuXpKTpqeIt5q8gCfdOPV /OmnNTdlD9lueFh99gS6NDM= =dejJ -----END PGP SIGNATURE-----

1 0

East Africa Fibre Connectivity- Heads up
by Raymond Macharia 18 Aug '09

18 Aug '09

Hello all,in the last two weeks or so providers in East Africa, particularly in Kenya where I am, have been moving from Satellite to Fibre for the internet Back bone connectivity. From where I am I have seen an upsurge of about 100Mbps in the last two days from my users. It would be interesting to know if anyone out there has seen an increase in traffic from this region and by how much. There is more to come as providers are cutting prices and adding bandwidth to their networks. Best Regards Raymond Macharia

13 19

bits/hz/second: we're barely more efficient than the telegraph (Re: TransAtlantic 40 Gig Waves
by Anton Kapela 17 Aug '09

17 Aug '09

I'll comment on both: On Mon, Aug 17, 2009 at 12:14 PM, Rod Beck<Rod.Beck(a)hiberniaatlantic.com> wrote: > Rod, do you know if the 40G waves increased the spectrum efficiency of > your fiber? On land systems they pretty much break even, i.e. you can [rod beck replies] > The enabling technology is based on advanced encoding techniques allowing a greater rate of symbol transfer." Looking back in Google and other IEEE papers, the previous 20 years of interfacing our abstract "bits" to the real world via photons hasn't been met with terribly high efficiencies, though we certainly have seen both great progress in the transmitter (who could have imagined a VCSEL in 1985?) and receiver technology, and of course a significant improvement in usable bits/sec. I can only wonder what the curve of optical spectral efficiency we achieve over the next decades will resemble. Perhaps we'll have to wait for a "Shannon of Optics" to stand up (or quit their day job at whatever modern-day version of $bell_labs they're stuck working for) and point out something obvious we're missing. A bit of sobering reality I often consider is we waited roughly a century to progress from where Marconi began to the present day, where we have cheap radios doing 12 bits/hz/sec costing about $20k (a pair). Clearly a key difference is that people are paying (allot, propotionately) to communicate $stuff and folks value networks more than they did previously - so we're not in the same position folks were pre-1900's, struggling to find a market for their crazy wires across the sea. For the experts out there: how long are we going to wait for something more efficient than morse code over twisted pairs? -Tk

2 1

Re: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ?
by deleskie＠gmail.com 17 Aug '09

17 Aug '09

I'd have to _assume_ that a lot of those impacted don't have a maint contract with their router vendor of choice and therefore don't have an easy path to upgrade. -jim ------Original Message------ From: Jared Mauch To: randal k Cc: nanog(a)nanog.org Subject: Re: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? Sent: Aug 17, 2009 7:40 PM On Aug 17, 2009, at 5:37 PM, randal k wrote: > Yep, we started seeing this right around 12:20pm MST. We saw it from a > customer's rapidly-flapping BGP peer. We told them to configure bgp > maxas-limit, but apparently CRS1s don't have that command. > > Anybody have a handy route-map that will deny anything with a as-path > longer than say 15-20? ;-) Is there some significant barrier to people getting recent code on the devices that is not impacted by this and the other fun bgp 'attacks' that can happen? We usually see customers drop bgp sessions all over, making me wonder ... if you're not able to upgrade, what is the issue? Just that most people don't see these as an attack against their infrastructure? That people are unwilling to upgrade code unless it has a long-term impact to their operations? An outage once every few months is OK? - Jared Sent from my BlackBerry device on the Rogers Wireless Network

2 1

[NANOG-announce] NANOG Updates
by Betty Burke 17 Aug '09

17 Aug '09

NANOG Community: As the summer months begin to draw to a close, I hope many of you are making your plans to attend NANOG47. It is sure to be a great program and great meeting venue for all to network. If you have not yet sent your presentation abstract, please submit your materials to http://pc.nanog.org, as the NANOG Program Committee is accepting a few more presentations for consideration. Of additional note, the registration fee will increase on September 14, and the hotel NANOG group rate will expire on September 30, 2009. So don't wait, visit nanog.org for all the latest information and links to registration, the hotel, and local points of interest. In addition to the NANOG47 agenda, we encourage you to take part in the the 5th Annual NANOG Election process. The election information can be found at http://nanog.org/governance/elections/2009elections/ . Please take a moment to review the Eligible Voters list to confirm we have not missed you, and do consider sending a nomination for the Steering, Program, and Mail List committees. The process works well when the community, you, become engaged. As reported at NANOG46 and in NANOG-Futures, the NANOG Marketing Working Group is active and has a new list of sponsorship opportunities for consideration, http://nanog.org/meetings/nanog47/sponsorships.php . We can not emphasize enough how important NANOG Sponsorship is to our efforts in keeping the cost of registration in check. A balance of both allows Merit to provide the level of support the community has come to expect. Please do consider recommending a sponsorship opportunity to your marketing representatives and or send a note to marketing(a)nanog.org with any new ideas you may have. The community will be, and is, very appreciative and in return it is a great opportunity for Sponsors to have access to a diverse group which represent the spirit of NANOG. Lastly, in keeping with Merit's commitment to community transparency, the community will find a set of Financial updates at http://nanog.org/about/financial/ And the most recent NANOG46 survey information can be found at http://nanog.org/about/surveys As always, on behalf of the NANOG support staff, we look forward to seeing many of you in person at our next meeting, NANOG47 in Dearborn, Michigan. In addition to contacting me directly, always feel free to send any comments, questions or concerns directly to nanog-support(a)nanog.org Sincerely, Betty Burke NANOG Community Project Manager and NANOG SC Member _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

atac.fr DNS problem
by Serge Vautour 17 Aug '09

17 Aug '09

Hello, Our AS855 can't seem to contact the DNS servers for atac.fr domains (dns.atac.fr [62.160.25.65] & dns2.atac.fr [195.68.125.36]). From our network, dig dies for both IPs: ------------------------------------------------------------------------------ ;; Received 401 bytes from 192.33.4.12#53(c.root-servers.net) in 17 ms atac.fr. 172800 IN NS dns2.atac.fr. atac.fr. 172800 IN NS dns.atac.fr. ;; Received 94 bytes from 194.57.253.1#53(E.NIC.fr) in 316 ms dig: couldn't get address for 'dns2.atac.fr': not found ------------------------------------------------------------------------------ If I use dig from public web sites it works: ------------------------------------------------------------------------------ ;; Received 401 bytes from 192.203.230.10#53(e.root-servers.net) in 94 ms atac.fr. 172800 IN NS dns2.atac.fr. atac.fr. 172800 IN NS dns.atac.fr. ;; Received 94 bytes from 194.57.253.1#53(E.NIC.fr) in 313 ms atac.fr. 300 IN A 194.145.56.21 atac.fr. 300 IN NS dns.atac.fr. atac.fr. 300 IN NS dns2.atac.fr. ;; Received 110 bytes from 195.68.125.36#53(dns2.atac.fr) in 113 ms ------------------------------------------------------------------------------ A traceroutes die as well: traceroute 195.68.125.36 .... 9 ae-2-79.edge1.NewYork1.Level3.net (4.68.16.78) [AS 3356] 25.278 ms ae-1-69.edge1.NewYork1.Level3.net (4.68.16.14) [AS 3356] 25.284 ms ae-4-99.edge1.NewYork1.Level3.net (4.68.16.206) [AS 3356] 27.476 ms 10 COLT-TELECO.edge1.NewYork1.Level3.net (4.78.132.22) [AS 3356] 25.871 ms 26.014 ms 25.589 ms 11 * * * 12 90.168-14-84.ripe.coltfrance.com (84.14.168.90) [AS 8220] 114.992 ms 114.912 ms 115.243 ms 13 * * * traceroute 62.160.25.65 ... 9 ae-2-79.edge2.NewYork1.Level3.net (4.68.16.80) [AS 3356] 25.573 ms 25.429 ms ae-3-89.edge2.NewYork1.Level3.net (4.68.16.144) [AS 3356] 25.591 ms 10 francetelecom-level3-te.NewYork1.Level3.net (4.68.111.86) [AS 3356] 39.905 ms francetelecom-level3-te.NewYork1.Level3.net (4.68.111.82) [AS 3356] 33.916 ms 33.762 ms 11 * * * It appears as though packets aren't making their way back. Is there anyone from francetelecom or AS8220 that could assist? Thanks, Serge __________________________________________________________________ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

2 2

APAC to US crawling
by Mun Fai Lee 17 Aug '09

17 Aug '09

Is anyone seeing a huge latency jump from Asia Pac to US again? Sample traceroute: 4 2 ms 1 ms 1 ms 210.13.64.14 5 2 ms 1 ms 4 ms 210.13.64.13 6 2 ms 2 ms 2 ms 218.105.0.69 7 41 ms 35 ms 35 ms 218.105.6.102 8 36 ms 36 ms 36 ms 218.105.5.82 9 36 ms 36 ms 37 ms 210.52.132.230 10 38 ms 39 ms 38 ms 210.53.126.2 11 38 ms 38 ms 39 ms 217.6.49.181 12 * 296 ms 295 ms lax-sa1-i.LAX.US.NET.DTAG.DE [62.154.5.170] 13 1033 ms 1029 ms 1028 ms 192.205.33.101 14 1087 ms 1090 ms 1094 ms cr2.la2ca.ip.att.net [12.122.129.98] 15 1086 ms 1084 ms 1085 ms cr1.slkut.ip.att.net [12.122.30.29] The above was taken from a user in China tracing to New York about 30 mins ago

4 6

FW: BoF for APNIC 28 in Beijing - IPv6 Promotion
by Skeeve Stevens 17 Aug '09

17 Aug '09

FYI for those that might be attending APNIC 28 in Beijing next week. -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve(a)eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? From: Skeeve Stevens Sent: Monday, 17 August 2009 9:05 PM To: 'apnic-talk(a)apnic.net' Cc: ausnog(a)ausnog.net; nznog Subject: BoF for APNIC 28 in Beijing - IPv6 Promotion Greeting all that will be attending APNIC 28 in Beijing, While we are in China at APNIC 28, and as per the spirit of 1.3 of http://www.apnic.net/__data/assets/pdf_file/0012/3117/sig-guidelines.pdf I am proposing that we hold a BoF for the purpose of seeing if there are enough interested parties to get together to discuss the issue of IPv6 promotion in the APNIC region with the 'maybe' end of it becoming a SIG. I am asking for some leeway in this request as this region is a complex one with a very broad range of cultural differences and language barriers that that don't always translate across the entire membership. For example, the way we might want to accomplish something in Australia could be very different to the way it would be done in say Japan, China or India. IPv6 promotion is something that APNIC has been doing for quite a while now, with some degree of success. But given the timeframes in which we have till things get very painful for many organisations, I do not believe that APNIC has sufficient resources (whether that be man-power, financial, etc) to effectively promote it across all the economic communities that it represents. I would like the hold a BoF to gauge the interest on how members themselves can be more involved in their region, what they would/could be prepared to do, and to discuss the challenges that we are having, developing new ideas and focusing on specific ways to promote IPv6 - without all the technical mumbo-jumbo. I am suggesting a much less technical perspective needs to take shape. I realise that a very large percentage of us are technical people, but there are many business minded people who I am sure have many great ideas... and if there isn't that many... let's get them involved somehow. Many members in the APNIC region have their own NIR (JPNIC, CNNIC, etc) to assist in these kinds of matters (I assume), but in Australia and NZ specifically speaking for my area of focus, we deal directly with APNIC... so I don't know how appropriate having people who deal with their NIR directly on these matters, but the more the merrier. There is no suggestion in this proposal that the many people who talk at conferences about IPv6, or APNIC themselves have not done a good job... My suggestion is that we can do more, and time is of the essence. I am inspired to bring this about by my own passion regarding IPv6 adoption, and I am willing to put (and already have put) the resources and passion of me and my company behind efforts to help finding new ways to foster IPv6 adoption in this region. There seems to be an issue of room availability at APNIC28, but if I have to put up some $$ myself and we go take over the local McDonalds, I am willing to do so to try and help make this BoF happen. I think timing is important... and I think now is the time we need to start discussing these things. Big machines like APNIC move rather slowly, and I am willing to try to do what it takes to try and push things along. So, if you're going to be in Beijing, and you really are passionate about IPv6 adoption, please come and see me - the big bald aussie-guy - and let's get something happening. I will be looking at the schedule to see where we can fit a couple of hours to chat. Also, you might be approached by myself or others who are also interested in making this happen. All I can ask is to please be involved, and DO - rather than talk about it. -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve(a)eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced.

1 0

ADMIN: List FAQ/Monthly Post.
by NANOG Mail List Committee 16 Aug '09

16 Aug '09

This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins(a)nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://spam-l.com/mailman/listinfo * Contacting People * http://puck.nether.net/netops/ * http://www.peeringdb.com * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins(a)nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php

1 0

Re: Follow up to previous post regarding SAAVIS
by mkarir 15 Aug '09

15 Aug '09

Hi Jared, You should give the new RADB portal a try. We were trying to do pretty much what you describe. Dont know what web2.0 is but the new portal is a web based object management system complete with "recommended" changes and inconsistency lists. We just added prefix allocation check with backend information from PCH (prefix checker tool). Prefix/acl generation is coming soon too stay tuned. Alert/ notification has been tested and we are figuring out how to roll it out on a larger scale. We are also starting to study whether the data itself has actually gotten any better since we put this web gui in place. -manish On Aug 12, 2009, at 6:55 PM, nanog-request(a)nanog.org wrote: > Date: Wed, 12 Aug 2009 16:57:07 -0400 > From: Jared Mauch <jared(a)puck.nether.net> > Subject: Re: Follow up to previous post regarding SAAVIS > To: nanog-post(a)rsuc.gweep.net > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Message-ID: <ACC05272-318E-4E81-A48C-3CE22AA2F943(a)puck.nether.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > I've come to the conclusion that if someone put a nice web2.0+ > interface on creating and managing these objects it would be a lot > easier. > > If there were a customer portal where you could visit to say "update > my prefix-list/acl to include the following new prefix(es), and push > the change /now/" I presume that would drive customer utilization of > these services and allow people to manage things "better". > > There are lots of leaks all the time, as can be evidenced by the leak > detection stuff I set up here: > > http://puck.nether.net/bgp/leakinfo.cgi > > - Jared

3 2