- Test - lists.nanog.org

Re: using IRR tools for BGP route filtering
by Danny McPherson 23 Jun '00

23 Jun '00

> This is not our experience, and yes, we filter customers *and* peers. > (We have a few peers we don't filter other than sanity-wise, but this > is a limitation of config file size, not performance. Plus, a couple > of Tier-1 networks don't register or don't publish as-sets.) Configuration size is certainly one of the issues, yes. I guess some providers are more concerned with BGP convergence than others. I for one think 4-5 minutes to pickup a full BGP table from a single peer when doing nothing else -- and withOut any filter lookups, is a bit much. > We have been requiring customers to register, for BGP customers, since > we started offering IP transit, and have built filters for customer from > RADB and other public registries from day one. Good practice. Unfortunately, it still doesn't provide safety when one of your peers advertises a network that they're not supposed to. > Obviously, when it comes to the data plane, filtering should be done > at the edge, for scaling reasons. Though this requires providers to rely on other providers to ensure their availability, something many providers would rather not do. > Filtering based on registries is a hack - the real issue of trust, of > originators of routing information, is better managed through an end-to-end, > top-to-bottom, but scalable, delegation and signature method, using such > mechanisms as are under discussion in various IETF wg's on secure BGP. SBGP. Ha. Did you perhaps consider the performance implications of this? And the requirement for de-aggregation or hierarchal signatures? And the fact that today it'd take pretty much an entire 24-hour period for one router to verify a full Internet routing table from a single peer? And that'll scale? I'd suggest we stick to some registry/pre-population of policies mechanisms. It's interesting that for quite a while nearly 30K PSTN 800 numbers were allocated nearly every week, with number portability and all. Perhaps we're simply missing something :-) > There is still the issue of the boot-strap route required for root name > servers... :-) Among those the requirement for routers to actually have cycles to populate forwarding tables and forward packets, something they probably wouldn't be doing if they were running SBGP. > In fact, the end result is non-propogation of bogus routing information. > If only a few more big networks would do this, the risk to the net in general > would be substantially reduced. I'll again site the www.cisco.com incident from a few months back. The announcement was originated from a large provider that performs prefix-based filtering on all customers. I can speculate that your customers as well were affected by this. -danny

2 1

Re: Generally accepted announcement sizes
by Kai Schlichting 22 Jun '00

22 Jun '00

At Thursday 05:35 PM 6/22/00 , Tony Tauber wrote: >On Thu, 22 Jun 2000, Mike Heller wrote: > > > > Can anyone point me to a centralized resource for Tier 1 and Tier2 > > providers' accept policies? I have found that when some of my circuits go > > down various parts of the 'Net become unreachable and I attributed that to > > the size of that announcement being a /24. I assume that the carriers I'm > > having issue with are not using RADB as I registered all of my netblocks, > > >To find out exactly why your multi-homing set-up isn't working, >I'd work with your providers' operations staff. Perhaps set up >a time to test the fail over with them on hand to help you analyze >by looking at the routes on both. It should be possible for them >to help check the behavior of traffic over a third provider as well >if the providers are worth their salt. A rather complex setup on their side, as far as I can tell from route-server.cerf.net, route-views.oregon-ix.net and route-server.ip.att.net: iwon.com is AS 14829, and they seem to announce 3 networks: They announce 165.254.159.0/24 to AS 2914 (Verio) and AS 1785 (AppliedTheory) At the Oregon IX, the path via Verio is seen 15 times, via AT only 2 times. That's is an indicator of connectivity (and likely density of interconnectivity of providers to Verio vs. AT) right there. It's more balanced 5:4 (Verio:AT) at AT&T's route view. They announce 209.10.180.0 to AS 701 (UUnet), 4513 (PFM/Globix), 1239 (SL). At the Oregon IX, this is seen somewhat balanced between the 3, but at AT&T, it's 8 paths to UUNet or SL, only one path to PFM/Globix. They announces 216.73.19.128/25, which is solely seen through AS 2914 (Verio) at the Oregon-IX, and only 4 times at that. As expected, Verio seems to accept this as a customer route, but few of their peers accept the /25, Note that AT&T and CERF.net are not seeing this specific, but they see the larger /18 aggregate from AppliedTheory only, which is probably what 90% of all traffic to this network . It's a wonder that the /25 is seen at all: I think it should be withdrawn for sanity's sake. So, what exactly are you trying to accomplish, Mike? One thing is clear: the third network will always receive most traffic from AT, the second one mostly from UUnet+Sprint, the first one (which I believe you are referring to) mostly from Verio. The right way to overcome this is likely not to play with BGP toys like AS_prepend or making your providers manipulate the local_pref for you (and I see that Verio and UUnet don't seem to be crossing paths, at least for the first network listed), but by utilizing bigger networks: /22's in the >204.0.0.0/8 space are looking damn good in terms of 'being heard' compared to /24's. Did I mention that Verio seems to be the only one filtering at /20 boundary in 62/8 and 63/8 ? As a customer, you won't have that problem, obviously. bye,Kai

1 0

Re: Generally accepted announcement sizes
by Mufti Ahmed 22 Jun '00

22 Jun '00

Mike what does RADB mean? thanks Mufti Nayeem Ahmed Network Systems Engineer Market Data Networks Reuters America Inc. (212)-603-3595 1-800-2REUTER 1-800-PAGE-MCI pin# 1569803 Can anyone point me to a centralized resource for Tier 1 and Tier2 providers' accept policies? I have found that when some of my circuits go down various parts of the 'Net become unreachable and I attributed that to the size of that announcement being a /24. I assume that the carriers I'm having issue with are not using RADB as I registered all of my netblocks, Thanks, Michael Heller iWon.com ph 914.826.2007 fx 914.591.0205 ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

3 2

CALEA update
by Chip Sharp 22 Jun '00

22 Jun '00

At NANOG 19, I gave a short talk on CALEA. The contributions for next week's CALEA JEM can be found at: http://www.tiaonline.org/standards/CALEA_JEM/contributions.cfm The FBI has submitted a contribution, but it is not on the web page yet. If anyone else on the list is attending, please let me know. Thanks, Chip ------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org -------------------------------------------------------------------

1 0

Re: Generally accepted announcement sizes
by Danny McPherson 22 Jun '00

22 Jun '00

There are a few points worth reiterating with this model, most of which Tony has already touched on. To function properly: o This requires that one of your two providers allocate the space and announce the aggregate locally, as well as propagate the more-specific learned from the customer. o This requires that the owner of the aggregate accept the announcement of the more specific from the second provider as well. o This requires that the customer doesn't have a problem with traffic being routed solely via the primary provider when considering peer networks who reject the more-specific advertisement from the secondary provider. o This requires that the customer doesn't have a problem with suboptimal routing to the secondary provider via the primary provider when problems occur, and that the primary provider imposes no policies that would disallow this. o This model of redundancy also assumes that some type of Byzantine failure with routing internal to the primary providers network is not of concern (hrmm..). Of course, if any of these are problems, then the whole issues becomes, well, slightly more interesting... -danny > Here's the deal. If you number out of Provider1's CIDR block > but advertise your more-specific to Provider2 and the two Providers > touch and Provider1 accepts the more-specific route from Provider2, > you should have no problem reaching anyone. > > Here's the reason: Everyone accepts Provider1's announcement of the block. > When your link to P1 is up, any traffic they recieve for your prefix > gets routed over that link since they carry your more-specific internally. > However, if other providers here the more-specific from P2, they'll > send directly via P2 who sends it over the link to you. > If your link to P1 goes down, P1 won't see the direct route to you > but should see the route via P2 if P1 is accepting it. (Some > may either block the announcement or have anti-spoofing packet filters > at their borders that block the traffic itself).

1 0

Re: Generally accepted announcement sizes
by Brantley Jones 22 Jun '00

22 Jun '00

At 05:03 PM 6/22/2000 -0400, you wrote: >Can anyone point me to a centralized resource for Tier 1 and Tier2 >providers' accept policies? I have found that when some of my circuits go >down various parts of the 'Net become unreachable and I attributed that to >the size of that announcement being a /24. I assume that the carriers I'm >having issue with are not using RADB as I registered all of my netblocks, > >Thanks, > >Michael Heller >iWon.com >ph 914.826.2007 >fx 914.591.0205 I have been told that some Tier 1's peering agreements ensure global routability with these providers that normally filter /24's. Who are your providers? Brantley

1 0

Generally accepted announcement sizes
by Mike Heller 22 Jun '00

22 Jun '00

Can anyone point me to a centralized resource for Tier 1 and Tier2 providers' accept policies? I have found that when some of my circuits go down various parts of the 'Net become unreachable and I attributed that to the size of that announcement being a /24. I assume that the carriers I'm having issue with are not using RADB as I registered all of my netblocks, Thanks, Michael Heller iWon.com ph 914.826.2007 fx 914.591.0205

2 1

Re: Generally accepted announcement sizes
by Danny McPherson 22 Jun '00

22 Jun '00

The providers I'm aware that perform filtering of this sort normally do so based on the length of allocations from the RIRs (ARIN, APNIC & RIPE) within the associated address blocks. These polices have little to do with the RADB (Routing Arbiter Database) or other IRRs. Of course, if inter-provider filtering were feasible the specific route objects would be obtained from the RIRs and pretty much any correctly registered route (of a "more reasonable than today" length) would probably be accepted by those providers. Consulting the allocation guidelines for those specific RIRs should help answer your question. Consulting the "ISP Resources" section of the NANOG web server should provide useful information regarding specific filtering policies implemented by a few ISPs. -danny > Can anyone point me to a centralized resource for Tier 1 and Tier2 > providers' accept policies? I have found that when some of my circuits go > down various parts of the 'Net become unreachable and I attributed that to > the size of that announcement being a /24. I assume that the carriers I'm > having issue with are not using RADB as I registered all of my netblocks,

1 0

Re: (fwd) FW: Duff root nameserver
by Michael Shields 22 Jun '00

22 Jun '00

So, is there a public mailing list or web page where there are maintainence and outage notifications relating to the root and gTLD servers? Every time there is a problem, the best source of information seems to be secondhand reports on NANOG. There must be a better way. -- Shields.

2 1

Re: using IRR tools for BGP route filtering
by Danny McPherson 22 Jun '00

22 Jun '00

I agree with this, and have seen the document, and have worked for large providers that performed prefix filtering on customers long before IOPS existed. However, if every ISP performed prefix-based filtering between one another, it'd be improved "a lot more". I recall more than a few instances when providers inadvertently broke other providers customers by "mis-advertising" prefixes. And if every ISP performed SA verification between one another (presumably with the same filters) it would again be improved "a lot" more. -danny > If every ISP does prefix based filtering on its > downstream customers, the integrity of the Internet > routing system will be improved a lot. The document > below proposes such a model: > > http://www.iops.org/Documents/routing.html

2 1