cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1961
Views
0
Helpful
12
Replies

BGP:Please help clarify nuance on BGP synchronization?

news2010a
Level 3
Level 3

Hello folks, I have a question regarding BGP behavior when synchronization is enable or disabled.

First of all, I understand that in order for a route to be advertised in iBGP, let's say advertised via the 'network' command under the bgp router <AS> command, such network would appear in the bgp table (show ip bgp)  only if such prefix is already populated in the ip routing table (it could be populated in the ip routing table by a directed connected interface, redistribution or learned via an IGP). My understanding is that such condition does not change no matter what, with bgp sync enabled or disabled. Am I correct?

Therefore I think the statement below regarding bgp sync is a little bit confusing:

"A prefix is synchronized in BGP if there is a matching prefix in the IGP. If a BGP learned prefix is not synchronized, the prefix will not be inserted into the routing table and will not be advertised to external peers...".

The confusion to me is that even when BGP sync is disabled, it is a requirement to have the respective network or prefix present in the ip routing table. Well, in order to have such network present in the routing table I normally would need an IGP to populate the network there in the routing table, right? (unless it is a direct connected network or populated in the routing table via the redistribute command).

So following the rationale above it seems to me that the requirement is that I would need an IGP advertising the prefix in the ip routing table no matter what with sync disabled or enabled. So my point is that I do not understand very well the point of the "synchronization"  command. I am aware that normally is not in use anymore and it is disabled by default.

I would appreciate if you could clarify this concept.

4 Accepted Solutions

Accepted Solutions

Reza Sharifi
Hall of Fame
Hall of Fame

Synchronization states that, if your AS passes traffic from another AS to a third AS, BGP should not advertise a route before all the routers in your AS have learned about the route via IGP. BGP waits until IGP has propagated the route within the AS. Then, BGP advertises the route to external peers

More info here:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#synch

But as you said here, this is on older command, it is not used any more and it is disabled by default.

In addition, other venders like Juniper, which their products is mainly built for service providers and heavy use of BGP do not have such a command.

HTH

Reza

View solution in original post

Jon Marshall
Hall of Fame
Hall of Fame

news2010a wrote:


Therefore I think the statement below regarding bgp sync is a little bit confusing:

"A prefix is synchronized in BGP if there is a matching prefix in the IGP. If a BGP learned prefix is not synchronized, the prefix will not be inserted into the routing table and will not be advertised to external peers...".

The confusion to me is that even when BGP sync is disabled, it is a requirement to have the respective network or prefix present in the ip routing table. Well, in order to have such network present in the routing table I normally would need an IGP to populate the network there in the routing table, right? (unless it is a direct connected network or populated in the routing table via the redistribute command).

So following the rationale above it seems to me that the requirement is that I would need an IGP advertising the prefix in the ip routing table no matter what with sync disabled or enabled. So my point is that I do not understand very well the point of the "synchronization"  command. I am aware that normally is not in use anymore and it is disabled by default.

I would appreciate if you could clarify this concept.

Just to add to Reza's post.

The confusion comes from the fact that as you correctly state each router must know about all external routes to the AS. And one way to do this is to redistribute external routes into your IGP within your AS. This is where synchronisation becomes important.

However the other way to do the same thing is to have every router within your AS peering with every other router within your AS ie. there must be a full IBGP mesh between all routers. If this exists then synchronisation still has to be disabled but as you can see you then do not need an IGP as all routers are receiving all routes from IBGP. So all routers within the AS can know all other routes from BGP alone ie. you don't need an IGP.

Jon

View solution in original post

Marlon

The problem you are having is that when R1 advertises the route to R2 the next-hop is 10.0.0.1 which is R1 interface.

R2 then advertises that to R3 but the next-hop remains unchanged ie. it is still 10.0.0.1. But R3 does not know how to reach 10.0.0.1 so it cannot install it in the routing table and cannot advertise it to R4. Note R3 is not checking for the route in the routing table, rather it is because the next-hop is not reachable that it is not advertised and is not installed in the routing table.

It's unfortunate in your example that the next-hop 10.0.0.1 and the network 10.0.0.0/24 are the same network if you see what i mean so this may confuse what i was trying to explain. So a quick test

on R1

