- Test - lists.nanog.org

Re: MPLS VPNs or not?
by Dave Israel 07 Aug '01

07 Aug '01

On 8/7/2001 at 17:33:39 +0100, Randy Bush said: > > > That would be a rational position, but it can't be accepted by the > > folks who have a fairly irrational attitude about the subject. > > love those ad hominem arguments by the desperate in the defense of clearly > non-scalable technology. will ad homina be part of 2547bis? The sad thing here is, you repeated what the complaints are about in your reply: specifically, you keep telling us it is "clearly non-scalable," but you also fail to tell us why. So: 1) 2547bis requires configuration at the ends only, just like any other IP service in a properly configured network. 2) The routing descriptor space is larger than the IP space, so it does not present a limiting factor. 3) The BGP mesh requirements are the same as for any other BGP-aware network (barring implementation issues, which are not a problem with the protocol itself.) The additional configuration can be as static or as dynamic as any other IP service. 4) The memory requirements for the additional routes are the same as for any other IP routes, plus a little overhead for tracking the routing table. This additional overhead does not appear to be significant. Therefore, I would say that 2547bis is clearly scalable, or at least, as scalable as internet IP service. -Dave

1 0

Re: MPLS VPNs or not?
by Dave Israel 07 Aug '01

07 Aug '01

On 8/7/2001 at 15:14:02 +0100, Randy Bush said: > > > Take a look at the mpls(a)uu.net archives for a rather exhaustive and > > exhausting discussion of this very subject, or provide facts as to what > > specifically doesn't scale. > > to paraphrase vijay, if dealing with one rib is a major discussion in the > operator and ietf communities, how many thousands of them do you think a > prudent operator wants to deal with in 2547? And on some agricultural list somewhere, they're discussing the proper way to raise a sheep. If there's all that discussion about how to raise one sheep, who wants to deal with a flock? Once you know how to deal with one big table, dealing with a bunch of tiny, simple tables is pretty easy, especially since, once you build them, they mainly take care of themselves. This really isn't that much to it, folks. If you're very brave and very careful, you can let your customers handle their routes. Otherwise, you can statically route to them. If you don't want to handle all those routes in your VPN networks, how many more plain IP customers are you going to handle? Configuring routing for an RFC 2547 MPLS VPN is not really much harder than configuring a plain IP customer. It can certainly be automated just as easily. Perhaps the issue here is, the folks arguing against the complexity are targeting their arguments on the people who really don't need to worry about it: the small network operators, who have a small support staff trying to run a BGP-enabled network. These guys might be MPLS VPN customers, but there's no need for them to be providers. To leech another person's metaphor here, the argument is that a 747 is too hard for your average pilot to fly. Fortunately, your average pilot doesn't have to fly it. -Dave

1 0

Re: MPLS VPNs or not?
by Robert Raszuk 07 Aug '01

07 Aug '01

Randy, For me you can complain to vedors that they make crappy boxes which don't do what you need. That is fine and I will not say a one bad word against it. On the other hand I (helping to deploy mpls-vpns around the world for a few years in a number of networks including these days even your ATT) just can't watch stating that the arcitecture of 2547 is screwed only because current platforms don't scale 5 years ahead. R. > Randy Bush wrote: > > > 5 years from now you will see routers from multiple vedors allowing you > > to store & process orders of mangnitute of more routes. > > good, because i will need them for the normal default-free zone. > > but today, the vendors seem to think i need massively more routers to > support this grotty hack. and i suspect that you'll be telling me i > still need that whoileparallel network five years from now. > > randy

1 0

fire on MIT campus affecting LCS and W3C
by Nick Feamster 07 Aug '01

07 Aug '01

fyi ---------- Forwarded message ---------- Date: Tue, 7 Aug 2001 10:39:33 -0400 (EDT) Subject: fire on MIT campus affecting LCS and W3C Apparently there was a fire on the MIT campus that is affecting access to LCS and W3C web servers. The fire got a major power line.

1 0

RE: MPLS VPNs or not?
by Irwin Lazar 07 Aug '01

07 Aug '01

