May 1998 - Test - lists.nanog.org

Xylan??
by kbrown＠primelink.com 28 May '98

28 May '98

I know this is off topic, but had someone in the office today trying to sell us on some Xylan switches? Anyone have any prior experience with these products? Please respond in private email only.

1 0

Re: 165.138.0.0
by Sean Donelan 28 May '98

28 May '98

>So is your rant about Sprint's filtering a macro by now? > >Or are you hoping that sheer repetition will somehow "fix" what >you perceive to be an evil conspiracy? Never attribute to duplicity what can be explained by stupidity. I'm perfectly willing to take Sprint at its corporate word. But if so, the same reasoning why sprint filters non-customer routes would apply to other ISPs filtering sprint customer routes. If sprint doesn't want to change its policy, its up to the sprint NOC to assist its customers to meet identical terms and conditions "Addresses not meeting the addressing filters, must either qualify for a larger chunk fo non-provider-assigned address space or get aggregatable address space from their immediate provider(s) and renumber their hosts into it." Renumbering is easy, everyone has to do it, even Sprint customers. Unless you are advocating that Sprint be treated to special conditions. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Transit Routing
by Ehab Hadi 28 May '98

28 May '98

There is a very valable book dedicated for BGP4: Internet Routing Architectures By Halabi, Bassam; Softcover; 477 Pages Published by Cisco Press; 04/1997; ISBN: 1562056522 On-line Ordering: http://www.cbooks.com/sqlnut/SP/search/gtsumt?isbn=1562056522 Ehab Hadi ehabh(a)nortel.ca >From owner-nanog(a)merit.edu Thu May 28 11:21:32 1998 >Received: from localhost (daemon@localhost) > by merit.edu (8.8.7/8.8.5) with SMTP id NAA24073; > Thu, 28 May 1998 13:48:47 -0400 (EDT) >Received: by merit.edu (bulk_mailer v1.5); Thu, 28 May 1998 13:47:44 -0400 >Received: (from majordom@localhost) > by merit.edu (8.8.7/8.8.5) id NAA23921 > for nanog-outgoing; Thu, 28 May 1998 13:47:43 -0400 (EDT) >Received: from home.merit.edu (home.merit.edu [198.108.60.42]) > by merit.edu (8.8.7/8.8.5) with ESMTP id NAA23917 > for <nanog(a)merit.edu>; Thu, 28 May 1998 13:47:36 -0400 (EDT) >Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id NAA16557 for nanog(a)merit.edu; Thu, 28 May 1998 13:47:35 -0400 (EDT) >Received: from fstop.shutter.net (root(a)fstop.shutter.net [209.14.1.1]) > by merit.edu (8.8.7/8.8.5) with ESMTP id JAA16061 > for <nanog(a)merit.org>; Thu, 28 May 1998 09:33:23 -0400 (EDT) >Received: from root (root.unixnet.org [209.14.1.6]) > by fstop.shutter.net (8.8.5/8.8.5) with SMTP id JAA30034 > for <nanog(a)merit.org>; Thu, 28 May 1998 09:33:19 -0400 >Message-Id: <199805281333.JAA30034(a)fstop.shutter.net> >From: "John Golovich" <john(a)shutter.net> >Organization: ShutterNet >To: nanog(a)merit.org >Date: Thu, 28 May 1998 09:36:54 +0000 >MIME-Version: 1.0 >Content-type: text/plain; charset=US-ASCII >Content-transfer-encoding: 7BIT >Subject: Transit Routing >Reply-to: john(a)shutter.net >References: <Pine.BSF.3.96.980527224232.2395B-100000(a)iago.nac.net> >In-reply-to: <Pine.BSF.3.95q.980528070230.2972A-100000(a)thuule.pair.com> >Sender: owner-nanog(a)merit.edu > >Can someone point me in the direction of some good white papers where >I could pick up some knowledge on BGP specifically in regards to >transit routing. > >I am working with 3 local ISPs here all connected to different >backbones. We are all going to be peering at one central office with >T-1 lines running between each location. > >Our intention is to allow each others traffic to flow through whoever >is the closest route. However I have only recently gotten into BGP. > >Any help is appreciated. > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: 165.138.0.0
by Sean M. Doran 28 May '98

