I'm going to add some elaborations and alternatives in between your
excellent comments, if you don't mind...
Jeff Aitken wrote:
A common, but by no means the only, strategy is as follows:
1. All routers participate in a single, flat IGP. The only routes carried
in the IGP are loopbacks and links between routers. All other routes are
carried in BGP. This keeps things simple and promotes fast convergence.
Lesson learned: if you can, put all of the loopbacks into an
aggregateable range, and all of the inter-router links in an
aggregateable range. Makes rACLs much easier when you deploy them
(tomorrow).
IGP metric design can take many shapes. Planning your metrics early can
make for excellent stability in the face of issues and outages, and can
keep leased line costs low.
3. All lower-level routers in a "region" are client peers of the cores
that serve that region (where 'region' could mean POP, city, country,
etc., depending on your network).
We took this a step further, for future-proofing, courtesy of guidance
from AOL/ATDN and their excellent NANOG presentation on migrating from
OSPF to ISIS. All of the lower-level routers are client peers of the
cores, and are fully meshed within the region; the cores do NOT reflect
routes from client to client. This helps quench MED oscillation issues.
4. All routes advertised via BGP have their next-hop reset where they
enter the network. Typically this is on the edge routers, which are
client peers of the local core routers, but can be done anywhere. The
end result is that no matter where on the network you stand, every BGP
route has a next-hop address that corresponds to a router loopback that
you know how to reach via your IGP.
It's simplest to reset ALL routes, but you might want to look at doing
it on MOST, leaving a hook to exclude some special-case routes such as
blackhole routes.
You can also avoid the next-hop rewrite as long as the link containing
the next hop is in BGP (or your IGP, but not recommended). I haven't
proven my theory, but my theory says that NOT rewriting the next-hop
allows MPLS (if you're running it) to label-switch packets all the way
to the egress interface. A rewritten next-hop would invoke PHP at the
next-to-edge router, and the edge router would have to do a FIB lookup.
Am I wrong? Possibly. Would there be a benefit? I think so.
pt
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
