Do you have a good reason to use BGP aggregation?

For the last 10 years, I've been preaching that you should use static BGP prefix advertising (with the network mask router configuration command) to advertise your IP address space into the public Internet, not the BGP aggregation. I might see some use for BGP aggregation in enterprise networks (or MPLS VPN networks) using BGP as the core routing protocol with other routing protocols serving the edge, but I cannot find a good scenario where BGP aggregation in public Internet would be a good solution. Do you use BGP aggregation in your network? Do you have a good scenario that you'd like to share with us? Write a comment.

5 comments:

  1. I have a few...

    1) BGP will advertise the aggregate only when it has component routes. this means that it will advertise the aggregate until his last component route is lost. the component routes can also be specificaly defined with the "advertise-map" keyword. All of these make it a really helpful feature in many cases - i can mention a few if you would like...

    2) It provides an easy way of suppressing prefixes

    3)Its inheritance capabilites (aggregate from its commponents) can also be quite helpful. mainly, the way you can control this inheritance.

    ReplyDelete
  2. aggregate is a bad idea as you answer in the previous post but you can use only static route with a tag that go into BGP with redistribute static that match the tag and add a community.
    another idea is to set the next hop of the route to an address that route to Null in all the network so address that is not in use will be discard in the edge of the network and will not get to the route originator.

    Nitzan

    ReplyDelete
  3. Ofer,

    the guy is asking to share our opinion with him. The quotes that you show - You can be sure that he knows that (Or even possible is that you quote his publications :))

    Anyway, in my opinion I've never used this feature for my humble experience period (~7 years). I'm working in a service provider and most of our customers have PI addresses. Other just using network command because they've never heard about aggregation feature. Anyway I found it as a good feature which nobody use (because everyone use network statement instead) Just like ORF (Outbound Route Filtering) - nobody use it everyone is prefer to use Prefix-list in conjunction with route-maps.

    Kind Regards,
    Danail Petrov

    ReplyDelete
  4. Danail,

    I am not quoting anyone but myself (if i would, i would give reference).I just pointed out aspects of BGP aggregate that i think are providing an added value.


    as for a simple example:

    Let's say we have 2 routers. one (R1) located at the HQ , and the other (R2) located in a DRP site a couple of miles away.
    The two sites (Main and DRP) are connected directly (not through the internet!), and are running IBGP.

    normally, traffic should flow only over the Main site's link to the ISP (i am refering only to inbound traffic), so we will advertise the more specidic routes there.
    We got 4 C Classes from the ISP (PI).

    configuring 4 "nework" statements (for each C Class network) at the main site , and "aggregate-address X.X.X.X 255.255.252.0" at the DRP site would be an easy way of implementing this requierment.


    of course, you could configure a static route to null0 and advertise it using a "network" statement, but then you will have to filter the more specific routes. anyway, (as far as i can think of) BGP aggregate will be much more elegant.

    ReplyDelete
  5. More specifically, the aggregate statement will advertise the aggregate when "component" (aka contributing) routes are present in BGP. "Network," on the other hand, will take contributing routes from any protocol. Suppressing more specifics with the use of summary-only, is also desirable for many. The scenario can be when you provide transit for acquisitions (that could be private or public AS'es) which occupy a fraction of your aggregate space and you wish to suppress them. There is no one size fits all here. The point is the knob is there for a reason and plenty of folks have use for it.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.