June 2000 - Test - lists.nanog.org

Re: exchange point media (was: Re: MAE-EAST Moving? ...)
by Martin Cooper 23 Jun '00

23 Jun '00

Alex Bligh <amb(a)gxn.net> writes: > LINX also runs mixed media (sadly) - FDDI and more sane things (GigE > and Fast Ethernet). The switches here fragment when switching toward > Fast Ethernet. They would certainly move >1500 byte pings between > FDDI ports, but I have no FDDI ports now to test whether this works > with DF set (i.e. it doesn't fragment FDDI to FDDI), nor whether > ICMP is *ever* generated. Maybe I'm being ultra-thick here, but what business do layer-2 devices have looking at the contents of layer-3 packet headers and acting on what they find there? I thought the whole point of building IXPs at layer-2 was to leave layer-3 policies to the participants - if not then one might as well start building IXPs with routers surely? > However, I believe best practice at LINX is, and perhaps should > be elsewhere, to set MTU on your FDDI interfaces to that supported > by ethernet. Given most exchanges started with ethernet and worked > upwards, this should have been best practice everywhere from teh > start. This seems to me to be exactly the right thing to do in the context of exchange point fabrics composed of mixed MTU media, irrespective of the presence or absence of such schizoid layer-2 devices as those that have been discussed here. M.

1 0

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

23 Jun '00

--- Danny McPherson <danny(a)tcb.net> wrote: > > > 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. I know that some ISPs have been doing that but that is not good enough. The key is to have EVERY ISP do it to leave no 'holes' for bad routes to sneak in. And that's the model suggested in the paper. > > 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. Agree. The ideal situation is to filter on all interface where external routes come in i.e. filter on peers and customers. I used to work for an ISP (ANS) who filtered all its peers and managed to automatically generate router configurations including huge no. of prefix filtering lines. It did help us to dodge the disaster of AS7007 and other similar incidents. However, it does introduce a lot more work. Also, the toughest part is how often to update the filtering list so no legitimate prefixes be blocked. How big a filter list a router can handle in its configuration is something needs to be investigated since number of prefix lines will be huge for peer to peer filtering. In conclusion, the best is for ISPs to filter on peers and customers. But if they can not do that for peers, at least filter on customers. If all ISPs filter its customers, it's already a big step forward. > > And if every ISP performed SA verification between > one another > (presumably with the same filters) it would again be > improved "a > lot" more. > > -danny --jessica > > > 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 > > __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/

1 0

RE: Generally accepted announcement sizes
by Mike Heller 23 Jun '00

23 Jun '00

The 216.73.19.128/25 is a legacy network that I am renumbering off of. I agree that it is too small of a network to be seen consistently. When my verio connection went down the other day, the 165.254.159/24 netblock did not appear in the cerf routeserver and verio wasn't seeing my announcement at all either. It seems that they filter announcements from 128/8 to the /19 and larger thereby filtering my announcement out. The above two are my office networks. The 209.10.180/24 is my production network and I peer directly with GBIX, UUnet, and SPrint. I had no problems there. Thanks for your input, Mike -----Original Message----- From: Kai Schlichting [mailto:kai@pac-rim.net] Sent: Thursday, June 22, 2000 7:33 PM To: Mike Heller Cc: 'nanog(a)merit.edu' Subject: Re: Generally accepted announcement sizes 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

ATM resources?
by Steve Hardin 23 Jun '00

23 Jun '00

Hi, I was hoping someone good point me to some resources in the form of books on ATM. This would be for voice as well as Data? This would be for a real world implementation. Regards, Steve

3 2

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