IMHO, this was a poorly written article. From a security standpoint, every argument against MPLS-VPNs could also apply to ATM or F/R PVCs in that none of the three provide any encryption. They try to paint MPLS as something its not, then criticize it for not being what they want it to be. It's akin to criticizing an automobile for not being able to fly. I thought it most ludicrous that Tom Nolle would criticize MPLS-VPNs because they will likely only be used on carrier's private IP networks. Based on that logic, we should also criticize ATM and Frame Relay since carriers only offer services across their own backbones. I also found it interesting that the critics of MPLS as "bad for the 'net" work for a company that currently offers MPLS-based VPN services in the U.S. (IP Enabled Frame Relay) and is rolling those services out to Europe while also expanding them to support ATM speeds. I'm betting that there are quite a few very upset product managers at AT&T this morning. Irwin > -----Original Message----- > From: Hank Nussbacher [mailto:hank@att.net.il] > Sent: Tuesday, August 07, 2001 1:37 AM > To: nanog(a)merit.edu > Subject: MPLS VPNs or not? > > > > Experts call MPLS bad for 'Net > > http://www.nwfusion.com/news/2001/0806mpls.html > > Intersting read. This should start a nice long thread :-) > > -Hank >

1 0

Followup on Cleveland Keith Building Fire
by Sean Donelan 07 Aug '01

07 Aug '01

The Keith Building is your typical multi-tenent, multi-purpose office building, which also has become a defacto carrier hotel. Over 20 different carriers have equipment, and circuits in the building. Although the property damage was limited, and no one was severely injured, during the fire department response several providers had service interruptions. In a multi-tenent building, it is often difficult to do pre-fire planning. Even though we are all competitors, in such situations, we all share the same fate. On fire-life-safety issues it would make sense for those of us in each of organizations to ensure the overall safety of the buildings we are all in. The National Fire Protection Assocation is developing guidelines for telecommunication facilities. Are there any lessons we can learn from the Keith Building fire which should be included in the recommended guidelines? Can we work with the local fire departments on more effective pre-fire planning?

1 0

RE: TCP session disconnection caused by Code Red?
by James Smith 07 Aug '01

07 Aug '01

I can see "connection refused" being caused by lack of resources (memory, not CPU) caused by ARP requests not being resolved and waiting to time out. What happens is that all the outstanding ARP requests use up all available memory, so no buffers can be allocated for new incoming connections. Send enough requests fast enough, looking for enough different IP's, memory gets exhausted. Been there, seen it happen, tweaked the WellFleet/Bay/Nortel knob to limit the amount of space used for ARP resolution, and solved the problem caused by too many outstanding ARPs. Of course, I could have stuffed in more memory, but limiting the space used for the process was easier. James H. Smith II NNCDS NNCSE Systems Engineer The Presidio Corporation -----Original Message----- From: George William Herbert [mailto:gherbert@retro.com] Sent: Monday, August 06, 2001 2:57 PM To: mike harrison; nanog(a)merit.edu Subject: Re: TCP session disconnection caused by Code Red? mike harrison <meuon(a)highertech.net> wrote >Blaz Zupan <blaz(a)amis.net> wrote: >> For the last few days, our network seems to be basically unreachable from the >> outside. Most incoming TCP sessions (web requests, incoming mail, telnet >> sessions, etc.) often fail with a simple "Connection refused" like nobody is > >Your routers are brain dead from the load.. routers that are used to >handling a few thousand connections are being asked to handle 10's of >thousands. 1 good 1000+ address scan from an ISDN user kills my >Lucent/Ascend TNT unless we filter for it. I've been told (but not given permission to forward details of who/how/what) that some major sites with a single router and relatively flat network topology are dying due to the ARP request flood that is being generated by Code Red scans on the inside of their border router choking the router. Check the rate of ARP requests coming off your border router and see if it seems excessive; if so, that may be it. -george william herbert gherbert(a)retro.com

2 1

TCP session disconnection caused by Code Red?
by Blaz Zupan 07 Aug '01

07 Aug '01