1) add a loopack interface ie.

   int loopback 10

   ip address 192.168.5.1 255.255.255.0

2) advertise it out

   router bgp 500

   network 192.168.5.0 mask 255.255.255.0

then check on R3. You should see exactly the same behaviour ie. it is there in "sh ip bgp" with a next-hop of 10.0.0.1 but it isn't in the routing table. And it cannot be advertised to R4 because the next-hop is not reachable ie. nothing to do with not finding it in the routing table.

The way to fix this is on R2 add this to your bgp config -

router bgp 400

neighbor 192.168.1.2 next-hop-self

this tells R2 to make itself the next-hop when it advertises the route to R3. R3 can reach R2 so R3 can then advertise the route to R4 and a "sh ip route" on R3 should have both 10.0.0.0/24 and 192.168.1.0/24

*** Edit - i have just realised you are already using 192.168.1.x for the link between R2 & R3. Apologies for confusing the issue even more. Use a network on the R1 loopback that isn't used anywhere else eg. 192.168.5.0/24

Jon

View solution in original post

Jon Marshall
Hall of Fame
Hall of Fame

news2010a wrote:

Yes, the 'next-hop-self' - I missed it again.

Then I did as you outlined. I noticed that R4 still does not receive the 10.0.0.0/8 (advertised on R1). I can see the issue is that we ignored that we are learning from R1 (AS 500) and attempting to send a learned route to same AS 500 where R4 is. Once it recognizes the AS_PATH there, it is one of the BGP rules that it should not learn the route originated from same AS_PATH, correct?

I did the debug on R4 and that is what I've got:

00:35:41: BGP(0): 172.16.1.1 rcv UPDATE w/ attr: nexthop 172.16.1.1, origin i, o
riginator 0.0.0.0, path 400 500, community , extended community
00:35:41: BGP(0): 172.16.1.1 rcv UPDATE about 10.0.0.0/24 -- DENIED due to: AS-P
ATH contains our own AS;

00:35:41: BGP(0): 172.16.1.1 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: A
S-PATH contains our own AS;

Translating "sbkw"...domain server (255.255.255.255)

Good point.

On R4

router bgp 500

neighbor 172.16.1.1 allowas-in 1

Jon

View solution in original post

12 Replies 12

Reza Sharifi
Hall of Fame
Hall of Fame

Synchronization states that, if your AS passes traffic from another AS to a third AS, BGP should not advertise a route before all the routers in your AS have learned about the route via IGP. BGP waits until IGP has propagated the route within the AS. Then, BGP advertises the route to external peers

More info here:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#synch

But as you said here, this is on older command, it is not used any more and it is disabled by default.

In addition, other venders like Juniper, which their products is mainly built for service providers and heavy use of BGP do not have such a command.

HTH

Reza

Jon Marshall
Hall of Fame
Hall of Fame

news2010a wrote:


Therefore I think the statement below regarding bgp sync is a little bit confusing:

"A prefix is synchronized in BGP if there is a matching prefix in the IGP. If a BGP learned prefix is not synchronized, the prefix will not be inserted into the routing table and will not be advertised to external peers...".

The confusion to me is that even when BGP sync is disabled, it is a requirement to have the respective network or prefix present in the ip routing table. Well, in order to have such network present in the routing table I normally would need an IGP to populate the network there in the routing table, right? (unless it is a direct connected network or populated in the routing table via the redistribute command).

So following the rationale above it seems to me that the requirement is that I would need an IGP advertising the prefix in the ip routing table no matter what with sync disabled or enabled. So my point is that I do not understand very well the point of the "synchronization"  command. I am aware that normally is not in use anymore and it is disabled by default.

I would appreciate if you could clarify this concept.

Just to add to Reza's post.

The confusion comes from the fact that as you correctly state each router must know about all external routes to the AS. And one way to do this is to redistribute external routes into your IGP within your AS. This is where synchronisation becomes important.

However the other way to do the same thing is to have every router within your AS peering with every other router within your AS ie. there must be a full IBGP mesh between all routers. If this exists then synchronisation still has to be disabled but as you can see you then do not need an IGP as all routers are receiving all routes from IBGP. So all routers within the AS can know all other routes from BGP alone ie. you don't need an IGP.