28 May '98

So is your rant about Sprint's filtering a macro by now? Or are you hoping that sheer repetition will somehow "fix" what you perceive to be an evil conspiracy? Sean.

1 0

Re: Why does Sprint have address filters again?
by Sean M. Doran 28 May '98

28 May '98

| If someone is asking now, the answer is that the | registries (ARIN didn't even exist at the time Sprint began filtering) | had no involvement other than to request that Sprint lower their filters | from a /18 to a /19. That is also my recollection. Sean.

1 0

Re: 165.138.0.0
by Aaron Branham 28 May '98

28 May '98

I got two nice replies from Sprint. They won't change their filtering policy overnight but they are at least considering it. I think they're interested in listening to customers on the issue, but please don't spamm or rant......hey if they do change it I might resubscribe to nanog :) I removed their email addresses because they didn't post it to nanog. Date: Thu, 28 May 1998 16:08:46 -0400 From: -removed- @sprint.net To: Aaron Branham <abranham(a)ind.net> Subject: Re: 165.138.0.0 Aaron, We have been talking internally about changing the policy for some time now. We are trying hard to figure out what really makes sense. With our entire core network made up of GSRs, we are capable of handling very large routing tables. I think the original intent of the policy was valid, even though it was unpopular. You are right, times have changed, and it may be the time to change the policy. Rational feedback from customers, such as you, as well as others in the industry will play heavily in our decision. However, don't look for it to happen over night as the result of some thread on nanog. Thanks again for your comments. ------------------------------------------------------- Date: Thu, 28 May 1998 16:01:48 -0400 (EDT) From: -removed- @sprint.net To: Aaron Branham <abranham(a)ind.net> Cc: SEAN(a)SDG.DRA.COM Subject: Re: 165.138.0.0 I don't want to get into a religious war over filters and our policy in that respect (especially on email :-). I just wanted to say that I did clean up the 129.122/16 as much as possible. The reason we don't just have one route in there is that the customer has multiple circuits with static routes. - - Aaron Branham [AKB8] (a(a)ind.net) <Phone# 317.263.8976>

1 0

NANOG 13 INFO
by Pam Ciesla 28 May '98

28 May '98

We'd like to take this opportunity to thank folks in the community who have significantly contributed resources to this NANOG. Thanks to Bay Networks for providing the network equipment allowing us to provide several hundred hub ports in the main room and the terminal room. Thanks to Cabletron for providing wireless access head ends for the meeting. The University of Michigan Information Technology Division will be providing a handful of machines for the terminal room. Thanks to the Real Broadcast Network (RBN) for casting the NANOG 13 meeting over the net. Thanks also to Cisco for providing the equipent and resources to cast the meeting using the MBone. And finally, thanks to Aptis, Bay, and Cisco for funding the beer-n-gear event Monday evening. Bill -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (734) 764-9430 (New Area Code) NOTE: NANOG Registration payment cutoff is Friday, 5/29 at midnight payment of $150 is due. The registration fee after the 29th will be $170 and the cancellation fee is $20. If you call with payment info my voicemail is secure so please leave a message and speak slowly. The attendee list on the webpage has been updated. Please look there first if you are not sure that you have paid. Thanks ---------------------------------------------------------------------- Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 -----------------------------------------------------------------------

1 0

Re: ingress filtering
by Jared Mauch 28 May '98

28 May '98

The great thing about the CC images released by cisco (as long as you're running with ip cef or ip cef dist), you can turn this neato command on your interfaces to your customers: ip verify unicast reverse-path This automatically does filtering based on your local routers routing table. This means you can take a customer connection and filter them. You will encounter problems if they are multihomed and have netblocks that you don't route directly to them, but you can make those changes later as they multihome. We've had a few problems with our customers and doing this, when we don't route all their address space, but this is easily fixed. Asymetrical routing is an evil you have to live with and adjust to, so if you have more than one upstream, I would not apply such filters to those interfaces. I would recommend that everyone who has the ability to do this on their routers do so. This will help many possible problems. If we can get enough people to make this part of their default configuration (such as no ip directed-broadcast is these days) on their ports to customers, we could prevent many DoS attacks. If you have dialup lans (ie: mci, uunet, etc.. who have big public dialup pools) PLEASE filter these, as well as the smaller providers out there. - jared > > On Thu, 28 May 1998, Mr. Dana Hudes wrote: > > > > > Who *does* do ingress filtering? I have it on our border routers > > > and customer connect ports. We have transit from MCI and UUNET. > > > Neither has ingress filters -- see below message from MCI on > > > this. > > > > > > Subject: Re: RFC1918 addresses from MCI > > > Date: Thu, 28 May 1998 08:16:23 -0700 > > > From: security(a)mci.net > > > To: dhudes(a)graphnet.com > > > CC: security(a)mci.net > > > > > > Mr. Hudes, > > > > > > > > > Thank you for your note. MCI does not currently source filter > > > address > > > space at it's ingress points. Addresses sourced from > > > non-routable or > > > invalid addresses are not blocked or filtered. Addresses > > > destined to > > > non-routable addresses spaced are not routed. > > > > > > If you think it is a security issue and it is on-going then > > > please > > > contact us with the target address so we can investigate. -- Work: jared(a)qual.net - We Make The Internet Work for Your Business 9-5pm(ET) 800 637 4424x2634 - 24x7 NOC - 800 424 3223 pgp key available via finger from jared(a)puck.nether.net

1 0

Re: 165.138.0.0
by Sean Donelan 28 May '98

28 May '98

>This provides the greates redundancy for our customers. Sprint's policy >does not apply to customer routes so they do not filter at the /16 level >for classic B addresses. (They do for everybody else though....) Tell me once again, what is Sprint's justification for applying these filters to everyone else? If it is for a noble purpose to save the entire Internet from collapse, why isn't it a good idea for Sprint's customers to do the same? If it is for anti-competitive reasons, to encourage people to buy service directly from Sprint to get around the filters, then I'm willing to offer identical terms and conditions for non-customers. Neither IHETS nor SPRINT is a DRA customer. Doesn't the State of Indiana have a competitive bidding system? Isn't it possible that one day, IHETS may no longer be a customer of Sprint? >we'll re-announce the /16 from at least one of the POPs. But in order to >make sure the /16 is always routable we'll have to advertise it from >every POP that has a /20 or /19 sub address. Otherwise if the one POP >advertising the /16 goes down our customers on the noted networks will >loose connectivity to your network. (We'll also have to put in a /16 >static route to overide the null0 that BGP will inject into our routing >tables.) It was much cleaner to just advertise the /19's and /20's >without the /16 but we can (and I guess will have to unless you change >your filters) do it the other way. By cooperating with your upstream ISPs, you can use several methods, such as proxy aggregation, announcing more specifics inside SPRINT, and only announcing the larger block elsewhere, you can achieve a high degree of reliability without propagating tiny CIDR blocks world-wide. Why does Sprint have these filters? Once again, I'd be happy to change my filters on the same terms and conditions as SPRINT. SPRINT could become a customer of DRA. SPRINT could change their filters to not apply to non-customers. IHETS could become a customer of DRA. There are lots of alternatives. But if prefix-length filters are a good idea, they should be a good idea for everyone. Otherwise it is hypocritical to only apply them to non-customers?

1 0

RE: 165.138.0.0
by Aaron Branham 28 May '98

28 May '98

On Thu, 28 May 1998, Sean Donelan wrote: > >The purpose of the /20's and /19's on our 165.138.0.0, 165.139.0.0 and > >157.91.0.0 networks was to provide better service to our customers and to > >try and save IP address space for others. Like some of the class A's > >above we treated these as CIDR blocks instead of going to our upstream > >providers or the ARIN to get more addresses. Because our network has > >a dozen pops thoughout the state and each has at least one upstream > >connection to Sprint and MCI we advertise them as the /19's and /20's. > >This provides the greates redundancy for our customers. Sprint's policy > >does not apply to customer routes so they do not filter at the /16 level > >for classic B addresses. (They do for everybody else though....) > > Sure. It makes sense. Just have sprint change their policy about > filtering non-customers, and I'd be happy to do the same. Otherwise it > seems a bit hollow to say Sprint's filters are saving the Internet from > collapse when they allow they customers do do the exact thing they > are telling everyone else is a bad idea. > > Of course, it does lock you into SPRINT for all times, since if you > ever become a non-customer, they will begin filtering your routes no > matter how sensible the idea. I'm a customer of Sprint and I can say two things, one they have gotten a lot better this year in overall quality of service and two their filtering policy is very outdated & Sprint's customers seem to have the most violations of the policy. It does appear that the policy is enforced with peers like MCI and UUnet on routes Sprint learns from them, but not visa versa. Looking quickly over the MCI, ANS, and UUnet routes (via 'show ip bgp neighbor x.x.x.x received-routes') I see the Sprint AS's pop up in a lot of the CIDR routes, (/24 - /19) esp in the old class B range (look at 129.122.0.0.) Sprint's got GSR's now and they haven't had any network wide BGP flaps like they did a 12-18 months ago, even though the current policy was used at that time. Because of the shortage of IP addresses I think your going to see a lot more attempts to squeeze CIDR blocks out of the remaining class A's and B's, if we use them we'll have addresses for a couple of more years. (might even cut the routing tables if people can stand renumbering and turning in their /19's and such for a /16, /15, /14 or so.....) As a customer I'm asking Sprint to pull the filters on non-customers. I'd urge other customers to do the same. ------ P.S. Sean, I took a /20 that we haven't used yet and just advertised it to MCI - the route didn't make it into the Sprint tables. But it also didn't make it into your network even though it appears that you have a direct connection to MCI.....are you using the same filter on MCI? If so are you having problems getting to some of the networks I mentioned in my other email? INDY1#traceroute Protocol [ip]: Target IP address: 150.147.1.1 Source address: 165.138.16.254 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to StLouis21-e1.dra.net (150.147.1.1) 1 bordercore4-hssi6-0-2.NorthRoyalton.mci.net (166.48.234.9) [AS 3561] 300 msec 272 msec 32 msec 2 core1.NorthRoyalton.mci.net (204.70.4.205) [AS 3561] 20 msec 28 msec 24 msec 3 core-hssi-2.Chicago.mci.net (204.70.1.93) [AS 3561] 32 msec 28 msec 32 msec 4 border4-fddi-0.Chicago.mci.net (204.70.3.83) [AS 3561] 36 msec 32 msec 36 msec 5 * * * 6 * * etc...... ----but using MCI's IP---- INDY1#traceroute 150.147.1.1 Type escape sequence to abort. Tracing the route to StLouis21-e1.dra.net (150.147.1.1) 1 bordercore4-hssi6-0-2.NorthRoyalton.mci.net (166.48.234.9) [AS 3561] 28 msec 24 msec 24 msec 2 core1.NorthRoyalton.mci.net (204.70.4.205) [AS 3561] 24 msec 24 msec 28 msec 3 core-hssi-2.Chicago.mci.net (204.70.1.93) [AS 3561] 32 msec 28 msec 28 msec 4 border4-fddi-0.Chicago.mci.net (204.70.3.83) [AS 3561] 32 msec 32 msec 36 msec 5 data-research.Chicago.mci.net (204.70.27.10) [AS 3561] 36 msec 44 msec * 6 StLouis21-e0.dra.net (150.147.112.21) [AS 1746] 56 msec * 40 msec

1 0