June 2000 - Test - lists.nanog.org

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

Re: exchange point media (was: Re: MAE-EAST Moving? ...)
by Jeff Haas 22 Jun '00

22 Jun '00

I was heard to say a few days ago: > Please be aware that any traffic passing through FDDI XP's using > DEC gigaswitches is biased. These switches break path mtu discovery. This was in the context of measuring packet size in the Internet. After receiving a couple notes asking for clarification, I figured it was worthwhile to pass the same info back on to NANOG. Should one install a (fast|gig)ethernet card into one's Gigaswitch and said switch have FDDI interfaces, the switch will go from having a 4500+ byte MTU to a 1500 byte MTU. This is even between FDDI card to FDDI card on the same switch. The switch will happily fragment the packet if you leave DF off. However, if you turn it on, the switch will drop the packet silently. The switch is unable to generate ICMP and route it back to the sender. Given all of this, PMTU-D breaks in these circumstances. This is important because at least two XP's that I run route server service experienced problems due to this - Mae-West and PAIX. PAIX solved the problem by heavily encouraging customers to get off the Gigaswitch - I don't know if its still in service. Mae-West (SJ) still has this issue to the best of my knowledge. Mae-West (NASA) has been migrating to a SSR fast ether network to get off the Gigaswitches. Collectively, Mae-West still has this issue when transiting across the bridge. So, to make a long story short, try some PMTU probes on your switched fabric before trusting statistics about packet sizes. IM(probably undereducated)O, larger MTUs are not going to do you a lot of good across public exchange point fabric for a long time to come. Large MTU's across private interconnects, or specially targeted interconnects between "Service Providers" will probably be of greater benefit. -- Jeffrey Haas - Merit RSng project - jeffhaas(a)merit.edu

3 2

Re: using IRR tools for BGP route filtering
by Jessica Yu 22 Jun '00

22 Jun '00

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 --Jessica --- Danny McPherson <danny(a)tcb.net> wrote: > > > > i emphatically DO NOT think that large providers > should filter other > > peers. i think the large providers should filter > their own announcements, > > by carefully verifying what a downstream wishes to > announce before > > accepting it, filtering the customer > announcements, and aggregating their > > announcements to peers. > > I believe Randy's point is that it'd be really nice > to filter prefixes > learned from peers, but even if the routing > databases were up to date, > reliable and useful, the routers can't perform the > policy matches against > filters fast enough. > > And I agree completely. The fact that pretty much > any network with an > AS number could take any Internet subnet completely > offline in a matter > of -- what, ~8 minutes(?), intentionally or > unintentionally, well, > I think it's pretty amazing. The only way a service > provider can protect > their customers from this is by applying > prefix-based filtering to all > their peers. > > > Of course, this requires valid, accessible, up to > date IP registration > information. It also routers that can store > hundreds of thousands of > lines of policies. Then, the routers have to be > able to perform matches > on the policies when processing updates. All this > is at the "control > plane". > > Then, ideally, the routers would be able to utilize > the same set of > policies to perform packet filtering functions in > the "data plane", > which is even more interesting. > > These two components alone would make the overall > Internet > infrastructure far more reliable and secure than it > is today, > no doubt. > > > i think its silly to try and regulate the world > from ones own corner. > > regulate your corner, and encourage others to do > the same. i don't care if > > said encouragement is by tacit agreememnt, or > bound up in legealese in > > peering agreements. > > I don't think it's silly at all to regulate the > policies one employs in > in their network in order to increase overall > destination availability > to ones customers. Policies of this nature only > require support of the > network that implements them. Other than requiring > peers to keep registry > information up to date, they impact the peer > networks no way whatsoever. > > -danny > > > __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/

1 0

Re: using IRR tools for BGP route filtering
by Sean Donelan 22 Jun '00

22 Jun '00

I believe every major backbone has suffered a multi-hour service disruption due to another provider announcing blackhole routes. The most recent one was Sprint a couple of weeks ago when another major provider re-announced part of their network in Chicago. Its not just a risk from "small" providers like 7007. Most of the widely distributed bogus announcements pass through large providers like Spring and UUNET. Most bogus announcements only affect a single network customer, like the FCC web site, so some people just assume its usual Internet flakiness when they can't reach a network. Its strange to see carriers whose management wouldn't think of ignoring the LERG, believe its ok to risk extended service disruptions by announcing and listening to unfiltered, unauthenticated routing information. Are engineers keeping their managers' in the dark. Does management not know there is a potential solution to the problem. Or does their management really think its Ok their customers are at risk of losing service at any time due to unfiltered routes. When you speak with your Cisco sales rep, do you tell them one of the requirements is being able to filter the entire route table with multiple peers.

9 12

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

22 Jun '00

> AS Path filtering would be much smaller than prefix based filtering. > Perhaps small enough to work on existing routers. These filters could also > be built using registry data, from the ASes that make up providers' as-macros. > Not a silver bullet, but probably significantly better than doing > nothing. Though it's certainly better than nothing, it does little more than ensure AS_PATH sequence and integrity .. it provides no protection against invalid announcements. -danny

1 0

Re: [apops] Re: RIPE NCC CIDR blocks - smallest allocations
by Mark Prior 22 Jun '00

22 Jun '00

http://www.apnic.net/db/RIRs.html . Interesting but it doesn't contain the data in Joao's posting nor does it contain the equivalent data from the other registries. Mark.

1 0