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.

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

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

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...

[...]

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 :wink:

A

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

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/

I don't generally like 'me, too', posts, but Ivan's advice here cannot be overstated; this way lies madness.

[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

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? :wink:

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 :wink:

Once again, thanks all for the replies.
Clue

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

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.

:slight_smile:

Best regards,
Daniel

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

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

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

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