OSPF vs IS-IS vs PrivateAS eBGP
Hi All, I know this has been discussed probably many times on this list, but I was looking for some specifics about what others are doing in the following situations. I would like to run an IGP (currently OSPF) to our customers that are multi-homed in a non-mpls environment. They are multi-homed with small prefixes that are swipped from my ARIN allocations. OSPF has been flaky at best under certain conditions and I am thinking of making the move to IS-IS. I have also seen others going to private AS and running eBGP. This seems a bit much, but if it works, i'd make the move to it as I like bgp the most (all of the BGP knobs give me the warm and fuzzies :). I'd also like to see what folks are using in a MPLS network?? OSPFv3 or IS-IS or right to MP-BGP and redist static from the CE to PE??? On and off list are welcome. I'll make a summary after I gather the info. Thanks, Clue
Sorry, not OSPFv3. IPv6 thoughts dancing in my head. OSPF-VRF as most of you probably interpret. On Wed, Aug 19, 2009 at 10:12 AM, Clue Store <cluestore@gmail.com> wrote:
Hi All,
I know this has been discussed probably many times on this list, but I was looking for some specifics about what others are doing in the following situations.
I would like to run an IGP (currently OSPF) to our customers that are multi-homed in a non-mpls environment. They are multi-homed with small prefixes that are swipped from my ARIN allocations. OSPF has been flaky at best under certain conditions and I am thinking of making the move to IS-IS. I have also seen others going to private AS and running eBGP. This seems a bit much, but if it works, i'd make the move to it as I like bgp the most (all of the BGP knobs give me the warm and fuzzies :).
I'd also like to see what folks are using in a MPLS network?? OSPFv3 or IS-IS or right to MP-BGP and redist static from the CE to PE???
On and off list are welcome. I'll make a summary after I gather the info.
Thanks, Clue
Clue Store wrote:
I have also seen others going to private AS and running eBGP. This seems a bit much, but if it works, i'd make the move to it as I like bgp the most (all of the BGP knobs give me the warm and fuzzies :).
Upon previous advice I've received from large ISPs, I shifted to ISIS to strictly handle internal links and loopbacks which are stable in a single area and use iBGP/eBGP for everything else. While not currently using MPLS (size, topology, and customer demand don't warrant it), it's nice to have the foundations already in place. Shifting IGPs is annoying, especially given we previously had everything in the IGP. The only perk I saw with OSPF was future development of supporting MPLS across multiple areas. ISIS just seemed to suit my needs better. Jack
On 19/08/2009 16:12, Clue Store wrote:
I would like to run an IGP (currently OSPF) to our customers that are multi-homed in a non-mpls environment.
Unless you want your customers to have very substantial control over your internal network, don't use an SPF IGP like ospf or is-is. You really want to use BGP for this and private ASNs are fine - that's what they are there for. Nick
Thanks for all the replies so far. Just to clarify, I am in the small ISP/Hosted services business. I was fortunate to inherit the current setup of OSPF to the multi-homed customers. As i stated earlier, I would like to run an IGP, what I really meant was I would like to run a routing protocol that gives me most control as well as the customer and that scales. I am not dead set on running and IGP as IGP in my mind refers to MY internal gateways. and not my customers gateways. eBGP with Private AS is what I would like to go with , but I have had some in the industry say this is not as good as running an IGP with the customer. However, I disagree, but from the looks, this really might just come down to whatever protocol im comfortable with and making sure that it is configured in the correct manor for my situation. As far as my internal connections, I think I will be migrating to IS-IS, but this is not the point of my message to the list, as I am more concerned about customer connections. Keep the opinions coming guys. Clue On Wed, Aug 19, 2009 at 12:01 PM, Nick Hilliard <nick@foobar.org> wrote:
On 19/08/2009 16:12, Clue Store wrote:
I would like to run an IGP (currently OSPF) to our customers that are multi-homed in a non-mpls environment.
Unless you want your customers to have very substantial control over your internal network, don't use an SPF IGP like ospf or is-is. You really want to use BGP for this and private ASNs are fine - that's what they are there for.
Nick
Keep the opinions coming guys.
there are certainly many opinions on this subject. However, the most important factor is - how flexible you wish to be? As you correctly point out, this is not an issue of what protocol are you going to be running inside your network. So, "IGP" is not an issue. The issue at hand is what routing protocol are you going to be running with your customers. The question you should ask yourself is - in what situations are you going to be running routing protocol with customers? In those situations, how are you going to implement things like loop prevention, path selection, load sharing and most importantly - how are you going to be carrying those routes in your network? Now, if you are clear how to do those things and you are comfortable with them in any given scenario - why would you limit yourself to on one thing? You could decide to be very flexible and do "whatever customer prefers", or you could limit yourself to one routing protocol. There are pros and cons in both cases. Personally, I prefer being able to be flexible with customers, but I perfectly understand larger operators wanting to have "standard package" that can be copy/pasted without much risk... -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.info/
On Wed, Aug 19, 2009 at 12:58:01PM -0500, Clue Store wrote: [snip]
would like to go with , but I have had some in the industry say this is not as good as running an IGP with the customer.
Name and shame. TTBOMK, no-one who thought walking that road was a Good Idea did so for long after starting down the path. As far as 'customer choice' goes, the customer is indeed always right when it comes to their *desired goal* in the abstract (multihoming, etc), but rarely if ever in its implementation. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Unless you want your customers to have very substantial control over your internal network, don't use an SPF IGP like ospf or is-is. with your customer ^
i know that's what you meant, but i thought it worth making it very explicit. practice safe routing, do not share blood with customer. is-is in core with ibgp, and well-filtered ebgp (and packet filters a la bcp 38) to customers. randy
I seem to get the impression that isis is preferred in the core. Any reasons why folks dont prefer to go with ospf? Glen On Thu, Aug 20, 2009 at 3:36 PM, Randy Bush <randy@psg.com> wrote:
Unless you want your customers to have very substantial control over your internal network, don't use an SPF IGP like ospf or is-is. with your customer ^
i know that's what you meant, but i thought it worth making it very explicit.
practice safe routing, do not share blood with customer.
is-is in core with ibgp, and well-filtered ebgp (and packet filters a la bcp 38) to customers.
randy
I seem to get the impression that isis is preferred in the core. Any reasons why folks dont prefer to go with ospf?
a bit harder to attack clnp (is-is) than ip (ospf) is-is a bit simpler to configure, though you can get a sick as you want. but don't. a bit simpler to code, so worked and was stable when ospf was far flakier than it is now. randy
On Sep 11, 2009, at 6:23 PM, Randy Bush wrote:
I seem to get the impression that isis is preferred in the core. Any reasons why folks dont prefer to go with ospf?
a bit harder to attack clnp (is-is) than ip (ospf)
is-is a bit simpler to configure, though you can get a sick as you want. but don't.
a bit simpler to code, so worked and was stable when ospf was far flakier than it is now.
I'd also add that ISIS supports IPv6 through the addition of TLVs whereas OSPF was redesigned into OSPFv3. Personally I like ISIS due to it's simplicity and use it for router loopback advertisement only.
-----Original Message----- From: Cord MacLeod [mailto:cordmacleod@gmail.com] Sent: Friday, September 11, 2009 9:50 PM To: North American Network Operators Group Subject: Re: OSPF vs IS-IS vs PrivateAS eBGP
I'd also add that ISIS supports IPv6 through the addition of TLVs whereas OSPF was redesigned into OSPFv3.
Personally I like ISIS due to it's simplicity and use it for router loopback advertisement only.
Cord, so you've piqued my interest. Are you saying you run ISIS for loopback recursion, but another protocol for everything else? -- Stefan Fouant
On Sep 12, 2009, at 7:48 AM, Fouant, Stefan wrote:
-----Original Message----- From: Cord MacLeod [mailto:cordmacleod@gmail.com] Sent: Friday, September 11, 2009 9:50 PM To: North American Network Operators Group Subject: Re: OSPF vs IS-IS vs PrivateAS eBGP
I'd also add that ISIS supports IPv6 through the addition of TLVs whereas OSPF was redesigned into OSPFv3.
Personally I like ISIS due to it's simplicity and use it for router loopback advertisement only.
Cord, so you've piqued my interest. Are you saying you run ISIS for loopback recursion, but another protocol for everything else?
Correct. I use ISIS in level 2 only to announce my loopbacks, then BGP for everything else.
On 19 Aug 2009, at 16:12, Clue Store wrote:
I would like to run an IGP (currently OSPF) to our customers that are multi-homed in a non-mpls environment. They are multi-homed with small prefixes that are swipped from my ARIN allocations. [...]
Customers do, err, interesting and creative things, in unexpected ways. Develop a standard filtering/protection layer from them and deploy it however they connect to you - ergo use one routing protocol. Using bgp means you can transit people who aren't pinching your own arin space with the same filtering techniques. The filtering methods and techniques for customer/provider edges are well understood and documented for bgp so if you need help, then help is out there. With bgp you'd also leave less of a time bomb for whoever succeed you in the future. This is before we even look at the technical reasons why bgp is more suitable than a flooding RP for this deployment. Use BGP ;-) A
Do not EVER run an SPF routing protocol with your customer. They can insert anything they want into it (due to configuration mistake, malicious intent or third-party hijacking) and your whole network (or at least the other customers) will be affected. Just to give you a few examples: * They could hijack the host route to your DNS server and spoof every other customer of yours that uses your DNS * They could hijack the host route to your POP3 server and collect the usernames and passwords of your residential users * Company A could hijack the host route to the web server of company B. * They could insert a better default route than you do and at least some of your routers will listen to them. * If they ever make a total mess and start flapping their LSAs, your whole network will be affected and all your routers will burn CPU running SPF algorithm. If you absolutely insist on not using BGP (but then BGP is the only currently available routing protocol designed to handle routing in scenarios where the two parties don't necessarily trust each other), use RIP. It's safer than OSPF, at least you can filter the incoming updates. Ivan http://www.ioshints.info/about http://blog.ioshints.info/
-----Original Message----- From: Clue Store [mailto:cluestore@gmail.com] Sent: Wednesday, August 19, 2009 5:13 PM To: nanog@nanog.org Subject: OSPF vs IS-IS vs PrivateAS eBGP
Hi All,
I know this has been discussed probably many times on this list, but I was looking for some specifics about what others are doing in the following situations.
I would like to run an IGP (currently OSPF) to our customers that are multi-homed in a non-mpls environment. They are multi-homed with small prefixes that are swipped from my ARIN allocations. OSPF has been flaky at best under certain conditions and I am thinking of making the move to IS-IS. I have also seen others going to private AS and running eBGP. This seems a bit much, but if it works, i'd make the move to it as I like bgp the most (all of the BGP knobs give me the warm and fuzzies :).
I'd also like to see what folks are using in a MPLS network?? OSPFv3 or IS-IS or right to MP-BGP and redist static from the CE to PE???
On and off list are welcome. I'll make a summary after I gather the info.
Thanks, Clue
On Aug 20, 2009, at 7:13 PM, Ivan Pepelnjak wrote:
Do not EVER run an SPF routing protocol with your customer.
I don't generally like 'me, too', posts, but Ivan's advice here cannot be overstated; this way lies madness. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Unfortunately, inefficiency scales really well. -- Kevin Lawton
Clue Store said the following on 20/8/09 01:12 :
I know this has been discussed probably many times on this list, but I was looking for some specifics about what others are doing in the following situations.
Discussed on list, presented in tutorials, how much more advice is actually required? ;-)
I would like to run an IGP (currently OSPF) to our customers that are multi-homed
Several have replied saying "don't ever do this". The I in IGP stands for "interior" - which means "inside" your network, which does not mean "outside" your network. For the latter, we have BGP - if BGP for some reason seems too hard, check out the NANOG tutorials on the subject. Good luck! philip --
Thanks again for all of the replies on and off list. As I stated earlier, I didn't not think IGP was the protocol of choice for running to customers, i've just been to many different houses that do actually do this. 99% of all of our customer CPE is not managed by the customer, so that leaves it up to me to decide what to run to them. The only issue with using ebgp is getting enough of my staff that actually understand bgp to the point where they can deploy it themselves without having to get me involved on every install. I think I can make this pretty cookie-cutter config to start off and then work from there. We are moving to a new NOC so this network will get a fresh start (new 7513-sup720, few m10i's, and a dozen or so 7200vxr's). So my deployment strategy will be ebgp with multihmed customers. I just had to poke the fire so I had some ammo for upper management when they ask why I decide to go ebgp. And yes Philip, I actually have many of those presentations saved on my drive as they were all for not ;) Once again, thanks all for the replies. Clue On Thu, Aug 20, 2009 at 8:26 AM, Philip Smith <pfs@cisco.com> wrote:
Clue Store said the following on 20/8/09 01:12 :
I know this has been discussed probably many times on this list, but I
was
looking for some specifics about what others are doing in the following situations.
Discussed on list, presented in tutorials, how much more advice is actually required? ;-)
I would like to run an IGP (currently OSPF) to our customers that are multi-homed
Several have replied saying "don't ever do this". The I in IGP stands for "interior" - which means "inside" your network, which does not mean "outside" your network. For the latter, we have BGP - if BGP for some reason seems too hard, check out the NANOG tutorials on the subject.
Good luck!
philip --
The only issue with using ebgp is getting enough of my staff that actually understand bgp to the point where they can deploy it themselves without having to get me involved on every install. I think I can make this pretty cookie-cutter config to start off and then work from there.
For those of them that prefer eye candy to real study :), I've made a few video clips when the weather was really bad last winter and I couldn't go rock climbing ... http://wiki.nil.com/BGP (the "Videos" section") They are targeted at using BGP in MPLS VPN networks, but are useful in other similar scenarios as well.
So my deployment strategy will be ebgp with multihmed customers. I just had to poke the fire so I had some ammo for upper management when they ask why I decide to go ebgp.
Ah, that was the reason ... You could have told us in advance and my previous reply would have been even more explicit :)) Good luck! Ivan http://www.ioshints.info/about http://blog.ioshints.info/
FWIW, we use BGP to our multihomed customers (even when we manage the CPE), using a private AS. OSPF doesn't have the right toolset to provide protection for inter-network route propogation, and the risk of some customer's CPE screwing up you routing is just too high to go naked. A basic CPE BGP config is not too difficult to template, and you don't necessarily have to use prefix filters on it (although you definitely need them on YOUR) side. And once you've got it deployed, you'll find the knobs you can turn to do things like TE (ie. data down one pipe, voice down the other, and failover for both) will have both you and your customers loving it. (What? I can actually use that spare circuit that normally does nothing?!?). GG On 8/20/09, Ivan Pepelnjak <ip@ioshints.info> wrote:
The only issue with using ebgp is getting enough of my staff that actually understand bgp to the point where they can deploy it themselves without having to get me involved on every install. I think I can make this pretty cookie-cutter config to start off and then work from there.
For those of them that prefer eye candy to real study :), I've made a few video clips when the weather was really bad last winter and I couldn't go rock climbing ...
http://wiki.nil.com/BGP (the "Videos" section")
They are targeted at using BGP in MPLS VPN networks, but are useful in other similar scenarios as well.
So my deployment strategy will be ebgp with multihmed customers. I just had to poke the fire so I had some ammo for upper management when they ask why I decide to go ebgp.
Ah, that was the reason ... You could have told us in advance and my previous reply would have been even more explicit :))
Good luck! Ivan
Gary T. Giesen wrote:
FWIW, we use BGP to our multihomed customers (even when we manage the CPE), using a private AS. OSPF doesn't have the right toolset to provide protection for inter-network route propogation, and the risk of some customer's CPE screwing up you routing is just too high to go naked. A basic CPE BGP config is not too difficult to template, and you don't necessarily have to use prefix filters on it (although you definitely need them on YOUR) side. And once you've got it deployed, you'll find the knobs you can turn to do things like TE (ie. data down one pipe, voice down the other, and failover for both) will have both you and your customers loving it. (What? I can actually use that spare circuit that normally does nothing?!?).
This is pretty much how I do it for our 100Mb fibre clients. Most of them are upgrading from a <2Mbps SDSL circuit (which has been hugely profitable) to 100Mb Ethernet over fibre. Instead of erasing the revenue of the SDSL, I had this bold approach (mgmt speak) whereas I'd make both circuits worthwhile, by making them redundant. Configure eBGP from your edge to the client edge using private-AS. Since I already have copy/paste templates (thanks to RANCID), I make it a habit to ensure filters are at both ends. Goes without saying that BCP-38 is followed, and strict is deployed everywhere possible. peer-group and regexes are handy. Even for clients who have a single connection (particularly where we control the CPE), I implement eBGP on it so that if I so have the need, I can move their connection about my network with relative ease, even if I know they will never be multi-homed into us. Since my upstream doesn't allow me to BGP peer with them (v4) (they statically route my own ARIN block to me), my v4 experience ends within my own network. *sigh* Either way, even though I'm small and perhaps irrelevant, if in the same sentence you read "my network" and "customer network", use BGP. Steve
Configure eBGP from your edge to the client edge using private-AS. Since I already have copy/paste templates (thanks to RANCID), I make it a habit to ensure filters are at both ends. Goes without saying that BCP-38 is followed, and strict is deployed everywhere possible.
peer-group and regexes are handy.
If you're starting from scratch, use peer templates, they are slightly more versatile than the peer groups and allow (limited) inheritance. Ivan http://www.ioshints.info/about http://blog.ioshints.info/
On Thu, Aug 20, 2009 at 08:47:14AM -0500, Clue Store wrote:
99% of all of our customer CPE is not managed by the customer, so that leaves it up to me to decide what to run to them.
And then you run into the customer who thinks it's better to use a CPE of his own, breaks into the CPE to read your config and hooks up his own device with his own config... and suddenly you have Problems[tm]. I've seen it happening, more than once.
The only issue with using ebgp is getting enough of my staff that actually understand bgp to the point where they can deploy it themselves without having to get me involved on every install.
Am I alone in my view that BGP is _far_ more simple and straight-forward than OSPF (except in salary negotiations of course *G*)? Especially if you leave "plain simple area 0". Or if you have to protect from external parties. With BGP prefix-filtering, things are easy and obvious.
We are moving to a new NOC so this network will get a fresh start (new 7513-sup720, few m10i's, and a dozen or so 7200vxr's). So my deployment strategy will be ebgp with multihmed customers. I just had to poke the fire so I had some ammo for upper management when they ask why I decide to go ebgp.
:-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
I think you misunderstood me. You definitely need prefix filters on the *provider* side, but the CPE doesn't necessarily need them as the impact is hopefully limited to that particular customer. They're always better of course. GG On 8/20/09, Daniel Roesen <dr@cluenet.de> wrote:
On Thu, Aug 20, 2009 at 08:47:14AM -0500, Clue Store wrote:
99% of all of our customer CPE is not managed by the customer, so that leaves it up to me to decide what to run to them.
And then you run into the customer who thinks it's better to use a CPE of his own, breaks into the CPE to read your config and hooks up his own device with his own config... and suddenly you have Problems[tm].
I've seen it happening, more than once.
The only issue with using ebgp is getting enough of my staff that actually understand bgp to the point where they can deploy it themselves without having to get me involved on every install.
Am I alone in my view that BGP is _far_ more simple and straight-forward than OSPF (except in salary negotiations of course *G*)? Especially if you leave "plain simple area 0". Or if you have to protect from external parties. With BGP prefix-filtering, things are easy and obvious.
We are moving to a new NOC so this network will get a fresh start (new 7513-sup720, few m10i's, and a dozen or so 7200vxr's). So my deployment strategy will be ebgp with multihmed customers. I just had to poke the fire so I had some ammo for upper management when they ask why I decide to go ebgp.
:-)
Best regards, Daniel
-- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Am I alone in my view that BGP is _far_ more simple and straight-forward than OSPF
that ospf has become exceedingly complex, and all that results thereof.
I couldn't agree more. Most of my staff are still under the impression in Cisco land that the "network 10.0.0.0 255.255.255.0" statement injects that network into OSPF, when it simply turns on OSPF for the interfaces that are in that network. I'm really glad to see Cisco that made this change in OSPFv3 for v6. Clue On Thu, Aug 20, 2009 at 6:52 PM, Randy Bush <randy@psg.com> wrote:
Am I alone in my view that BGP is _far_ more simple and straight-forward than OSPF
this is a very telling statement in a number of ways.
that ospf has become exceedingly complex, and all that results thereof.
that both are known for their complexity.
randy
Clue Store wrote:
I couldn't agree more. Most of my staff are still under the impression in Cisco land that the "network 10.0.0.0 255.255.255.0" statement injects that network into OSPF, when it simply turns on OSPF for the interfaces that are in that network. I'm really glad to see Cisco that made this change in OSPFv3 for v6.
Cisco legacy commands make it hard on those learning fresh. I still get annoyed when I can't use CIDR notation in a config statement. I think, if nothing else, v6 is giving Cisco a fresh start at reimplementing some things. After dealing with Juniper awhile, I shifted some policies to mirror Juniper's method of doing things. At least that sorted out some confusion for others in the routers. Sadly, Cisco specific shortcuts still look cleaner and easier to manage in the config, but they also require more thought and understanding of what is going on. Jack
On Thu, Aug 20, 2009 at 07:56:14PM -0500, Clue Store wrote:
Most of my staff are still under the impression in Cisco land that the "network 10.0.0.0 255.255.255.0" statement injects than network into OSPF, when it simply turns on OSPF for the interfaces that are in that network.
So most of your staff is FAR away from understanding OSPF. Don't you think it's easier to teach them BGP? Where you have a straight-forward config of explicit neighborship, with explicit in/out prefix-lists to control route propagation from/to customers? Where signalling channel (BGP TCP session) is totally separated from what routing information is being exchanged (BGP NLRI)? OSPF just _looks_ simple when used in fully-trusted, most simple almost all defaults config, and even then it's misleading (see your reference to IOS' "network" statement for OSPFv2). When traffic engineering is needed with multiple redundant uplinks for customers, things become very interesting very quickly. Troubleshooting OSPF LSA flooding and database replication is really HARD compared to BGP's simple UPDATE/WITHDRAW messaging. And then you got the whole lot of different LSA types, flooding rules, extension hacks, area types, yadda yadda. IS-IS more straight-forward than OSPF, but still complex. All this is referring to your concern about being able to teach the Ops folks BGP, compared to teaching them OSPF. In my experience, it was never a problem to teach Ops folks BGP to CPEs (even with traffic engineering mods via route-maps), but very hard to get them up to speed on IGPs - and I'm by no means an expert in those either. BGP gives you more control, and with far higher chance of Ops folks being able to troubleshoot issues to success. To me, a clear winner, if your CPE hardware supports it. My 0.02EUR ;) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
participants (16)
-
Andy Davidson -
Clue Store -
Cord MacLeod -
Daniel Roesen -
Fouant, Stefan -
Gary T. Giesen -
Glen Kent -
Ivan Pepelnjak -
Jack Bates -
Joe Provo -
Marko Milivojevic -
Nick Hilliard -
Philip Smith -
Randy Bush -
Roland Dobbins -
Steve Bertrand