From iljitsch at muada.com Fri Sep 5 10:18:45 2003 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 5 Sep 2003 10:18:45 +0200 Subject: bgp behavior with exchange prefix in ebgp Message-ID: <91BBE3F7-DF79-11D7-A55A-00039388672E@muada.com> Dear EIXers, I thought I'd expand on my comments in the EIX session earlier this week. In a network that peers over an exchange, you'll see routes like this in the BGP table: Network Next Hop Metric LocPrf Weight Path *>i62.3.192.0/18 193.148.15.112 200 110 0 6728 i *>i62.8.128.0/17 193.148.15.209 110 0 9132 ? *>i62.12.128.0/17 193.148.15.224 1100 110 0 15623 i Note that the next hop points to an address that falls within the (old) AMS-IX peering LAN prefix. Since this router isn't directly connected to the AMS-IX, it needs to resolve this next hop: Routing entry for 193.148.15.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 Last update from 62.212.94.61 on GigabitEthernet1/0.1, 00:00:41 ago Routing Descriptor Blocks: * 62.212.94.61, from 62.212.80.68, 00:00:41 ago, via GigabitEthernet1/0.1 Route metric is 20, traffic share count is 1 So in this case the peering LAN prefix is announced over OSPF, so the next hop resolves correctly and all the traffic is sent to the next router, which is the one directly connected to the AMS-IX here. Now consider what happens when someone elsewhere announces the peering LAN prefix over EBGP (this is taken from route-views.oregon-ix.net): BGP routing table entry for 193.148.15.0/24, version 426250 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 3277 8482 28968 3246 1200 194.85.4.249 from 194.85.4.249 (194.85.4.249) Origin IGP, localpref 100, valid, external, best And: Routing entry for 193.148.15.0/24 Known via "bgp 6447", distance 20, metric 0 Tag 3277, type external Last update from 194.85.4.249 03:30:30 ago Routing Descriptor Blocks: * 194.85.4.249, from 194.85.4.249, 03:30:30 ago Route metric is 0, traffic share count is 1 AS Hops 5 The important part here is that the 193.148.15.0/24 prefix in OSPF has an administrative distance of 110, while the EBGP route shown here has a much lower administrative distance of 20. This means that the next hop address for the AMS-IX would resolve to an EBGP neighbor and all traffic to exchange peers is redirected over this neighbor! Now fortunately this only happens for routers that learn the peering LAN prefix over EBGP, so the impact is usually limited, but it's well worth the effort to filter out the peering LAN prefixes you connect to yourself. What happened this week at AMS-IX was even more fun: the new prefix for the peering LAN is a /23, but someone started to announce a /24 within that /24. (Probably typed ... 255.255.255.0 rather than ... 255.255.254.0, easy mistake.) The rule that kicked in now wasn't the relatively minor "EBGP has a lower administrative distance than IGPs" but the much heavier "longest match first" one. So in this case even the next hop resolved to an external route on the AMS-IX connected routers themselves, breaking the peering sessions. Iljitsch van Beijnum From gert at space.net Fri Sep 5 10:24:22 2003 From: gert at space.net (Gert Doering) Date: Fri, 5 Sep 2003 10:24:22 +0200 Subject: bgp behavior with exchange prefix in ebgp In-Reply-To: <91BBE3F7-DF79-11D7-A55A-00039388672E@muada.com>; from iljitsch@muada.com on Fri, Sep 05, 2003 at 10:18:45AM +0200 References: <91BBE3F7-DF79-11D7-A55A-00039388672E@muada.com> Message-ID: <20030905102422.Z67740@Space.Net> Hi, On Fri, Sep 05, 2003 at 10:18:45AM +0200, Iljitsch van Beijnum wrote: > Note that the next hop points to an address that falls within the (old) > AMS-IX peering LAN prefix. Since this router isn't directly connected > to the AMS-IX, it needs to resolve this next hop: Two ways to remedy this: - use next-hop-self on all iBGP peerings (which isn't always the perfect choice, but will easily fix these issues) - filter the exchange prefix(es) for all IXes that you participate *and all more specifics* on *all* eBGP sessions. This is strongly recommended even when already using next-hop-self (more specifics can break eBGP sessions at the IXP peering routers) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55575 (56535) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mike at linx.net Thu Sep 4 14:56:14 2003 From: mike at linx.net (Mike Hughes) Date: Thu, 4 Sep 2003 13:56:14 +0100 (BST) Subject: RIPE 46 Presentations Message-ID: Hi all, Most presentations from the RIPE 46 EIX working group are now available online at http://www.ripe.net/ripe/meetings/ripe-46/presentations/ If your presentation was not run from the RIPE supplied laptop, or does not appear on the above webpage, please email it to webmaster at ripe.net. Thanks, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike at linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" From andrei at ripe.net Mon Sep 22 11:34:06 2003 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 22 Sep 2003 11:34:06 +0200 Subject: Next phase in deploying anycast instances of k.root-servers.net Message-ID: <3F6EC20E.4040906@ripe.net> Dear colleague, After discussions at the last RIPE Meeting, we would like to clarify our current thinking about adding further anycast instances to k.root-servers.net. This message sets out the direction and further details the requirements for hosting such an instance and calls for expressions of interest from the Internet community to support this activity. I look forward to your support. Best regards, Andrei Robachevsky CTO, RIPE NCC General requirements and guidelines for expressions of interest for hosting a mirror instance of k.root-servers.net ============================================================== Introduction ------------ The RIPE NCC operates k.root-servers.net, one of the servers used as a name server for the DNS root zone. In order to further improve the distribution of the service in various Internet regions and its resilience against DDoS attacks the RIPE NCC is deploying mirror instances of the server worldwide as described in the ripe document "Distributing K-Root Service by Anycast Routing of 193.0.14.129" (RIPE 268). The first phase of this project included moving the cold standby instance of the server to service using anycast routing. This phase was completed in July 2003 and k.root-servers.net is currently deployed in two locations (LINX, London and AMS-IX, Amsterdam). The next phase will be mostly focused on the deployment of nodes with limited reachability in the RIPE NCC service region. The main motivation for this phase is: - Improving access to k.root-servers.net for a significant ISP community. - Isolating impact of an "external" DDoS attack. - Localising impact of a "local" DDoS attack. This document sets the direction and further details the requirements for hosting an instance of the k.root-servers.net server so that interested organisations may understand the general intentions and requirements of this phase of the project. Organisations wishing to express their interest in supporting this important activity may do so by following the guidelines below. Physical Sites -------------- Suitable sites for the location of mirror instances of the k.root-servers.net server will in most cases include an Internet exchange (IX) that offers a very high standard of infrastructure and Internet connectivity. The members of the IX should represent a significant ISP community in the region. In terms of physical infrastructure and services, a hosting site must satisfy the general requirements for root server locations, which are described in section 3.1 of RFC2870. Server Hardware --------------- All hardware for the instance of k.root-servers.net will be supplied at the host's expense. In most cases a typical configuration will be assembled by the RIPE NCC and shipped to the hosting site. The hardware will remain the property of the host, but will be operated solely by the RIPE NCC. The host will be asked to provide onsite physical support. However there is no requirement for the host to perform maintenance on the systems themselves, and administrative access will not be available. Connectivity and reachability ----------------------------- Though global reachability is not required for the instance of the k.root-servers.net server, it is critical that access to the server is provided in an open and non-discriminative manner to all members of the IX. However, it is important that global transit is co-ordinated with the RIPE NCC. Requirements for reachability are different for the management network of k.root-servers.net that is used by the RIPE NCC to perform system administration. It is required that connectivity of the management network is global and reliable. Expressions of Interest ----------------------- The RIPE NCC invites expressions of interest from organisations such as Internet Exchanges or other organisations that represent a significant ISP community in the region. Expressions of Interest should include details of the support which is being offered, such as hosting and connectivity. Please provide as much detail as possible, including physical infrastructure details, upstream and peer network connectivity details, and bandwidth availability. Please refer specifically to the provisions of RFC2870 in your response. Please send expressions of interest to: k-anycast at ripe.net If any further information is required, please also use this address. From carsten at ripe.net Fri Sep 26 16:27:29 2003 From: carsten at ripe.net (Carsten Schiefner) Date: Fri, 26 Sep 2003 16:27:29 +0200 (CEST) Subject: ISC installed an f.root-servers.net instance in Johannesburg Message-ID: <200309261427.h8QERTgF024139@birch.ripe.net> All, only remotely related (not in the RIPE region) - however, may still be of some interest as we had three presentation on this very topic during RIPE 46, furthermore the box is installed at JINX, the Johannesburg Internet exchange. http://www.itweb.co.za/sections/internet/2003/0309260853.asp Regrads, Carsten