BGP advertisement without a network statement

[Vi2]

I understand that in order for a router to advertise networks to another router over eBGP you need a network command for the subnet and mask.  In addition, it has to be an exact match in the routing table as well.  However, I set up a lab that has a router advertising a subnet to an eBGP peer without a network statement but I think I know why but would like someone's else's thoughts on this as well.  The edge router "a" peers with router "b" over eBGP.  Edge router "a" also peers with router "c" over iBGP.  Router "c" is advertising 10.250.3.0/24 to edge router "a" over iBGP.  So I see 10.250.3.0/24 on edge router "a" but I do not have a network statement to advertise it to router "b".  Is the reason that router "b" is receiving that route is because anytime a router learns about a route from an iBGP neighbor it automatically advertises it to its' peers?  I ask because when I create a loopback interface directly on router "a" and no network command to advertise it, router "b" does not see that route as expected.

Thank you

[Joseph W. Doherty]

"I understand that in order for a router to advertise networks to another router over eBGP you need a network command for the subnet and mask."

Not always. It's how you get prefixes from the route table into BGP.

For more information see:
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19345-bgp-noad.html#intro

[Vi2]

Great article and thank you for posting it. So I read about how the IGP needs to have a route to the iBGP learned routes. Aside from that, in the scenario I gave edge router "a" does not need network statements in order to advertise iBGP learned routes to the eBGP peer "b" assuming that the IGP has a route to the iBGP learned route? I have always used a network statement to advertise so this one scenario threw me off.

Thank you

[Martin L]

Yes, and it works the other way too. note: iBGP will not advertise eBGP-learned routes to other iBGPs.

there are several other ways to advertise networks/prefixes into BGP:

1. network x mask z

2. network x without mask will work if u have auto-summary enabled; also,

3. redistribution others or connected is my favorite.

4. aggregate-summary  is tricky but works

[Vi2]

I noticed that in my lab when I looked at the routing table of the other iBGP peers. They receive the eBGP learned route because the edge has a route to it as well. Thank you very much. Your feedback and article just put me in a better place. Do you have any books to recommend that you may have read related to BGP? I currently have my CCNP - R&S and work on BGP on a lightweight basis (at the edge only with VRF-Lite). However, I am studying for CCIE and also about to be exposed to BGP on a greater scale with multiple routing policies in place.

Thank you

[Vi2]

So I noticed I had synchronization disabled on edge router "a". When I enabled it, router "a" stopped advertising the iBGP learned route to the eBGP peer "B". It made sense because I didn't have static routes or an IGP running. So I created an OSPF instance enable OSPF between router "a" and "c" which is the iBGP peer and now router "a" knows about 10.250.3.0. However, despite knowing how to get to the iBGP learned route it still is not advertising that route to the eBGP peer automatically. I have to enter the network statement under the BGP instance in order for router "a" to advertise that network to the eBGP peer. So it seems that with synchronization enabled you not only need to have IGP know how to reach the iBGP learned route but you also have to configure the network statement under the BGP instance as well. If they synchronization is disabled then it will advertise it regardless.

[Vi2]

So I tripled checked my lab and this is the conclusion from testing different scenarios:
1) Edge router "a" knows how to reach iBGP learned route via OSPF. Synchronization is enabled and no network statement configured to advertise iBGP learned route under the BGP instance. Result - edge router does not announce the iBGP learned route to the eBGP peer. - Announces the route to EBGP peer once the network statement is configured.
2)Same scenario above except I disable synchronization then clear all BGP peerings on the edge router "a". Edge router "a" now announces the iBGP learned route to the eBGP peer.
3)Did the same test without OSPF configured because the iBGP peer was directly connected and router "a" still knew about the iBGP learned route.

[Vi2 · Accepted solution]

Feedback is welcomed on this topic. Thank you for your feedback so far.

[Vi2 · Accepted solution]

I apologize for beating a dead horse here but I felt like I missed something during my testing because it did not make sense based on the rules in play. Sure enough, I must have not given sufficient time for the routing tables to converge on edge router "a" or neglected to clear it in one of my scenarios. After re-enabling synchronization and then clearing the bgp peering the iBGP learned route was no longer in the routing table and therefore was not being advertised to the eBGP peer. So then I added a static route back to the route that lives on the iBGP peer and sure enough the route gets advertised without the network statement under the BGP instance. Without the static route, using OSPF as the IGP also made it possible for the route to get announced. Once I disabled synchronization the learned route is installed in the routing table and then announced to the eBGP peer with no network statement or IGP present...just iBGP running as the IGP. I also saw the synchronization should be enabled when an AS is passing traffic from one AS to another acting as a transit service. Thanks again everyone.

[Giuseppe Larosa · Accepted solution]

Hello Vi2,

synchronization is an old concept coming from the early days of BGP when BGP was running only on edge / border routers and internal routers were running only an IGP.

This was before introduction of route reflector servers and BGP confederations that solve the full mesh iBGP issue.

In that scenario border routers were expected to redistribute eBGP routes into IGP.

This is not feasible anymore given the very big size of a full internet BGP table ( 750,000 routes !!!) no IGP can support so many routes.

The modern approach is to run IGP in parallel with iBGP. The IGP provides connectivity between loopback addresses. And iBGP is used to propagate all service related prefixes.

Now, the new default value is no sync with sync disabled. This is why at the beginning the iBGP route was accepted and advertised.

The reason for this change is that most of the users had to disable sync and auto-summary on each device

no sync

no auto-summary

Both commands are now new defaults for BGP.

>> I also saw the synchronization should be enabled when an AS is passing traffic from one AS to another acting as a transit service

This is not true anymore for the reasons explained above and because for example with the introduction of MPLS internal P routers do not need to perform IP routing lookup but only perform MPLS label swap.

Hope to help

Giuseppe

[Vi2]

Very helpful Giuseppe. Thank you for the background info!!!