RE: OSPF -vs- ISIS
The State of Illinois converted to ISIS in 2002 from EIGRP and it has definitely been a good thing for us. It's been operationally bullet proof, and simple to maintain. We typically get features faster than we would if we ran OSPF. For example, we have a desire in the future to use IPFRR. Every indication from the vendor is that this feature will be available to ISIS first, most likely because of either the extensibility of ISIS or more likely because ISIS is in so many larger providers. Mike Bernico -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of vijay gill Sent: Tuesday, June 21, 2005 9:20 AM To: Dan Evans Cc: nanog@merit.edu Subject: Re: OSPF -vs- ISIS Dan Evans wrote: All, Can anyone point me to information on what the top N service providers are using for their IGP? I'm trying to build a case for switching from OSPF to IS-IS. Those on this list who are currently running IS-IS, do you find better scalability and stability running IS-IS than OSPF? I understand that this question is a lot more complex than a simple yes or no since factors like design and routing policy will certainly affect the protocols behavior. Any insights or experiences that you can share would be most helpful. Thanks, Daniel Evans Alltel Communications Daniel, in short, we've found ISIS to be slightly easier to maintain and run, with slightly more peace of mind in terms of securitiy than OSPF. Performance and stability wise, no major difference that was noticable. For more information, see the talk by Dave Katz at http://www.nanog.org/mtg-0006/katz.html Also, AOL's experience in switching from OSPF to ISIS is covered at http://www.nanog.org/mtg-0310/gill.html the PDF on that page is actually an older version. The full version I used at NANOG is available at http://www.vijaygill.com/oi.pdf /vijay
Network Operations - Visionael opinions
Hi, I'm looking for thoughts and opinions on Visionael Network Resource Manager from network operators that have used or evaluated this product. I'd appreciate anything you'd like to share regarding your experiences. Thanks in Advance! Mike Bernico
RE: MPLS ICMP Extensions
Maybe I'm wrong, but I thought that the extended MPLS info only showed up when the trace was started on a PE or P router. Is that right? If customers or others outside the MPLS domain can see that info I'd definitely agree with you. Mike -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 12:40 PM To: [EMAIL PROTECTED] Subject: MPLS ICMP Extensions I wanted to get some other opinions on some new features that have appeared in recent code from the popular vendors. It appears there is a new draft, a copy of which can be found at http://www.watersprings.org/links/mlr/id/draft-ietf-mpls-icmp-01.txt that allows MPLS enabled boxes to return some additonal information in a traceroute packet. That's all well and good, and I can see how that might be amazingly useful to someone running an MPLS network, however, it seems to expose data much further than the local network. Here's a random example from a traceroute I recently performed (on a Juniper): traceroute wcg.net [snip] 11 hrndva1wcx3-oc48.wcg.net (64.200.95.117) 91.935 ms 102.652 ms 92.960 ms MPLS Label=13198 CoS=0 TTL=1 S=1 12 hrndva1wcx2-oc48.wcg.net (64.200.95.77) 92.593 ms 92.785 ms 93.119 ms MPLS Label=12676 CoS=0 TTL=1 S=1 13 nycmny2wcx2-oc48.wcg.net (64.200.240.45) 93.273 ms 93.121 ms 93.067 ms MPLS Label=12632 CoS=0 TTL=1 S=1 14 nycmny2wcx3-oc48.wcg.net (64.200.87.78) 104.755 ms 91.949 ms 92.169 ms MPLS Label=12672 CoS=0 TTL=1 S=1 15 chcgil1wcx3-oc48.wcg.net (64.200.240.37) 92.021 ms 91.737 ms 91.684 ms MPLS Label=12592 CoS=0 TTL=1 S=1 16 chcgil1wcx3-pos5-0.wcg.net (64.200.210.114) 175.907 ms 278.144 ms 203.763 ms MPLS Label=12695 CoS=0 TTL=1 S=1 17 chcgil1wcx2-oc48.wcg.net (64.200.103.73) 93.286 ms 93.230 ms 93.593 ms MPLS Label=13506 CoS=0 TTL=1 S=1 18 stlsmo3wcf1-atm.wcg.net (64.200.210.158) 92.780 ms 92.344 ms 92.596 ms It appears both Cisco and Juniper support this new feature. The question I quickly asked both vendors is how do you turn this behavior off, so the traceroutes appear as they did before this feature was introduced. The answer, apparently, is you don't. You can either disable TTL processing on your MPLS tunnels (in effect disabling traceroute), or you can have it output all this extra information. The response I'm getting so far from each vendor is they believe this are the right two options to offer. Thus, my post here. I think there are more people out there who would like to not expose their MPLS labels, Class of Service info, or anything else this feature can provide (because, I don't know all of what it can display), but still allow traceroute to work normally. If I'm off in the deep end, please tell me so, if not, please tell your vendor rep you'd like the icmp no mpls info knob. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Seeking Advice: L2TPv3 vs. Martini Draft MPLS
All, I'm currently comparing these two technologies in an effort to offer a Layer 2 VPN service on our backbone. Our network is currently not MPLS enabled. Below is what I perceive as the pros and cons of each technology. If anyone has thoughts on or experience with either one of these protocols I'd like to hear your opinion. Thanks Mike Martini VPN Pro Supports MPLS TE for each VPN, making it more PVCish Enabling MPLS would open up the MPLS tool box for other services like L3 VPNs and TE Con --- Enabling MPLS is a huge change Changing the forwarding paradigm in the network exposes us to new and interesting bugs and stability issues L2TPv3 VPN Pro --- Doesn't require MPLS/Much smaller change Con Although standard, only supported by Cisco currently (I think) Requires special tunneling card in GSR routers.
RE: Seeking Advice: L2TPv3 vs. Martini Draft MPLS
Thanks for your advice David. Your point is very well received. One of the design requirements for our VPN solution will be the ability to allow customers to use non-IP protocols. I don't think RFC2547bis will work for this. However if we do go the MPLS route then RFC2547bis will be available as a product as well as Layer 2 VPNs. That's definitely a benefit. -Original Message- From: David Bigge [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 10:56 AM To: Mike Bernico; [EMAIL PROTECTED] Subject: Re: Seeking Advice: L2TPv3 vs. Martini Draft MPLS Mike, An unsupported standard might as well not be a standard. I would lean towards the most openly supported standard- MPLS. Along with not letting one vendor bend you over the barrel, this openess also flushes out any problems for a more stable long-term network. You don't talk about 2547bis VPNs. Are you considering that also? We use a competitor of Cisco's equipment so I am biased. My 2 cent. David - Original Message - From: Mike Bernico [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 04, 2003 10:13 AM Subject: Seeking Advice: L2TPv3 vs. Martini Draft MPLS All, I'm currently comparing these two technologies in an effort to offer a Layer 2 VPN service on our backbone. Our network is currently not MPLS enabled. Below is what I perceive as the pros and cons of each technology. If anyone has thoughts on or experience with either one of these protocols I'd like to hear your opinion. Thanks Mike Martini VPN Pro Supports MPLS TE for each VPN, making it more PVCish Enabling MPLS would open up the MPLS tool box for other services like L3 VPNs and TE Con --- Enabling MPLS is a huge change Changing the forwarding paradigm in the network exposes us to new and interesting bugs and stability issues L2TPv3 VPN Pro --- Doesn't require MPLS/Much smaller change Con Although standard, only supported by Cisco currently (I think) Requires special tunneling card in GSR routers.
RE: IP QoS case-studies
Pete, Our network is currently offering DiffServ QoS to customers. It's a new service, but so far it is working well and has been very well received by our customers. I'd be happy to answer any questions about what we do or why offline but here are some talking points of our policy. 1. We established a network wide delay budget and then put together some software that monitors network latency. 2. We control the classification feature. We classify all our customer traffic for them with Cisco class based policing at the CPE router. 3. We use Cisco's LLQ or MDRR queuing only on our links from distribution to the network edge. On our high speed links (622Mb and above) we don't queue. There are two schools of thought on this, but we currently subscribe to the theory that just letting FIFO happen is faster than applying custom queues in the core. YMMV with very fast routers, ASICs, and all that. Hope that helps! Mike -Original Message- From: Pete Kruckenberg [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:04 PM To: [EMAIL PROTECTED] Subject: IP QoS case-studies I've found there's no shortage of advice and theory about the viability of IP QoS (DiffServ) in a large wide-area (converged) network. I have not had much luck with finding documentation about experiences implementing and operating such a beast. Presumably that's yet another (silent) confirmation that It Doesn't Work or There's a Better/Easier Way. Nevertheless, I'd still like to find anyone who has tried (successfully or not) to converge (ie VoIP/H.323/data) a high-speed (~ 1Gb/s) IP network and use IP QoS for what it is sold to do. White paper/presentation references or off-line conversation would be appreciated. Pete.
routing between provider edge and CPE routers
Hi, I apologize if this has been asked before. I work for an ISP that started very small (hundreds of T1 and 56k customers) and has grown very large in the last few years (thousands of T1 customers, as well as DS3 customers and OC3 customers). We currently use an IGP to route between our distribution routers and the CPE routers we manage. This has historically worked very well. We have recently begun running into scalability issues however. We have some distribution routers that have over 1000 T1 interfaces on them. This is causing some problems with stability in that edge IGP. Does any other service provider use an IGP all the way to the customer for non BGP customers or are we the only one? I have a feeling we maybe are. If you do use an IGP, have you had any of the scalability issues we have had? How did you fix them? If you use statics/BGP to CPE routers have you had any issues doing that? In particular I'm wondering about the thousands of lines of configuration used to make static routes work. Thanks in advance for your advice. Mike Bernico
RE: routing between provider edge and CPE routers
Thanks so much for all the feedback. All your input has been extremely helpful. Just to clarify: In our network core all customer routes are summarized and carried in iBGP. That was a recent change of mine. We use EIGRP to carry loopback and next hop information. I'm working on migrating us to IS-IS currently. (Hmm...that last sentence probably just opened up another can of worms...) At the network edge we use heavily filtered EIGRP. I was already leaning towards static routes, based on this groups input I would say that it will be a new priority. Thanks again Mike -Original Message- From: Bruce Robertson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 11:09 AM To: Mike Bernico Cc: [EMAIL PROTECTED] Subject: Re: routing between provider edge and CPE routers We switched to BGP just recently, before things got out of hand. I highly recommend that you do so. It really does work better. It's very nice seeing your OSPF config carry essentially just the loopback interfaces. In particular I'm wondering about the thousands of lines of configuration used to make static routes work. You don't say whether you're using Cisco, but recent IOSes have no trouble with huge configurations. You may have to use 'service compress-config'. -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 http://www.greatbasin.net
RE: routing between provider edge and CPE routers
So, by accepting routes from CPE you create a huge security vulnerability for your customers, and other parties. This practice was understood as a very bad network engineering for decades. Is there someplace I can find tidbits of information like this? I haven't been alive decades so I must have missed that memo. Other than this list I don't know where to find anyone with lots of experience working for a service provider. 1) for single-homed sites use static routing, period. Dynamic routing does not add anything useful in this case (if circuit is down, it's down, there are no alternative ways to reach the customer's network). I agree, and all the feedback I've gotten should help me convince my peers. The convinience of having to configure only CPE box is no excuse. Invest some resources in a rather trivial configuration management system, which keeps track of what network addresses were allocated to which customer, and produces corresponding bits of router configuration automatically. Most respectable ISPs did that long time ago. That will also reduce your tech support costs. I've never heard of software like that. Do you have a recommended vendor? Is it typically developed in house? PS. They should really require a test in defensive networking before letting anyone to touch provider's routers... What can I say, I must work cheap!
