BGP – Network Command vs Redistribution Considerations

bgp

BGP has three ways to advertise a route:

  • network command
  • redistribute command
  • Aggregation

There are two reasons I've come across for using the network command vs the redistribute command:

1.

The network command advertises routes with an origin code of i for IGP. The redistribute command advertises routes with an origin code of ? for Incomplete. Later, these are used in the Path Selection process whereby the origin code of i is preferred to ?.

BUT the Origin Code can be changed to anything you like using a route-map. So for the purpose of this question, let's ignore the different origin codes since they can be overridden.

2.

The network command requires you to explicitly specify which networks should be advertised into BGP. Where as the redistribute command might inadvertently advertise networks into BGP that you did not explicitly select (aka, using redistribute connected and later adding an loopback interface for testing that you did not mean to get advertise).

BUT you can also use a route-map to limit what network(s) are being redistributed, so in both cases you can still advertise networks explicitly. So for the purpose of this question, let's ignore the difference in explicit advertisements since that is possible in both method.

My question: OTHER than the two differences identified above… what are reasons why one might choose to use the redistribute command verses the network command.

Does it simply come to personal preference? Or local policies? Or are there other definitive use-cases that would require the use of one or the other.

Best Answer

First - there are two distinctly different problems being solved with these commands:

  1. The network and redistribute commands are mechanisms to initiate routes into BGP, either statically (with a backing route) or coming from another dynamic routing protocol. As mentioned in the notes there are certainly differences between the two mechanisms (origin types being an example) but the underlying function of route initiation is a common element.

  2. Route aggregation creates a supernet route within BGP as a function of other BGP routes - so, for example, the presence of one or more /24 subnets in a /19 can cause the /19 to be advertised (with or without the component /24's, depending on policy). There are a bunch of knobs typically available within route aggregation (AS sets, bundling attributes, etc) but the basic notion of working completely within the context of BGP (vs initiating an altogether new route) distinguishes it from network and redistribute

So - your question might be better phrased as why choose one method of initiating routes into BGP versus another. The answer is honestly going to be a function of design. Redistributing from an IGP allows for a dynamic set of routes to be pushed into BGP. So - for example - networks might constantly be added and removed from OSPF within one portion of an enterprise network. These routes would (within policy limits) be added- and removed- from BGP without any further intervention. Similarly it's possible to use dynamic tagging mechanisms to control how certain classes of routes are treated in the network. As another example - a tag could be applied to a route from the prior case (enterprise OSPF) such that a particular prefix would have a BGP community applied at the point of redistribution that allowed it to be leaked past a summary. Or in a more mundane example an IGP tag might signify the need to append AS tags to the prefix at the point of BGP redistribution to make it less favorable (..or change MED, localpref, etc).

In contrast, the network command just initiates a set of routes into BGP as long as an identical backing route is in the table. This is a very static method that's typically employed when a BGP speaker at the edge of the network wants to initiate a set of prefixes into the network under almost all circumstances. The typical case for this would be BGP-connected end customers, who generally advertise a relatively small (and unchanging) set of solely-owned prefixes. They'll often pin the backing routes up with a static route as well as receiving more specific routes via an IGP (this can be thought of as a crude form of summarization).

Both approaches have their place and there's often a fair degree of overlap. It's harder to screw up the network command (although I've seen it done) while the added number of knobs and potential for loops with redistribution is often associated with a greater degree of complexity.

Related Topic