Jon

milan.kulik
Level 10
Level 10

Hi,

IMHO, your statement "when BGP sync is disabled, it is a requirement to have the respective network or prefix present in the ip routing table." is incorrect.

"Usually, a BGP speaker does not advertise a route to an external neighbor unless that route is local or exists in the IGP. The no synchronization command allows the Cisco IOS software to advertise a network route without waiting for the IGP. "

See https://www.cisco.com/en/US/docs/ios/12_1/iproute/command/reference/1rdbgp.html#wp1023361

BR,

Milan

Hello Milan/Marlon,

I agree with Milan on this that is the same explanation given by Maria in a previous thread on the same subject.

BGP synchronization objective is to be sure that prefixes advertised to an eBGP neighbor are not black holed inside the AS of the local node, in a pre MPLS world the only way to be sure of this was to verify that the prefix is present in the IGP database so that internal nodes that can be present on the path between the iBGP peer and the local node are able to route packets with a destination within the prefixes

It is safe to disable BGP synchronization when:

an iBGP full mesh is built involving all routers in the AS = all routers speak BGP and no black hole can form

or

MPLS is deployed so that internal P nodes just perform label switching of label switched paths that have a destination = PE node loopback

To be noted that default settings for this command has been changed to no sync

see

12.2(8)T

Command default behavior changed to disabled.

http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp5.html#wp1018615

Hope to help

Giuseppe

Oh Milan or someone, from reading the "Troubleshooting When BGP Routes Are Not Advertised" my conclusion was that no matter what, the route must be in the ip routing table in order to get advertised by BGP. I marked the sentences in red below. I know this specific topic is talking about auto-summary, but when I read the entire document I really had the impression it requires an IGP in the routing table.

If someone can clarify where I misinterpreted the text below please let me know.

(...)

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800945ff.shtml

(...)

Routes Announced Using a Basic Network Statement

When routes are announced using a basic network statement, the behavior of the network command varies depending on whether auto-summary is enabled or disabled. When auto-summary is enabled, it summarizes the locally originated BGP networks (network x.x.x.x) to their classful boundaries (auto-summary is enabled by default in BGP). If a subnet exists in the routing table and these three conditions are satisfied, any subnet (component route) of that classful network in the local routing table prompts BGP to install the classful network into the BGP table:

  • Auto-summary enabled

  • Classful network statement for a network in the routing table

  • Classful mask on that network statement

When auto-summary is disabled, the routes introduced locally into the BGP table are not summarized to their classful boundaries.

For example, BGP introduces the classful network 75.0.0.0 mask 255.0.0.0 in the BGP table if these conditions are met:

  • The subnet in the routing table is 75.75.75.0 mask 255.255.255.0.

  • You configure network 75.0.0.0 under the router bgp command.

  • Auto-summary is enabled.

If these conditions are not all met, BGP does not install an entry in the BGP table unless there is an exact match in the IP routing table.

news2010a wrote:

Oh Milan or someone, from reading the "Troubleshooting When BGP Routes Are Not Advertised" my conclusion was that no matter what, the route must be in the ip routing table in order to get advertised by BGP. I marked the sentences in red below. I know this specific topic is talking about auto-summary, but when I read the entire document I really had the impression it requires an IGP in the routing table.

If someone can clarify where I misinterpreted the text below please let me know.

(...)

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800945ff.shtml

(...)

Routes Announced Using a Basic Network Statement

When routes are announced using a basic network statement, the behavior of the network command varies depending on whether auto-summary is enabled or disabled. When auto-summary is enabled, it summarizes the locally originated BGP networks (network x.x.x.x) to their classful boundaries (auto-summary is enabled by default in BGP). If a subnet exists in the routing table and these three conditions are satisfied, any subnet (component route) of that classful network in the local routing table prompts BGP to install the classful network into the BGP table:

  • Auto-summary enabled

  • Classful network statement for a network in the routing table

  • Classful mask on that network statement

When auto-summary is disabled, the routes introduced locally into the BGP table are not summarized to their classful boundaries.

For example, BGP introduces the classful network 75.0.0.0 mask 255.0.0.0 in the BGP table if these conditions are met:

  • The subnet in the routing table is 75.75.75.0 mask 255.255.255.0.

  • You configure network 75.0.0.0 under the router bgp command.

  • Auto-summary is enabled.

