Russ

Author Archives: Russ

Administravia 20170420

A couple of minor items for this week. First, I’ve removed the series page, and started adding subcategories. I think the subcategories will be more helpful in finding the material you’re looking for among the 700’ish posts on this site. I need to work through the rest of the posts here to build more subcategoies, but what is there is a start. Second, I’ve changed the primary domain from rule11.us to rule11.tech, and started using the rule 11 reader name more than the ‘net Work name. rule11.us will still work to reach this site, eventually ntwrk.guru will time out and die. Finally, I’ve put it on my todo list to get a chronological post page up at some point.

Happy Reading!

The post Administravia 20170420 appeared first on rule 11 reader.

Optimal Route Reflection


There are—in theory—three ways BGP can be deployed within a single AS. You can deploy a full mesh of iBGP peers; this might be practical for a small’ish deployment (say less than 10), but it quickly becomes a management problem in larger, or constantly changing, deployments. You can deploy multiple BGP confederations; creating internal autonomous systems that are invisible to the world because the internal AS numbers are stripped at the real eBGP edge.

The third solution is (probably) the only solution anyone reading this has deployed in a production network: route reflectors. A quick review might be useful to set the stage.

In this diagram, B and E are connected to eBGP peers, each of which is advertising a different destination; F is advertising the 100::64 prefix, and G is advertising the 101::/64 prefix. Assume A is the route reflector, and B,C, D, and E are route reflector clients. What happens when F advertises 100::/64 to B?

  • B receives the route and advertises it through iBGP to A
  • A adds its router ID to the cluster list, and reflect the route to C, D, and E
  • E receives this route and advertises it through its eBGP session towards G
  • Continue reading
1 89 90 91 92 93 159