- NANOG - lists.nanog.org

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

a.gtld-servers.net
by Newell, Tom 22 Jun '00

22 Jun '00

The Network Solutions Registry identified a problem with one of its generic Top Level Domain servers (a.gTLD) that caused negative responses to some DNS lookups for the com zone only between 00:30 and 9:30 EDT on Thursday, 6/22/2000. Although the problem has been resolved, DNS name servers with MAX-NCACHE-TTL parameter set to anything other than the default value may need to have named restarted to correct any possible negative responses to valid domain names. Mark Rippe VP, Operations Tom Newell VP, Registry DNS Programs

1 0