"Kris Foster" <Kris.Foster@telus.com> writes:
> Going with confeds might not be a great idea in this situation.
i'd prefer it to going with multiarea OSPF. see my concluding
statement.
> In very
> large enterprise networks and various service provider networks this can
> make sense both technically and administratively.
1000 subnets is reasonably large. exactly where would you suggest
drawing the line?
> BGP confeds will take more administrative work since you will configure OSPF
> in each confed (along with maintaining BGP in and amongst confeds),
zero-difference on the ospf side as you would have to configure ospf
on each router anyway. ok, so you have to declare external interfaces
passive, but that's not a big deal.
the bgp maintenance overhead is there, absolutely. it's also pretty
straightforward. you could even write a short program in perl to
create the bgp configuration of any given router in your network.
of course, given the abusive extent to which a lot of people create
different areas on their ospf network, you might have a misconception
about how many pseudo-ases i would be suggesting in the configuration.
depending on the topology here, i would be expecting four to six.
> redistribute into and out of bgp
redistribution is bad. use a network statement (and a pull-up route)
to get the aggregate into bgp; don't redistribute out of bgp into ospf
_ever_.
> have to deal with all the appropriate filtering,
put a community on routes that you wish to advertise to the world;
there is no need for filtering anywhere except at the edge.
> and manually maintain metrics across BGP peers (if you like
> taking the best cost paths)!
nope. of course, you _can_ do coarse-grained traffic engineering with
BGP, which is a lot more than OSPF offers you...
> And do you really want to punish yourself
> (assuming you setup dampening) because you have an unreliable link
> somewhere?
i'd much rather find stuff dampened than peg the CPU on every router
in my backbone and thus cause misbehavior across my entire network.
dampening isn't about punishment; it's about saving the network.
> You'll obviously have to understand your networks characteristics and pick
> the best solution. Done properly you can use various tricks like stub areas
> to keep routing tables on all routers at reasonable sizes, minimize
> convergence time, and make troubleshooting easier.
adding multiarea/stub area/NSSA to OSPF is diametrically opposed to
making troubleshooting easier. it also exposes you to interesting
vendor bugs in the less-well-tested backwaters of their code (voice of
painful experience here).
summary: bgp scales for really big networks. ospf does not. where
you draw the line in the sand is up to you as the designer (and
remember that networks do grow, usually bigger than you expected them
to even in an academic setting). doing a few hours of extra work
under non-emergency circumstances in exchange for a more robust design
is a good investment in my book.
---rob
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:50 EDT