August 2010 - Test - lists.nanog.org

migration tools
by Randy Bush 05 Aug '10

05 Aug '10

know any tools, not methods, tools, to o migrate a network from one igp to another (e.g. ospf to is-is), o merge two networks which have common igp but are currently ebgp, o ... think mergers and acquisitions (no i am not gonna do it again:) randy

2 1

Re: SingTel (AS7473) is only announcing ConnectPlus (AS9911) routes to Level3 (AS3356) in SJC?
by Adam LaFountain 05 Aug '10

05 Aug '10

> Date: Fri, 30 Jul 2010 17:38:55 +0200 > From: Martin Barry <marty(a)supine.com> > Subject: SingTel (AS7473) is only announcing ConnectPlus (AS9911) > routes to Level3 (AS3356) in SJC? > To: nanog(a)nanog.org > > Anyone on the list who can offer an explanation about the following > scenario? We have taken this up with providers at either end but it > will take awhile to filter up to the ASes in question. > > We were seeing a London to Singapore connection go via San Jose > causing a 50%+ increase in latency. > > It appears that SingTel (AS7473) is only announcing ConnectPlus > (AS9911) routes to Level3 (AS3356) in SJC. > > However they have many adjacencies in many countries and other routes > of both AS7473 and it's other downstreams don't appear to be affected > (although I haven't tested them all). > > Traceroutes are appended at the end but to see for yourself use > 202.176.222.0 as a BGP or traceroute query in the Level3 looking glass > for both London and any other location, then compare with 167.172.93.0 > > Checking another large AS at random, they see AS7473 announcing AS9911 > routes in London. > > thanks > Marty At first I wanted to say this looks like a policy move on 7473's part but on further investigation I'm not sure if they're punishing themselves or doing some very specific traffic routing possible for balancing purposes. Noticing in Leve'3 bgp output they're a customer Show Level 3 (London, England) BGP routes for 202.176.222.212 BGP routing table entry for 202.176.222.0/24 Paths: (2 available, best #1) 7473 9911 AS-path translation: { APNIC-AS-2-BLOCK APNIC-AS-3-BLOCK } car2.SanJose1 (metric 44128) Origin IGP, metric 100, localpref 100, valid, internal, best Community: North_America Lclprf_100 Level3_Customer United_States San_Jose 7473:10000 7473:20000 7473:41101 Prepend_2_to_AS1668 Prepend_2_to_AS13680 Originator: car2.SanJose1 7473 9911 AS-path translation: { APNIC-AS-2-BLOCK APNIC-AS-3-BLOCK } car2.SanJose1 (metric 44128) Origin IGP, metric 100, localpref 100, valid, internal Community: North_America Lclprf_100 Level3_Customer United_States San_Jose 7473:10000 7473:20000 7473:41101 Prepend_2_to_AS1668 Prepend_2_to_AS13680 Originator: car2.SanJose1 I was inclined to believe it was related to cost, especially seeing the prepend for AOL (1668), but began to dimiss that as I saw two known _peers_ haul the traffic to the west coast as well: Router: gin-l78-mcore3 Site: GB, London - L78, VSNL LONTX01 STRATFORD Command: show ip bgp 202.176.222.212 BGP routing table entry for 202.176.222.0/24 Bestpath Modifiers: deterministic-med Paths: (3 available, best #2) 13 16 7473 9911 laa-icore1. (metric 3100) from laa-mcore3. (laa-mcore3.) Origin IGP, valid, internal Community: Peer route North America West Coast Los Angeles (LAA, LMR) Originator: laa-icore1. 7473 9911 pdi-icore1. (metric 3095) from pdi-mcore4. (pdi-mcore4.) Origin IGP, valid, internal, best Community: Peer route North America West Coast Palo Alto (PDI) Originator: pdi-icore1. and- 1 74 ms 75 ms 75 ms 10gigabitethernet2-3.core1.nyc4.he.net (72.52.92.77) 2 130 ms 149 ms 147 ms 10gigabitethernet5-3.core1.lax1.he.net (72.52.92.226) 3 131 ms 130 ms 139 ms laxeq-ds2-peer1.singtel.com (206.223.123.120) 4 131 ms 130 ms 139 ms ge-1-0-0-0.laxow-cr2.ix.singtel.com (203.208.149.118) In terms of figuring it out for sure I dont think L3 will tell you anything as they probably don't know. SingTel's your best bet but good luck with that unless you become a customer. I'm going to vote backbone traffic balancing by SingTel.

2 1

Fwd: [AusNOG] AusNOG 04 Reminder, 6 weeks to go!
by Mark Prior 04 Aug '10

04 Aug '10

FYI. Mark. -------- Original Message -------- Subject: [AusNOG] AusNOG 04 Reminder, 6 weeks to go! Date: Mon, 2 Aug 2010 19:08:18 +1000 From: Terry Manderson <terry(a)terrym.net> To: ausnog(a)ausnog.net Dear Colleagues, Just reminding you that AusNOG 04 is just 6 weeks away on the 16th and 17th of September at the Four Seasons, Sydney. We'd like to take a moment to highlight that AusNOG 04 *IS* the premier networking event for our industry in Australia for 2010. Apart from the fantastic opportunities you will have for (people) networking with national and international technology experts, we have a wonderful set of speakers for this year. In Sydney at AusNOG 04 you will have to opportunity to hear presentations from such industry luminaries as: Vijay Gill, Google Joe Abley, ICANN Marty Gauvin, Tier 5 and Roland Dobbins, Arbor Networks These speakers will cover such topics as warehouse scale computing, the DNS root signing, data centre design, and the security implications of the NBN. Along with the opportunity to listen to a host of other quality speakers, let us not forget the AusNOG dinner where many friendships and good memories are made! As you may be aware AusNOG 04 is now accepting registrations at: https://secure.ausnog.net/signup We are looking forward to seeing you at AusNOG 04! Kind Regards Terry Manderson (For the AusNOG Board) _______________________________________________ AusNOG mailing list AusNOG(a)lists.ausnog.net http://lists.ausnog.net/mailman/listinfo/ausnog

1 0

Re: IANA DNSSEC Testbed to be Decommissioned
by Joe Abley 03 Aug '10

03 Aug '10

> ICANN would like to thank Packet Clearing House (PCH) and Dun.com > DynTLD for their support and generous donation of global DNS > resources to the IANA DNSSEC testbed. My apologies to the good people at Dyn -- of course, that should be dyn.com, not what I wrote. Joe

1 0

IANA DNSSEC Testbed to be Decommissioned
by Joe Abley 03 Aug '10

03 Aug '10

Colleagues, ICANN has operated the IANA DNSSEC testbed, serving non-production, signed versions of the root, ARPA, IN-ADDR.ARPA, IP6.ARPA, IRIS.ARPA, URN.ARPA, and INT zones for several years. Following the recent completion of DNSSEC deployment in the root zone, this testbed is scheduled to be decommissioned. For more details on the IANA DNSSEC testbed, see <https://ns.iana.org/dnssec/>. For more details on DNSSEC deployment in the Root Zone, see <http://www.root-dnssec.org>. At the time that the service is decommissioned, the nameserver bound to NS.IANA.ORG (208.77.188.32, 2620:0:2d0:1::32) will be shut down and DNS queries to NS.IANA.ORG will fail with ICMP type 3 code 3 (Destination Unreachable, Port Unreachable). We suggest that anybody using the DNSSEC testbed for anything resembling production services make plans to stop doing so at their earliest convenience. ICANN would like to thank Packet Clearing House (PCH) and Dun.com DynTLD for their support and generous donation of global DNS resources to the IANA DNSSEC testbed. DRAFT TIMELINE Wed 2010-08-03 First public notice (this message) Wed 2010-08-25 Second public notice (reminder) Wed 2010-09-01 IANA DNSSEC Testbed is shut down Wed 2010-09-01 Third public notice (confirming work complete) Regards, Joe Abley Director DNS Operations, ICANN

1 0

RE: [c-nsp] Cisco ASR BGP within the box question
by Steven.Glogger＠swisscom.com 03 Aug '10

03 Aug '10

thanks oliver, will try and keep you (and the list) updated. -steven -----Original Message----- From: Oliver Boehmer (oboehmer) [mailto:oboehmer@cisco.com] Sent: Tuesday, August 03, 2010 8:06 AM To: Glogger Steven, SCS-NIT-NIO-PIO-DNW-NEO; cisco-nsp(a)puck.nether.net; nanog(a)nanog.org Subject: RE: [c-nsp] Cisco ASR BGP within the box question Steven, > just a short question (related to a quite new feature from cisco). > with the new cisco ASR software (15.0(1)S - released some days ago) it is > able to do BGP on the same box. > we need this feature because we use the VASI interfaces to bring and filter > traffic from one VRF to another VRF and performing firewalling (ZBF). > > basically we have on the box: > [VRF_A via vasileft1]--[VRF_B via vasiright1] > > and the box itself speaks BGP on VRF_B with some RR's: > [ASRBox] ---- (RR) ---- [anotherbox] > > the fun part is, if you want to announce (e.g. 0.0.0.0/0) from VRF_B > (announced from anotherbox) to VRF_A it should be possible now with that new > feature. > > according to BGP I need to configure the VRF_A peer as route-reflector- > client so the routes from the anotherbox get reflected via RR to VRF_B. > > but, it seems that the router itself needs to be tricked, since he thinks > that both peers are in the same route-reflector cluster ("DENIED due to: > reflected from the same cluster"): >[...] > so, does anyone knows a nice hidden command to disable this cluster-checking > on a per-peer basis or so? I'm not aware of an enhancement to set the cluster-id on a per-vrf basis, it is currently global.. But you could turn this into an eBGP session using local-as, for example router bgp 65501 address-family ipv4 vrf IABIP- neighbor 10.0.0.2 remote-as 65502 neighbor 10.0.0.2 local-as 65503 no-prepend replace-as address-family ipv4 vrf IACYP- neighbor 10.0.0.1 remote-as 65503 neighbor 10.0.0.1 local-as 65502 no-prepend replace-as not sure if this helps.. oli

1 0

[NANOG-announce] NANOG Steering Committee nominations now open
by Steve Feldman 03 Aug '10

03 Aug '10

Elections for three of the six elected positions on the NANOG Steering Committee will be held in October, 2010, for two-year terms ending in October, 2012. The current SC members whose terms are expiring are Patrick Gilmore, Joe Provo, and Robert Seastrom. Joe is finishing his second consecutive term, so per the charter, cannot be considered for reelection until October 2011. If you care about NANOG as a forum, and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. For more information about the role of the Steering Committee, or to find out more about what's involved in being a Steering Committee member, please consult the NANOG charter or contact someone who is already serving and ask them directly. http://www.nanog.org/governance/charter/ http://www.nanog.org/governance/steering/steeringcommittee.php Per the charter, Steering Committee members must attend at least two of three NANOG meetings per year while in office. HOW TO NOMINATE SOMEONE You may nominate someone else, or yourself. There is no limit to the number of nominations that may be submitted by a single person. Individual nominees will be contacted directly to confirm that they are willing to accept the nomination, and so that they can supply a biography for the NANOG web page. To submit a nomination, send the nominee's full name and contact details to nominations(a)nanog.org. The deadline for nominations is 11:59 PM EDT on Monday, August 30. The candidates will be given an opportunity to make brief comments and/ or accept questions from the community at the NANOG 50 Community Meeting on Sunday, October 3. As a reminder, the full election timeline is: Aug. 2 - SC Nominations begin Aug. 24 - Potential charter amendments discussed in nanog-futures Aug. 24 - PC Nominations begin Aug. 30 - SC Candidate information posted/nominations close Sep. 13 - Call for Mailing List Committee nominations Sep. 21 - Ballot approved Oct. 3 - Voting opens at 12:00 EDT Oct. 4 - PC Candidate Information posted/nominations close Oct. 6 - Voting closes at 09:15 EDT, results announced before the close of NANOG 50. For the SC, Steve Feldman _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

LACNOG 2010 - Call for Presentations now available
by LACNOG 2010 02 Aug '10

02 Aug '10

The Network Operators Group of Latin America and the Caribbean, LACNOG, will have its first conference LACNOG 2010 in Sao Paulo, Brazil, from 19th to 22nd of October jointly with the fourteenth LACNIC meeting (LACNIC XIV) and the PTT Forum organized by NIC.br. For more information on LACNOG 2010, please visit http://www.lacnog.org This is the initial public call for presentations for the event. The schedule for the selection of works will be the following: • Deadline for the reception of proposals: Monday, 27 August 2010 • Notification of proposal acceptance: Tuesday, 10 September 2010 • Deadline for the submission of final versions: Thursday, 30 September 2010 The submission of presentations for the LACNOG 2010 is subject to the following conditions: • English, Portuguese and Spanish are the accepted languages. • Presentations must be sent in Portable Document Format (PDF). • Presentations must not exceed twenty-five (25) minutes. Those interested in presenting their work should send the following data, within the timeframe specified above, to the following address: lacnog2010(a)lacnog.org • Complete title of the presentation. • Extended abstract plus a draft of the slides or the complete article if it were available. • Complete name(s), email address(es), biographical data and organization(s) of which the interested parties are a part of or represent. For further information, please don't hesitate to contact the Program Committee at comite_lacnog(a)lacnog.org. For more information on LACNOG 2010, please visit http://www.lacnog.org

1 0

DNSSEC Launched Today by EDUCAUSE and VeriSign
by Matt Larson 02 Aug '10

02 Aug '10

With Becky Granger's permission, I'm pleased to share the announcement below. Matt ----- Forwarded message from Becky Granger <rgranger(a)educause.edu> ----- From: Becky Granger <rgranger(a)educause.edu> Subject: [Dnssec-deployment] DNSSEC Launched Today by EDUCAUSE and VeriSign To: dnssec-deployment(a)dnssec-deployment.org, DNSSEC(a)internet2.edu, dnssec(a)educause.edu Date: Mon, 2 Aug 2010 11:06:01 -0600 Hello all - I wanted to let you know that DNSSEC is now supported in the .edu domain. Please feel free to pass the word! --Becky Becky Granger, CAE Director, Information Technology and Member Services EDUCAUSE - Uncommon Thinking for the Common Good (303) 939-0334 www.educause.edu EDUCAUSE Annual Conference - The best thinking in higher ed IT October 12-15, 2010 | Anaheim, CA www.educause.edu/e10 -----Original Message----- From: EDUCAUSE [mailto:educause@educause.edu] Sent: Monday, August 02, 2010 10:32 AM To: Staff Subject: DNSSEC Launched Today by EDUCAUSE and VeriSign FOR IMMEDIATE RELEASE Contact: Greg Jackson Vice President EDUCAUSE gjackson(a)educause.edu 202-331-5351 *********************************************** DNSSEC Launched Today by EDUCAUSE and VeriSign *********************************************** August 2, 2010, Boulder, Colorado--EDUCAUSE and VeriSign announced the deployment of a security system known as Domain Name Security Extensions (DNSSEC) within the .edu portion of the Internet, which EDUCAUSE manages under a cooperative agreement with the U.S. Department of Commerce. Institutions whose domain names end in .edu will now be able to utilize digital signatures to mitigate certain DNS security vulnerabilities, such as cache poisoning and man-in-the-middle attacks. The Domain Name System (DNS) is the part of the Internet that translates names such as "example.edu" into numeric addresses (for example, 198.59.61.90). All Internet applications-from electronic mail to online banking-depend on the accuracy and integrity of this translation. Over the years, Internet security experts have discovered a variety of ways that DNS translation may be compromised. The DNSSEC security system limits the problem by allowing owners of domain names to use digital signatures to add an extra level of authentication to the translation process. Deploying DNSSEC for .edu furthers the initiative to enhance domain name security throughout the broader scope of the internet. As a precursor to deployment, EDUCAUSE and VeriSign hosted a testbed environment which allowed end-to-end testing by selected .edu domain holders in a non production environment. Brian Voss, vice chancellor for IT and CIO at Louisiana State University and current chair of the joint EDUCAUSE/Internet2 Higher Education Information Security Council, noted, "I am proud that LSU is at the forefront of this exciting development and that our contributions and efforts as a testbed for .edu deployment have laid a foundation for the ubiquitous adoption of DNSSEC, so that the research and education community can eventually realize its full value," Voss also added, "DNSSEC represents an evolution in Internet reliability and security, and I know that my CIO colleagues recognize that our university communities expect our networks to be secure, and improving the security of our root Domain Name System through cryptography is something we all will embrace." EDUCAUSE President and CEO Diana Oblinger said, "EDUCAUSE has appreciated the opportunity to work with VeriSign and the U.S. Department of Commerce to advance the security and integrity of the Internet through early testing and deployment of DNSSEC. Dating from the creation of ARPANET through the present day, the higher education technology community has played a leading role in the development of the Internet as a platform for learning, discovery, and engagement. We have been happy to continue that role by being a lead partner in the launch of DNSSEC." Pat Kane, vice president of VeriSign, stated, "VeriSign's partnership with EDUCAUSE to test and deploy DNSSEC in the .edu domain demonstrates our ongoing commitment to a secure Internet infrastructure. VeriSign appreciates the close collaboration with EDUCAUSE and the U.S. Department of Commerce that allowed for success with this process and the opportunity to generate lessons learned which we are actively sharing with other domain registrars, thereby enhancing overall Internet security." ************************************* About EDUCAUSE EDUCAUSE is a nonprofit association and the foremost community of IT leaders and professionals committed to advancing higher education. EDUCAUSE programs and services are focused on analysis, advocacy, community building, professional development, and knowledge creation because IT plays a transformative role in higher education. EDUCAUSE supports those who lead, manage, and use information technology through a comprehensive range of resources and activities. For more information, visit www.educause.edu. ----- End forwarded message -----

1 0

Cisco ASR BGP within the box question
by Steven.Glogger＠swisscom.com 02 Aug '10

02 Aug '10

hi all just a short question (related to a quite new feature from cisco). with the new cisco ASR software (15.0(1)S - released some days ago) it is able to do BGP on the same box. we need this feature because we use the VASI interfaces to bring and filter traffic from one VRF to another VRF and performing firewalling (ZBF). basically we have on the box: [VRF_A via vasileft1]--[VRF_B via vasiright1] and the box itself speaks BGP on VRF_B with some RR's: [ASRBox] ---- (RR) ---- [anotherbox] the fun part is, if you want to announce (e.g. 0.0.0.0/0) from VRF_B (announced from anotherbox) to VRF_A it should be possible now with that new feature. according to BGP I need to configure the VRF_A peer as route-reflector-client so the routes from the anotherbox get reflected via RR to VRF_B. but, it seems that the router itself needs to be tricked, since he thinks that both peers are in the same route-reflector cluster ("DENIED due to: reflected from the same cluster"): Aug 2 13:35:03: BGP(0): 213.3.246.33 send UPDATE (format) 0.0.0.0/0, next 10.62.112.65, metric 0, path 44038 3303, extended community RT:65501:1702 Aug 2 13:35:03: BGP(0): 213.3.246.34 rcv UPDATE w/ attr: nexthop 10.62.112.65, origin i, localpref 250, metric 0, originator 10.62.112.65, clusterlist 10.62.112.79 10.62.112.17, merged path 44038 3303, AS_PATH , community Aug 2 13:35:03: BGP(0): 213.3.246.34 rcv UPDATE about 0.0.0.0/0 -- DENIED due to: reflected from the same cluster; Aug 2 13:35:03: BGP: 213.3.246.34 Modifying prefix 0.0.0.0/0 from 0 -> 4 address so, this is my config: config: <snip> interface vasileft1 ip vrf forwarding VRF_A ip address 10.0.0.1 255.255.255.252 zone-member security VASILEFT ! interface vasiright1 ip vrf forwarding VRF_B ip address 10.0.0.2 255.255.255.252 zone-member security VASIRIGHT ! router bgp 65501 address-family ipv4 vrf IABIP- bgp router-id 10.0.0.1 redistribute connected redistribute static neighbor 10.0.0.2 remote-as 65501 neighbor 10.0.0.2 update-source vasileft1 neighbor 10.0.0.2 activate neighbor 10.0.0.2 send-community both neighbor 10.0.0.2 next-hop-self exit-address-family ! address-family ipv4 vrf IACYP- import path selection multipaths bgp router-id 10.0.0.2 redistribute connected redistribute static route-map SET-PREFIX-SoO neighbor 10.0.0.1 remote-as 65501 neighbor 10.0.0.1 update-source vasiright1 neighbor 10.0.0.1 activate neighbor 10.0.0.1 send-community both neighbor 10.0.0.1 next-hop-self exit-address-family </snip> what does not works: - having another AS number on the same box (otherwise eBGP would be possible) - client-to-client reflection - magic stuff in route-map - setting different cluster-id's for different address-families - nothing found in the release notes: http://www.cisco.com/en/US/docs/ios/ios_xe/3/release/notes/asr1k_rn_3s_rel_… so, does anyone knows a nice hidden command to disable this cluster-checking on a per-peer basis or so? -steven

2 1