On 10/12/2013 8:43 PM, Nick Hilliard wrote:
If you want to do it with BGP, I'd recommend setting up a couple of VMs to act as route reflectors (with e.g. bird or quagga or something) and creating a very simple BGP community policy: tag your transit prefixes, your peering prefixes and your internal prefixes using different community values. Then you can use the route reflectors to control how the prefixes are distributed around your network. It's a small amount of work, but it's an approach that scales well in practice.
...and it's a LOT, LOT easier to migrate to this sort of design while the network is small, than when it grows. Start small, start simple, only set a couple of communities till you are comfortable with how it works, take some time and work out how you want to plan your community setting and matching, and like a work of art develop both the network and your BGP operational skills over time.
It may seem a bit counter-intuitive to start implementing this before you need it, but it's a lot easier to grow into this design than to grow out of a non iBGP core and have the change forced upon you.
Been there done that, and once there's lots of live paying customers with expectations around uptime, this stuff gets more and more tricky to retrofit and learn.
Reuben _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