If these conditions are not all met, BGP does not install an entry in the BGP table unless there is an exact match in the IP routing table.

Marlon

The section you quote is to do with when you have a network statement under the bgp config. Now with network statements you do indeed need a match in routing table for that route to be advertised to an EBGP peer and that is nothing to do with the rule of synchronisation ie. doesn't matter whether it's on or off.

But using the network statement is not the only way to advertise routes. You can redistribute but then you would have to have the route in the IGP for it to be redistributed.

But you can also have this scenario -

R1 (as 500)  ->  R2 (AS 400)   -> R3 (AS400) -> R4 (AS500)

R1 has an EBGP peering with R2

R2 has IBGP with R3

R3 has EBGP with R4

There is no IGP running in AS400

R1 advertises a route to R2. R2 sends it to R3 and R3 passes it to R4. Note that R1 May well have had a "network" statement if it was the orginating AS for that route. But also note that R3 has advertised the route to R4 and R3 does not have a network statement. Also note that there is no IGP in AS400 so synchronisation must be off. But you can see the above is an example that no IGP is running and therefore routes can be advertised by EBGP without an equivalent IGP route.

It's important though to distinguish between the routing table and IGP. On R3 there is no IGP running but if you do a "sh ip route" which shows the routing table you will still see the route advertised from R1 and the next hop for that route must be reachable by R3.

So the distinction is, with synchronisation on a check is made in the routing table to see if the route exists, if it does it can be advertised ie. there must be another independant source of routing information for that network before it can be advertised.

With synchronisation disabled no such check is made and the route can therefore be advertised although the next-hop must still be reachable ie. there doesn't have to be an independant source for the route to advertised.

Jon

Jon, I did a lab using your scenario. Indeed R3 passed the network prefix advertised on R1 (advertised via the network statement on R1). Such prefix is not on R3 ip routing table. So that proves that in iBGP, I do not need to have a prefix in the ip routing table in order to get it installed into iBGP. I am not running IGP either in none of the routers. Interesting.

However, I was not able to see the route 10.0.0.0/24 (advertised on R1 via the network statement) passing from R3 to R4. I attempted to advertise 10.0.0.0/24 on R3 using the network statement. That did not installed the prefix into BGP on R4 either. I attached the complete show run on all routers in case you wish to verify.

R3#show ip bgp
BGP table version is 1, local router ID is 192.168.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i10.0.0.0/24      10.0.0.1                 0    100      0 500 i
R3#show ip route
(removed)

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet1/1     < == There is no 10.0.0.0/24 prefix here. Yet the route was populated in BGP at R3.
C    192.168.1.0/24 is directly connected, FastEthernet1/0
R3#show run | b bgp
router bgp 400
bgp log-neighbor-changes
neighbor 172.16.1.2 remote-as 500
neighbor 192.168.1.1 remote-as 400
!
ip classless
no ip http server
ip pim bidir-enable
!
logging history size 500
!
line con 0
line aux 0
line vty 0 4
!
!
end

R3#


R4#show ip bgp summ
BGP router identifier 172.16.1.2, local AS number 500
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxR
172.16.1.1      4   400       8       8        1    0    0 00:04:22        0 <=== This is R3

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet1/0
R4#show ip bgp   <=== Prefix 10.0.0.0/8 was not passed to R4.

R4#show ip route
(supressed...)

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet1/0
R4#show ip bgp

R4#show run | b bgp
router bgp 500
bgp log-neighbor-changes
neighbor 172.16.1.1 remote-as 400
!
ip classless
no ip http server
ip pim bidir-enable
!
logging history size 500
!
line con 0
line aux 0
line vty 0 4
!
!

Marlon

The problem you are having is that when R1 advertises the route to R2 the next-hop is 10.0.0.1 which is R1 interface.

R2 then advertises that to R3 but the next-hop remains unchanged ie. it is still 10.0.0.1. But R3 does not know how to reach 10.0.0.1 so it cannot install it in the routing table and cannot advertise it to R4. Note R3 is not checking for the route in the routing table, rather it is because the next-hop is not reachable that it is not advertised and is not installed in the routing table.

