cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1905
Views
15
Helpful
12
Replies

Confirmation on BGP synchronization feature

news2010a
Level 3
Level 3

Folks, I just want to confirm that BGP synchronization is related to iBGP only, never applied to eBGP, correct?

"If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path".

1 Accepted Solution

Accepted Solutions

Seth, although you are talking to Peter, I wanted to say a couple of things. NetPro members do not usually have a problem to answer questions or explain things, since reading the notorious manuals doesn't always help (although some other well-known communities seem to religiously believe that it does). If I remember correctly, you are studying for the BSCI and you are reading the famously very well-written certification guide we all have learnt to love and can't live without. If you want more specialized reading about BGP, I believe you should read "Internet Routing Architectures" by Sam Halabi. Reading the right book can save you days of standing in front of the computer (which has caused serious neck pain to me right now).

Going to your parenthesized question: I have partly answered in my previous post. Synchronization doesn't "apply" to iBGP or eBGP. This kind of loose use of terminology causes confusion. Synchronization occurs within the AS and doesn't allow routes to go to the outside of the AS if routers internal to the AS are not synchronized.

The general synchronization scenario involves an AS that provides transit service. This means that the transit ASx receives routes from an eBGP peer in ASy and passes those to an eBGP peer in ASz, so that ASz can reach ASy destinations via ASx. If synchronization is on in ASx, this AS needs to have the routes of ASy in its IGP. Because this is obvious waste and practically impossible, synchronization is turned off and other techniques are used avoid black-holing.

If a route is received via an iBGP session, that doesn't make it an AS internal route. If ASy sends a route to ASx border router1 and router1 passes it to ASx border router2 via iBGP, this route is still external to the AS. Synchronization says router2 has to have external route in its IGP before passing it to an external peer in ASz, and that is the problem in the first place. If router 1 has another eBGP peer of its own, router 1 doesn't have to synchronize with any other router within its AS, so it gets away with the synchronization rule.

View solution in original post

12 Replies 12

Peter Paluch
Cisco Employee
Cisco Employee

Hello Marlon,

You are correct. This is exactly how I understand the synchronization feature in BGP. Note that it would not make sense in eBGP as there is no other routing protocol except BGP between autonomous systems - so there is nothing to synchronize the eBGP routes with.

The synchronization is meant as a measure against traffic blackholing where the edge routers of an AS know about external routes while the internal routers (not running BGP) do not know about external routes yet. Note that the synchronization basically expects external routes being redistributed into the internal routing protocol. This might work if you heavily limit the number of external routes you actually carry in your BGP, however, it is not a sound idea at all to redistribute the entire internet routing table into your favourite internal routing protocol, whatever it may be :-)

Best regards,

Peter

Peter, why shouldn't synchronization apply to EBGP as well?

I have three routers, A B and C in my AS, and only C is running BGP; it has an eBGP session to Router Z. I could declare network 10.3.3.0/24 under C's BGP process even if C doesn't have an IGP route to it. Without synchronization, C announces this network to Router Z and the NLRI propagates to wherever else Router Z may forward or redistribute it to.

Isn't that as much of a blackholing risk as it would be with an iBGP peer?

What does "BGP synchronization is related to iBGP only, never applied to eBGP" mean exactly?

In the description of synchronization there are typically at least 2 entities: 2 routers having an iBGP session between them and an eBGP session each with a remote peer. Please see the BGP FAQ on synchronization:

http://ciscosystems.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#nineteen

and an example in BGP case studies:

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

As far as I understand, the feature has to do with routes received from an iBGP peer and controls the validation of those routes in order for them to be passed any further to another eBGP peer.

When a router receives a route from an eBGP peer, should it wait for the route to be in its own IGP before passing it to another eBGP peer? I think this is not necessary because this router is the only one in the transit path via its own AS for the route, so there are no other internal routers in the transit path to synchronize with. Synchronization happens on the inside of the AS to ensure a valid transit path via this AS, not between ASs. The idea is that each AS synchronizes itself before they decide to speak routes to each other.

In provider networks synchronization is typically turned off and the requirement is translated to having all routers in the transit path run fully meshed iBGP in some fashion so that they can learn about all routes.

Going to the example of local BGP route origination: network 10.3.3.0/24 will not be advertised and I think this is not related to the synchronization rule (no iBGP route received to validate before passing it further). If you specify network + mask, you need an exact match in the local routing table (could be just a route to null0 though, which is a black-holing risk). If mask is missing, result depends on whether auto-summary is enabled (but still you would need at least a subset of 10.0.0.0 in the local routing table). See:

http://ciscosystems.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#five

Hello Maria,

good post

>> As far as I understand, the feature has to do with routes received from an iBGP peer and controls the validation of those routes in order for them to be passed any further to another eBGP peer.

this is my understanding too

Hope to help

Giuseppe

Thank you Giuseppe for taking the time to confirm the understanding of the concepts being discussed.

Hi Stuey,

In addition to other colleagues' answers here, what you are describing is a different thing.

A synchronization in iBGP is concerned with routes that are already in your BGP database, and the rule states that you will ignore all such routes that are in your BGP database but which are not advertised by your internal routing protocol.

What you have described here is simply an inclusion, i.e. injection of a route into your own BGP database. This is not a matter of synchronization, it is a matter of the most basic BGP operation: it goes over its network commands and tries to find the corresponding network in the routing table. If it finds it, it will add it to the BGP database. This is done outside of any iBGP or eBGP scope - it is related only to your own router and its decision process whether a network should or should not be added to the BGP database. If it does not find it, it will not add it. This is something completely different than with synchronization that tries to correlate routes discovered through iBGP with routes discovered through IGP. Synchronization is not about adding network, rather it is about validating their reachability.

I am not sure if I managed to highlight the fundamental difference. Please feel free to ask further!

Best regards,

Peter

Some of those statements seem contradictory:

On the one hand you say:

"you will ignore all such routes that are in your BGP database but which are not advertised by your internal routing protocol."

On the other hand, you say:

"it goes over its network commands and tries to find the corresponding network in the routing table. If it finds it, it will add it to the BGP database." Meaning that if it DOESN'T find it, it WON'T add it to the BGP database? Because then how could the premise in the first statement be true, "routes that are in your BGP database but which are not advertised by your internal routing protocol" ?? The second statement said that if they're not in the internal protocol then they don't get into the BGP database...

Hi Stuey,

If talking about iBGP synchronization, we are talking about networks that you already have in your BGP database because your iBGP neighbors have sent them to you via your iBGP peering to them. However, having a network in iBGP database does not alone mean that the network is already valid and will be used and distributed further. There are several consistency checks performed upon this network, like reachability of its next hop, and, if the synchronization is activated, also whether this network has arrived to your router also via an IGP such as OSPF.

Regarding the "network" command - yes, absolutely, if the BGP does not find the specified network in the routing table, it won't add it to its BGP database. But this is about originating a new route into BGP, not about distributing already known BGP networks further.

Okay, so, let's make an example. You have two edge routers in your network, PE1 and PE2, and an unspecified number of internal routers. The PE1 and PE2 have an iBGP peering and each of them also peers with some other AS. You own AS runs OSPF as its internal routing protocol.

Assume now that the PE1 receives information about a network 192.0.2.0/24 via its eBGP peering. It will forward this information via its iBGP peering to the PE2. Now, if synchronization is active on PE2, it will insert this network into its BGP database but it will not consider it as valid path until the 192.0.2.0/24 arrives also by OSPF or by any other IGP to the PE2. The path will be in the BGP database but it will not be considered as valid - it will just sit there until the network 192.0.2.0/24 will be also announced by OSPF. Clearly, this requires redistributing the BGP on the PE1 into OSPF. Only then the PE2 starts to consider this path valid and it will propagate it via eBGP further to its own peering AS. If, on the other hand, the synchronization is deactivated, the PE2 will not wait for the 192.0.2.0/24 to appear in OSPF. It will just check if the next hop is reachable and if is, it will consider the path valid, install it into its routing table and forward the information further to its eBGP neighbors. You do not wait for a network to appear in OSPF if you receive it via iBGP in order to declare it valid (of course, there are other checks that must pass before a path is considered valid). This is how the synchronization works. You can have networks in your BGP database and yet they can be considered invalid.

Now, imagine that the PE1 knows about an internal network 223.255.255.0/24. It may be a directly connected network or it may be somewhere in your AS but thanks to the OSPF, the PE1 knows about it. Now, you want to advertise this network in BGP so that other ASes know about it. Note that this network is previously unknown in BGP. So on PE1, you write "network 223.255.255.0" in the BGP configuration. The PE1 now checks its normal routing table whether there is a network 223.255.255.0/24, and if it is, the BGP will advertise this network to all BGP peers. If the network disappears from the routing table (somebody disconnects it), the BGP will withdraw it, and if it reappears, the BGP will again announce that it exists again. This is how the network command works.

Once again, do not confuse the synchronization feature that is used as an additional validity check on routes in BGP database with injecting previously unknown routes into BGP. These are two different things.

Best regards,

Peter

Thanks again Peter. I spent some time doing BGP setups in my lab last night and came to understand things already.

I have decided I need to spend more time at my console before I hurl questions into the forum.

(I was going to ask why synch shouldn't apply to eBGP; except if a BGP speaker gets a route via eBGP but also has that route in its IGP, then there's obviously a loop somewhere. In that case the BGP speaker would see its own AS in the AS-path and just not even let the route into its BGP table in the first place, right?)

Seth, although you are talking to Peter, I wanted to say a couple of things. NetPro members do not usually have a problem to answer questions or explain things, since reading the notorious manuals doesn't always help (although some other well-known communities seem to religiously believe that it does). If I remember correctly, you are studying for the BSCI and you are reading the famously very well-written certification guide we all have learnt to love and can't live without. If you want more specialized reading about BGP, I believe you should read "Internet Routing Architectures" by Sam Halabi. Reading the right book can save you days of standing in front of the computer (which has caused serious neck pain to me right now).

Going to your parenthesized question: I have partly answered in my previous post. Synchronization doesn't "apply" to iBGP or eBGP. This kind of loose use of terminology causes confusion. Synchronization occurs within the AS and doesn't allow routes to go to the outside of the AS if routers internal to the AS are not synchronized.

The general synchronization scenario involves an AS that provides transit service. This means that the transit ASx receives routes from an eBGP peer in ASy and passes those to an eBGP peer in ASz, so that ASz can reach ASy destinations via ASx. If synchronization is on in ASx, this AS needs to have the routes of ASy in its IGP. Because this is obvious waste and practically impossible, synchronization is turned off and other techniques are used avoid black-holing.

If a route is received via an iBGP session, that doesn't make it an AS internal route. If ASy sends a route to ASx border router1 and router1 passes it to ASx border router2 via iBGP, this route is still external to the AS. Synchronization says router2 has to have external route in its IGP before passing it to an external peer in ASz, and that is the problem in the first place. If router 1 has another eBGP peer of its own, router 1 doesn't have to synchronize with any other router within its AS, so it gets away with the synchronization rule.

Mohamed Sobair
Level 7
Level 7

Hi Maria,

As usual, an excellent explantion of BGP Synchronization rule

I have one comment though, that Synchronization is Only related to IBGP peers. The BGP speaker with Synchronization enabled wont advertise ANY IBGP learned route to any eBGP peers unless the routes are in the routing table. So , its mainly related to IBGP relationship, and doesnt effect have effect on eBGP relationship.

HTH

Mohamed

Mohamed, in my previous post I intentionally said that synchronization doesn't "apply" to iBGP or eBGP. The whole synchronization scenario contains a mix of eBGP peers, iBGP peers, and AS external routes. I think one needs to make clear to what they refer to when they say "apply to iBGP". Now that all is clear, I could say: synchronization applies to routes received from iBGP peers (not to the peers themselves) when sending those routes to eBGP peers. Or we could conspire to compress it exactly as it is in the very first post of this conversation, as long as we all have a common understanding of what we are referring to.

I said previously that, in my opinion, synchronization is not necessary in the eBGP peer1->single_router-> eBGP peer2 case, because the single_router is the only router in the transit path of its own AS. As I see it, the synch rule doesn't apply because it is not necessary (single_router is already in synch with itself), but you could say "it doesn't apply with eBGP just because" and provide no further explanation. It doesn't make much of a practical difference.

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