CCIE-type BGP Question

lamav · ‎05-24-2008

I have a question and one can refer to the diagram and explanation given at the following link as reference.

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

I need some fine tuning of my understanding of BGP synchronization and advertisements.

With the synch rule, an eBGP speaker must wait for its IGP to converge before advertising a prefix to an eBGP neighbor (different AS).

That makes sense and its easy to understand why. What I have been wondering is how the eBGP speaker knows when an IGP neighbor has converged. In the diagram, how does router B know that router E has learned of network 170.10.0.0?

Yes, router B can see the route for 170.10.0.0 in its own IGP table, but does that necessarily mean that router E's IGP has been informed? Let's say that router B's IGP was informed through another router, router Z. So, that tells router B that router Z's IGP process knows of 170.10.0.0, but what about router E? The importance of router E's IGP process knowing of the route, of course, is as explained in the dialogue -- router B knows that 170.10.0.0 is hanging off of iBGP neighbor router A, and he knows that to forward traffic to 170.10.0.0, he must go through router A. To do that, he has to go through E. So, bottom line, how does router B know whether router E's IGP process is informed of the route?

Am I confusing anyone?

I would love to hear from the senior engineers on here, especially.

Thanks very much

Victor

guruprasadr · ‎05-24-2008

HI Victor, [Pls RATE if HELPS]

Your concern is, there comes the concept of Synchronization. In the Diagram the AS100 is acting as a Transit AS.

The Router B will not advertise the Network 170.10.0.0 to AS400 before its IGP Cloud is converged.

There are several states for each Protocol to give the updates about the start & end of convergence about particular network between the Routers.

Let's wait for some more interesting POST.

Hope I am Informative.

Pls RATE if HELPS

Best Regards,

Guru Prasad R

lamav · ‎05-24-2008

Guru, you are informative, but about things I already understand :-)

To simplify, my question really is this: How does router B know when router E has learned of 170.10.0.0?

Richard Burts · ‎05-24-2008

Victor

There are perhaps several possible answers to your question. The simple answer is that there is only 1 IGP link coming into RouterB, in the diagram as drawn, and if the route is in the IGP table of RouterE then it must have learned it from RouterB.

Perhaps the larger perspective answer is that BGP assumes that the IGP will do its job correctly and if RouterZ knows then RouterB will also know. The job of the IGP is to converge so that all routers in the Enterprise have a correct understanding of what is reachable and where. If the IGP is not doing that then there is probably a bigger problem in the network than BGP synchronization.

HTH

Rick

HTH

Rick

mohammedmahmoud · ‎05-24-2008

Hi Everyone,

I totally agree with Rick, all that a BGP router do is that it looks in its routing table, if synchronization fails the debugs will show the famous "no valid path for x.x.x.x" message and the prefix is never sent, the rest of the job is left for the IGP to conduct.

BR,

Mohammed Mahmoud.

lamav · ‎05-24-2008

Rick/Mohammed. Thank you for your time and answers. Im happy to see the "big guns" on here. :-)

We always hear that "BGP has to wait for IGP to converge" when sync is on. So, I guess what I am asking is "how does the eBGP speaker know when IGP has finished converging"?

So, perhaps the answer is simply that router B will see a route for 170.10.0.0 in its IGP table that it learned from router Z's IGP process and then just assume (hope?) that that route also exists in router E's IGP table? I would have thought that the neighbor from whom it learned the route would be of interest. In other words, just because router Z knows the route, does that automatically mean router E does?

Victor

mohammedmahmoud · ‎05-24-2008

Hi Victor,

You are very welcomed :), yes BGP simply test the local routing table to see if the route is synchronized or not, the convergence is the IGPs role.

BR,

Mohammed Mahmoud.

Richard Burts · ‎05-24-2008

Victor

It is my understanding that BGP assumes that the IGP will function correctly and that if the route has been advertised to the BGP router by an IGP peer that it can assume that the rest of the IGP routers have also learned the route.

