6

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.

Eddie
  • 15,026
  • 6
  • 44
  • 84
  • 2
    I think you're mixing the BGP protocol with BGP implementations (specifically Cisco) here. – Teun Vink Feb 22 '17 at 22:39
  • @TeunVink Sure. I guess I mean both. Why use one command or the other to add routes to BGP on Cisco devices. – Eddie Feb 22 '17 at 23:04
  • 1
    The way you've phrased the question makes any answer trivial, since you've included the use of route maps. You can use a route map to change nearly every BGP route attribute. OTOH, if you have lots of routes, redistribute might be easier to manage. – Ron Trunk Feb 23 '17 at 01:15
  • 1
    @RonTrunk if you have lots of routes, redistribute might be easier to manage -- that is a perfectly acceptable, non-trivial reason to favor redistribution over network statements. I'm sure there are others. I'm looking for reasons other than explicit control of advertised routes or origin code. – Eddie Feb 23 '17 at 01:53

2 Answers2

8

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.

rnxrx
  • 6,114
  • 1
  • 19
  • 25
2

Another difference is that in case of the network command, the route can be injected/advertised irrespective of the source (EIGRP, OSPF, IS-IS, static, directly-connected), whereas, in case of redistribute command, you would have to use it for every source from which the route can be considered for advertisement.

In both cases described above, the route has to be present in the routing table for it to be considered in BGP. For aggregation, the longer routes/prefixes have to be in the BGP table as mentioned in another answer.

n4c
  • 41
  • 4