- Test - lists.nanog.org

MPLS VPNs or not?
by Hank Nussbacher 08 Aug '01

08 Aug '01

Experts call MPLS bad for 'Net http://www.nwfusion.com/news/2001/0806mpls.html Intersting read. This should start a nice long thread :-) -Hank

16 46

Re: MPLS VPNs or not?
by smd＠clock.org 08 Aug '01

08 Aug '01

avg: | > Yakov, that was not nice. | | Then to be consistent with your own position, you certainly should agree | that 2547 is "the way to do" VPNs, as with 2547 all the VPN-related | information is confined to the PEs (where "PE" stands for provider *edge*), | and none of the P (core) routers maintain any VPN-related information. Regrettably, even one's greatest allies on some fronts can develop tunnel vision. Sean. (not nice either)

1 0

Internet disruptions on multi-access networks, NAT and proxy caches
by Sean Donelan 08 Aug '01

08 Aug '01

Overall Internet performance measurements show only the typical variations in Internet performance. However, there have been several severe, but localized disruptions in multi-access networks, such as local ethernet, token ring and cable modem networks. There are also difficulties with some NAT devices and networks which aggressively use proxy web caches, such as international ISPs with small uplinks. This is a side-effect of Code Red II scanning the local subnet or network, and some network equipment having difficulty managing the ARP, NAT or proxy cache resource exhaustion. Due to the way IP forwarding works, point-to-point backbone router links are more or less immune to the problem. So I don't expect to see impact on the global Internet. But local enterprises and tier 2 through N ISPs could have problems with misbehaving servers on their networks.

1 0

Re: anybody seen this? (POST /PAV_REL HTTP/1.0)
by Matt Hite 07 Aug '01

07 Aug '01

Paul, This is a guess, but given a few clues in the header, I'd speculate that it's an anti-virus agent that utilizies Marimba technology for signature updates. (From what I understand, Marimba technology is incorporated into a number of applications for product updates, etc.) --Matt Hite On Tue, Aug 07, 2001 at 11:06:05AM -0700, Paul A Vixie wrote: > while hunting codered, i started seeing quite a few of the following: > > POST /PAV_REL HTTP/1.0 > User-Agent: TSTPAV > Connection: Keep-Alive > Content-length: 138 > Pragma: no-cache > Content-type: application/marimba > Request-type: update/12 > > what's being attempted here, and is anybody else seeing it? sometimes it's > > POST /PAV_REL HTTP/1.1 > Host: ... > Connection: keep-alive > User-Agent: TSTPAV > Content-length: 974 > Pragma: no-cache > Content-type: application/marimba > Request-type: update/12 > Via: 1.0 proxy-rnb (NetCache NetApp/5.1D3) > X-Forwarded-For: ... > > i'm not currently collecting the content, maybe i should. anybody seen this? > > ------------------------------

1 0

Re: MPLS VPNs or not?
by David Charlap 07 Aug '01

07 Aug '01

>> Over time, however, this advantage disappeared. IP best-match >> lookup chips were developed that could do a proper IP lookup at >> full line rate for OC-48 and even OC-192. > > Though I appreciate your point Dave,..... > > Throw enough silicon at any single problem and you can solve it. The > question is what can you do with the silicon you have at your > disposal for a given thermal/power/cost foot print. ... Don't misunderstand me. I am _NOT_ one of those people opposed to MPLS! I happen to be a developer working on MPLS software, and I think it is some very good technology. I was only referring to Craig's statement regarding some people's assertion that label/VC forwarding is faster than IP forwarding. I agree with him that this assertion is not true today, although it was true in the not-too-recent past. Other uses of MPLS (including traffic engineering, various kinds of VPN technologies, policies, etc.) are still very important, useful, and desirable features. -- David

1 0

RE: MPLS VPNs or not?
by Kavi, Prabhu 07 Aug '01

07 Aug '01