I'm seeking the collective wisdom of this list to try to prove that I'm not halucinating. For the last few days, our network seems to be basically unreachable from the outside. Most incoming TCP sessions (web requests, incoming mail, telnet sessions, etc.) often fail with a simple "Connection refused" like nobody is listening on that port (but of course there is a server running on the port). It does not matter which service I'm trying to connect to, it also does not matter which server I'm connecting to. It happens randomly, i.e. three successive connections fail, then 5 connections succeed, then 2 connections fail, etc. Outgoing connections (i.e. our customers surfing the web) work just fine - except active FTP, which of course contains an implicit "incoming" TCP session. I've been fighting with this since friday and have done some packet traces. By comparing successful and unsuccesful packet traces I came to the conclusion that my problems are being caused by incoming TCP packets with the RST bit set. So I applied the following access list on the link to our upstream: access-list 170 deny tcp any any rst access-list 170 permit ip any any After doing this, our incoming TCP sessions magically started working. Looking at the packet counters, I see about 20% of our incoming packets are TCP RST packets. Putting the same filter on an internal link, I see about 1% of TCP RST packets. Turning on access list logging, I see that most of the packets are destined for port 80 on unused IP addresses (which are nullrouted) - which I guess is Code Red searching for victims. So now tell me, am I dreaming or has Code Red found a bug in Cisco IOS? :) Or is this some kind of new (or old?) denial of service attack disguising as Code Red? I've reported this to psirt(a)cisco.com and I'm waiting to see what they come up with. Anyone seen anything like this? I see the same thing with 12.0(14)S2, 12.0(17)S, 12.0(18)S and 12.2(1). Machine is a 7206 VXR, NPE-400, PA-2E3, 2FE I/O controller. Blaz Zupan, Medinet d.o.o, Trzaska 85, SI-2000 Maribor, Slovenia E-mail: blaz(a)amis.net, Tel: +386-2-320-6320, Fax: +386-2-320-6325

3 5

Re: The Death of TCP/IP
by Michael 07 Aug '01

07 Aug '01

This is the article Cringely should have written: http://www.dismal.com/thoughts/article.asp?aid=1316 Michael > -----Original Message----- > From: Dan Hollis [mailto:goemon@anime.net] > Sent: Monday, August 06, 2001 3:11 PM > To: Mike Batchelor > Cc: nanog(a)merit.edu > Subject: RE: The Death of TCP/IP > > > > On Mon, 6 Aug 2001, Mike Batchelor wrote: > > > http://www.pbs.org/cringely/pulpit/pulpit20010802.html > > Cringley was amusing as the host for "Pirates of Silicon > Valley", but his > > expertise in technology clearly stops there. > > Is this the same cringley who falsely claimed a Ph.D from Stanford? > > -Dan > > -- > [-] Omae no subete no kichi wa ore no mono da. [-] >

1 0

Re: TCP session disconnection caused by Code Red?
by Jim Warner 07 Aug '01

07 Aug '01

George Herbert (gherbert(a)retro.com) said: I've been told (but not given permission to forward details of who/how/what) that some major sites with a single router and relatively flat network topology are dying due to the ARP request flood that is being generated by Code Red scans on the inside of their border router choking the router. Check the rate of ARP requests coming off your border router and see if it seems excessive; if so, that may be it. My campus is now seeing around 500 packets per second of CodeRed connection requests into blocks that total 130,000 addresses. The work of ARPing for all that stuff is distributed across 6 routers (mostly Cisco RSM) and they're doing OK. The experience at Cal State campuses is variable. They do tend to have flat topologies behind a single entrance router. Our neighbors at CSU Monterey Bay melted under the load _before_ CR-II emerged. They had their upstream install an access list permitting an explicit list of campus web servers and blocking port 80 to everything else. Their router is mfg by Alcatel, a PowerRail 7652 OmniCore 5052. I don't have a lot of details about their setup but I do know how big their assigned address pool is -- about 6000 addresses. That leaves me wondering about the importance of quality of the ARP implementation in the router code. I have heard that CSU Long Beach (Cabletron router) had similar problems. I'm looking for anyone that knows some details of Alcatel and SSR routers that might help us understand this. I don't think this is a case where the ingenuity of ASIC designers is the important parameter. Have any of the router benchmarks dealt with the capabilities and robustness of what I'm imagining must be process-level parts of the a router implementation? -jim warner, University of California Santa Cruz

1 0