In a sense I believe that your question comes down to a question of how bullet proof is the sync requirement in BGP. (yes there are some scenarios in which some packets could get dropped) It amounts to a question about what happens if the IGP converges slowly and the BGP router forwards a packet and it gets to a router in the interior that has not yet learned the route. That interior router will drop the packets. If it is transitory state (if the IGP does converge and the interior router does eventually learn the route) then it is not a problem to BGP. If it is a permanent state and the interior router never learns the route then it is a broken IGP or a badly misconfigured network, and BGP can not protect against that.

HTH

Rick

HTH

Rick

lamav · ‎05-24-2008

Rick/Mohammmed:

Once again, thank you very much.

You both gave me very helpful answers, but Rick, you hit the freaking nail on the head, my man!

"It amounts to a question about what happens if the IGP converges slowly and the BGP router forwards a packet and it gets to a router in the interior that has not yet learned the route."

You lucidly formulated a question that I have been trying to form in my own spastic way for the last hour. :-(

OK -- so the answer is that the eBGP speaker will look in its own IGP table, as a manner of guaging convergence of the IGP, see the route in question, and assume that the IGP has converged. And if it has not, then a few packets will get dropped. If this condition remains, then there is a greater problem with the network's design/IGP deployment.

Can I please ask one more question?

Lets keep the same scenario and disable synchronization, OK?

Now, one would think that the IGP's convergence wouldnt play a role now that synch is disabled. BUT, given the rule for BGP advertisements; namely, that a route (or one of its subnets if auto summarization is on) must exist in the RIB table before the BGP speaker can advertise it, the IGP's convergence still plays a role and is required for the BGP speaker to advertise the prefix. That is, if a static route to null0 is not created...Is that the correct way of looking at it?

Victor

Kevin Dorrell · ‎05-24-2008

Victor, I think we need to consider two distinct cases: where the IGP is distance-vector, and where it is link-state.

In the case of distance-vector, each router operates autonomously. In this example, B will not advertise to D until is has a route in its routing table for the prefix. In this case it gets the route from an advertisment from E. In that case, it is a pretty fair bet that E has a route. You ask "Let's say that router B's IGP was informed through another router, router Z". But by the nature of DV protocols, this means B's route would be thru' Z, and Z must already know how to get to the prefix.

(There is a slight complication if the advertisment comes from a router with the DV "next-hop" someone else on the same segment, but even in that case it is fair to assume that the "someone else" already has a valid route.)

In the case of a OSPF, everyone has a consistent view of the topology. What matters is the existance of a path to the OSPF ASBR (router A in the example) that is advertising the BGP prefix as an OSPF type-5. If router B knows about the ASBR, then it knows how to get to it, and so does router E, even before the BGP prefix gets advertised.

This calls to mind the extra rule that synchronisation enforces where the underlying IGP is OSPF: that not only the router must have a route to the prefix, but the OSPF RID of the ASBR (2.2.2.2) and the BGP RID of the IBGP originator (2.2.2.2) must be the same.

I hope that makes sense. It is getting late and I need some sleep.

Kevin Dorrell

Luxembourg

lamav · ‎05-24-2008

Kevin, thank you sir. That was a great set of explanations. I appreciate your time.

Have a good night...

Victor

mohammedmahmoud · ‎05-24-2008

Kevin,

Nice explanation indeed, and congratulations on your CCIE, from what i've seen from you on this forum you sincerely deserve it. Are you thinking of a second one, or you had enough :)

BR,

Mohammed Mahmoud.

Kevin Dorrell · ‎05-25-2008

Thank you Mohammed. :-). I have to get over the euphoria of this one before I go for a second! I thnk my wife would kill me if I went for a second one immediately!

I shall take it easy for a while and try and consolidate. There is still a lot of stuff on R&S that takes me by surprise, and still a lot of stuff I need to investigate further.

Cheers,

Kevin Dorrell

Luxembourg

mohammedmahmoud · ‎05-25-2008

Totally agree with you, specially about the wife issue, i am still negotiating with her :)

About the consolidation, i also agree with you, but my work now focuses mainly on MPLS and thus i believe i'd go for a SP soon, beside consolidating a lot of common issues. Anyway good luck and enjoy :)

BR,

Mohammed Mahmoud.