It's unfortunate in your example that the next-hop 10.0.0.1 and the network 10.0.0.0/24 are the same network if you see what i mean so this may confuse what i was trying to explain. So a quick test

on R1

1) add a loopack interface ie.

   int loopback 10

   ip address 192.168.5.1 255.255.255.0

2) advertise it out

   router bgp 500

   network 192.168.5.0 mask 255.255.255.0

then check on R3. You should see exactly the same behaviour ie. it is there in "sh ip bgp" with a next-hop of 10.0.0.1 but it isn't in the routing table. And it cannot be advertised to R4 because the next-hop is not reachable ie. nothing to do with not finding it in the routing table.

The way to fix this is on R2 add this to your bgp config -

router bgp 400

neighbor 192.168.1.2 next-hop-self

this tells R2 to make itself the next-hop when it advertises the route to R3. R3 can reach R2 so R3 can then advertise the route to R4 and a "sh ip route" on R3 should have both 10.0.0.0/24 and 192.168.1.0/24

*** Edit - i have just realised you are already using 192.168.1.x for the link between R2 & R3. Apologies for confusing the issue even more. Use a network on the R1 loopback that isn't used anywhere else eg. 192.168.5.0/24

Jon

Yes, the 'next-hop-self' - I missed it again.

Then I did as you outlined. I noticed that R4 still does not receive the 10.0.0.0/8 (advertised on R1). I can see the issue is that we ignored that we are learning from R1 (AS 500) and attempting to send a learned route to same AS 500 where R4 is. Once it recognizes the AS_PATH there, it is one of the BGP rules that it should not learn the route originated from same AS_PATH, correct? If I put R4 on AS 600, that should work OK.

I did the debug on R4 and that is what I've got:

00:35:41: BGP(0): 172.16.1.1 rcv UPDATE w/ attr: nexthop 172.16.1.1, origin i, o
riginator 0.0.0.0, path 400 500, community , extended community
00:35:41: BGP(0): 172.16.1.1 rcv UPDATE about 10.0.0.0/24 -- DENIED due to: AS-P
ATH contains our own AS;

00:35:41: BGP(0): 172.16.1.1 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: A
S-PATH contains our own AS;

Translating "sbkw"...domain server (255.255.255.255)

Jon Marshall
Hall of Fame
Hall of Fame

news2010a wrote:

Yes, the 'next-hop-self' - I missed it again.

Then I did as you outlined. I noticed that R4 still does not receive the 10.0.0.0/8 (advertised on R1). I can see the issue is that we ignored that we are learning from R1 (AS 500) and attempting to send a learned route to same AS 500 where R4 is. Once it recognizes the AS_PATH there, it is one of the BGP rules that it should not learn the route originated from same AS_PATH, correct?

I did the debug on R4 and that is what I've got:

00:35:41: BGP(0): 172.16.1.1 rcv UPDATE w/ attr: nexthop 172.16.1.1, origin i, o
riginator 0.0.0.0, path 400 500, community , extended community
00:35:41: BGP(0): 172.16.1.1 rcv UPDATE about 10.0.0.0/24 -- DENIED due to: AS-P
ATH contains our own AS;

00:35:41: BGP(0): 172.16.1.1 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: A
S-PATH contains our own AS;

Translating "sbkw"...domain server (255.255.255.255)

Good point.

On R4

router bgp 500

neighbor 172.16.1.1 allowas-in 1

Jon

jon.marshall wrote:

news2010a wrote:

Yes, the 'next-hop-self' - I missed it again.

Then I did as you outlined. I noticed that R4 still does not receive the 10.0.0.0/8 (advertised on R1). I can see the issue is that we ignored that we are learning from R1 (AS 500) and attempting to send a learned route to same AS 500 where R4 is. Once it recognizes the AS_PATH there, it is one of the BGP rules that it should not learn the route originated from same AS_PATH, correct?


Marlon

Sorry, missed the question. To be specific the rule is not that it should not learn a route that originated from same AS, it is actually that an EBGP peer will not accept a route advertisement that has any occurence of it's own AS in the AS_PATH attribute. This is how EBGP avoids routing loops.

Jon

Your attention to detail is remarkable. Thanks for all this professional help!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco