BGP explanation of sync rule

Answered Question
May 4th, 2009

All,

I'm having a hard time understanding the "no synchronization" line in bgp.

http://www.cisco.com/en/US/docs/internetworking/case/studies/icsbgp4.html#wp19382

The link shows a topology where an IGP is running between router, but iBGP is running between the two routers.

If I understand correctly, synchronization requires the IGP to know about the route before BGP will redistribute it to other neighbors. (Right?) If that's the case, if I were to look on RouterB's (the far side of iBGP) routing table, wouldn't I see a route point to the network that IGP doesn't know about, to RouterA as the next hop?

So, I envision RouterA knowing about 172.10.0.0, and it doesn't get redistributed into IGP when it hits router A, but instead gets propagated to it's iBGP peer (RouterB). Wouldn't RouterB have an entry in its routing table like:

B 172.10.0.0 [20/0] via 2.2.2.2

Does sync or "no sync" allow for router B to propagate this route to RouterD? I would think "no sync" if I'm trying to keep BGP from requiring the IGP knowing aobut the 172.10.0.0 subnet.

I may have just talked myself through it. =)

John

I have this problem too.
0 votes
Correct Answer by thotsaphon about 7 years 7 months ago

John,

Don't forget the rule. The router will not modify the next-hop when it sends routes via iBGP. That's why RouterB will see 2.2.2.1 as the next-hop.

RouterB may think about how to get there via IGP. Or you may use the nexthop-self command on the RouterA for some reason.

To be honest this document is good but for this part of your question it doesn't give you more configuration.

Toshi

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
thotsaphon Mon, 05/04/2009 - 06:32

John,

What document says is that you have to concern about when you have transit routers that are not running BGP.

So, I envision RouterA knowing about 172.10.0.0, and it doesn't get redistributed into IGP when it hits router A, but instead gets propagated to it's iBGP peer (RouterB). Wouldn't RouterB have an entry in its routing table like:

B 172.10.0.0 [20/0] via 2.2.2.2

No, If RouterB had network/2.2.2.[1-2] in the routing table.To make sure that the next-hop can be reach.Then it should be look like this.

B 172.10.0.0 [20/0] via 2.2.2.1

You may think about the nexthop-self on the RouterA as well.

After that RouterB will advertise this network to RouterD. However either RouterB or RouterD will go to network/172.10.0.0. They have to use RouterE as a transit path. What happens when RouterE trying to forward packets to 172.10.0.0? It has no idea about this. So dropping it. What you are going to do is to enable synchronization and redistribute those routes on RouterA to make IGP knows about this.

Toshi

John Blakley Mon, 05/04/2009 - 06:41

Toshi,

"No, If RouterB had network/2.2.2.[1-2] in the routing table.To make sure that the next-hop can be reach.Then it should be look like this.

B 172.10.0.0 [20/0] via 2.2.2.1"

Please correct me if I'm wrong, but wouldn't RouterB only have a next hop of 2.2.2.1 in its routing table IF it was learned through peering with RouterC? In the topology, it doesn't learn of 172.10.0.0 from RouterC, it would learn it from RouterA which led me to believe that it's next hop address would be 2.2.2.2. There's no peering between RouterB and RouterC. Am I incorrect?

Thanks,

John

Correct Answer
thotsaphon Mon, 05/04/2009 - 06:47

John,

Don't forget the rule. The router will not modify the next-hop when it sends routes via iBGP. That's why RouterB will see 2.2.2.1 as the next-hop.

RouterB may think about how to get there via IGP. Or you may use the nexthop-self command on the RouterA for some reason.

To be honest this document is good but for this part of your question it doesn't give you more configuration.

Toshi

lamav Mon, 05/04/2009 - 06:33

John:

You're rambling -- again! :-)

The point with synchronization is that the IGP must have a route in its routing table before BGP advertises it. It's pretty straightforward, really, and I think you understand it fine.

The requirement for IGP-BGP synchronization is completely mitigated if you have full iBGP peering.

Are you OK with this now?

Victor

Harold Ritter Tue, 05/05/2009 - 06:21

John,

Just to add to what the other posters have said and as I have mentioned many times on this forum, synchronization is kind of a legacy from the past and is turned off by default in IOS.

There is many issues related to enabling synchronization. Firstly, if the number of routes being propagated via iBGP is large, it simply doesn't make sense to redistribute these same routes in the IGP. Secondly, if you use OSPF as your IGP and you also use BGP route reflectors in your network, synchronization simply won't work. The reason being that your BGP neighbor router id and the OSPF router id will not match, which will prevent the synchronization from happening.

Regards

ex-engineer Tue, 05/05/2009 - 06:49

Harold:

Hope you are doing well today.

May I ask you a few questions?

1.) Regarding iBGP and redistributing into an IGP, if one is running iBGP and it is fully meshed, isn;t it the case that redistributing into the IGP is not an issue because it is no longer needed? In other words, in your statement, do you mean that iBGP is deployed only on, say, the edge routers, but not on the interior routers, as is the case displayed in the diagram that John posted?

2.) This is sort of related, in concept at least, to question #1. If you are deploying a BGP route reflector to help scale iBGP and create a fully meshed BGP network, why would you need to redistribute into the IGP?

Thanks for your time.

Harold Ritter Tue, 05/05/2009 - 07:20

Joe,

I am doing great. Thanks. I hope you are doing well too.

I was simply stating why it is a bad idea to enable synchronization in general.

1) Yes, this would indeed be the only reason for redistributing your BGP routes into the IGP and use to be the premise for the BGP synchronization. This scenario is not recommended if you have lots of BGP routes.

2) I was just mentioning it as an issue for someone who would want to enable synchronization intentionally (no good reason for that) or who would have an older IOS, where synchronization was enabled by default. Disabling synchronization is definitely the recommended approach.

Regards

ex-engineer Tue, 05/05/2009 - 07:37

Thanks, Harold.

I appreciate your explanations and can appreciate the points you were conveying. I just wanted to make sure that I understood you correctly. It's been a while since I was "in the trenches" as a network engineer, so I like to ask questions to refresh and relearn.

I've gotten some excellent help on here from several people.

Thanks again!

Actions

This Discussion