> -----Original Message----- > From: Daniel Golding [mailto:dan@netrail.net] > > The scary thing is that the "speed" of MPLS-based networks is taken as > gospel by an alarming number of engineers, mainly those who > have come out of > the large telco's (i.e. ILECs), and are still kind of mad > that ATM didn't > work out. These folks are more or less alarmed by IP, and > desperately seek a > more deterministic, switch-based model of data transmission > for the Internet > as a whole. The fact that there is no practical, real-world > difference in > forwarding speed between straight IP, and IP over MPLS is generally > explained away by these guys in a fairly elaborate handwaving > exercise. At > least one major hardware vendor is not helping this, with > some of their > engineers convincing major customers that conventional IP > routing is bad, > and that anything MPLS is good. While I agree that MPLS has > it's uses - i.e. > TE as an exception handling mechanism for outages, and L2VPN > technology as a > FR/ATM replacement, some folks need to approach the technology with > additional caution, and not blindly embrace it as a panacea. > As the internet > engineering community evolves, learning from things like ATM, > becomes quite > important. > > - Daniel Golding I completely agree with this type of pragmatism. A couple of years ago, MPLS had only one viable application-TE for core IP networks. The implementations were buggy at first, but they have certainly improved. Nobody was *forced* to use it, but some service providers saw advantages to deploying it. Today, MPLS has more applications, such as routing optical lightpaths, L3 VPNs, L2 VPNs, and more applications will come. Again, nobody is *forced* to use any of them. Some of these applications may provide significant business advantage, some of them may crash the network. IMHO, it is a Good Thing(TM) that vendors are coming up with these new applications, because it gives service providers multiple choices in terms of the types of service they could offer, assuming they were willing to take the risk in deploying these services. If you don't NEED protocol X, where X=[RFC 2547, QoS, L2VPNs, GMPLS, pick your favorite proposal here], don't use it. If you don't LIKE protocol X it, don't use it, and hope that: A.) Your competitors deploy it, and B.) Your hunch was right and you make more money than your competitors as the result of your decision. Ultimately, we should let the market decide. Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: prabhu_kavi(a)tenornetworks.com 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720

1 0

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

07 Aug '01

>> 1984 OSI >Usable parts adapted for IP use. I think we can all agree that IS-IS is still a fairly viable technology?

1 0

anybody seen this? (POST /PAV_REL HTTP/1.0)
by Paul A Vixie 07 Aug '01

07 Aug '01

while hunting codered, i started seeing quite a few of the following: POST /PAV_REL HTTP/1.0 User-Agent: TSTPAV Connection: Keep-Alive Content-length: 138 Pragma: no-cache Content-type: application/marimba Request-type: update/12 what's being attempted here, and is anybody else seeing it? sometimes it's POST /PAV_REL HTTP/1.1 Host: ... Connection: keep-alive User-Agent: TSTPAV Content-length: 974 Pragma: no-cache Content-type: application/marimba Request-type: update/12 Via: 1.0 proxy-rnb (NetCache NetApp/5.1D3) X-Forwarded-For: ... i'm not currently collecting the content, maybe i should. anybody seen this?

2 1

RE: MPLS VPNs or not?
by Kavi, Prabhu 07 Aug '01

07 Aug '01

> -----Original Message----- > From: Irwin Lazar [mailto:ILazar@tbg.com] > > 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 I thought this was interesting as well. This other group within AT&T has obviously looked at the potential scaling problems, the risks associated with it, and continue to deploy it. As a side note, this group has built large networks in the past, and given the size and scope of their networks, have a stability that most operators would envy. Oh by the way, they are profitable too. Randy, what was your point again? Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: prabhu_kavi(a)tenornetworks.com 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720

2 1

Blocking Code Red and other HTTP Hacks using NBAR
by Scott Frisby 07 Aug '01

07 Aug '01

This solution will be posted on CCO in the next day or so and will be referenced in the Cisco's Security Advisory as well. http://iponeverything.net/CodeRed.html You comments and thoughts are welcome - My thought is that this solution would really be useful on managed customer prem routers to block both inbound and more effectively outbound sessions to prevent code red infection. Please feel free to forward to customers. I will follow up with the official CCO release. Also policing and droping on conformance will work as well. Regards, Scott E. Frisby CCIE # 5059 Product Manager - NBAR Enterprise Solutions Engineering C i s c o S y s t e m s Voice: (408) 853-7018 Pager: 1-800-365-4578 Pager: 1-800-796-7363 p1032646 e-mail: sfrisby(a)cisco.com e-page: sfrisby(a)epage.cisco.com

1 0