[c-nsp] OSPF vs BGP to customer

Bruce Pinsky bep at whack.org
Thu Aug 18 20:29:59 EDT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Greene wrote:
> Thanks all for the replies on and off list.
> 
> The basic idea I get from the responses are:
> #1-    BGP gives more administrative control than OSPF with less likelihood
> of customer advertisements wreaking havoc on the backbone
> #2-    OSPF could be utilized, but customer should be relegated to
> independent area and routes filtered before injection into the backbone
> area. However, this is more complicated and perhaps more prone to nasty
> accidents than just running BGP
> 
> If anyone wants to elaborate even more than you have on the drawbacks of #2,
> that would be great.
> 


Your IGP process should only carry the infrastructure routes necessary to
facilitate creating your BGP sessions and managing your infrastructure,
i.e. your loopbacks, some internal link addresses, and possibly some
external link addresses if you don't do next-hop-self.  Your customer
routes should be carried in iBGP across your backbone and advertised
externally or should be sourced by your routers for external advertisement.

If you accept routes in OSPF from your customer, you must either:

- - redistribute into BGP
- - redistribute into OSPF from a separate process-id
- - allow direct interarea routes into your backbone

Redistributing into BGP can be processor intensive and needs to be
carefully filtered to prevent loops where there is dual-homing and/or
backdoor links.

Redistributing into OSPF breaks the paradigm of separation of
infrastructure routes in your IGP from customer routes in BGP.  However, if
you did allow it, you will have external routes that must be flooded
throughout your backbone and replicated at any area-border routers that you
have in your infrastructure.  Flooding and replication are highly processor
intensive and are the single biggest contributor to OSPF scaling problems.
 Additionally, you are likely to end up with network LSAs from your
customers further adding to the flooding issues.  Add on top of that the
CPU load for the redistribution itself.

Direct importation via interarea will have some of the same issues as
redistribution.  While the CPU load from redistribution won't be there,
flooding and replication are still of concern for scaling.  And the
security implications of operating in this manner would be of great concern
to me.

Regardless of redistribution or direct interarea importation, you will need
to be sure that you have good filters to prevent OSPF leaking from one
customer to another and to prevent accepting routes that are unanticipated
(whether intentional or unintentional).

In short, BGP was designed to faciliate route exchange between different
administrative domains and offers the features and controls necessary to
properly manage that.  OSPF (and other IGPs) aren't well-suited to the
task.  Sure you can do it, but I can also try to drive a nail with the
butt-end of the hammer too.

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFDBSgHE1XcgMgrtyYRAiRwAJ9fxtDIZklsU0iClM2aUaFQlJy2cgCg7wcp
vUfdIPRpzLyQcnXn8ohf4Pk=
=7U4/
-----END PGP SIGNATURE-----


More information about the cisco-nsp mailing list