Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

Discussion:Cisco Doc. BGP Practical Example

Hi,

I would like to discuss the case studies I went through in the following URL

http://www.cisco.com/warp/public/459/bgp-toc.html#sec5

It would be helpful if few techno's could join in this discussion.

Typically I want to discuss following

1. Mask Difference issue between BGP,OSPF redistribution

2. Few BGP Table entry issues at RTA & RTB routers in the example

Once you gone through the specified URL I would like rise my questions,Pls. let me know.

Thanks,

Dinesh.K

6 REPLIES
New Member

Re: Discussion:Cisco Doc. BGP Practical Example

Hi,

Could anybody here would like to join the discussion to clarify few things.Your response is most required.

Thanks

Dinesh

New Member

Re: Discussion:Cisco Doc. BGP Practical Example

Hi

i would like to join..

i had a quick glance about the example..what do u want to ask about in the BGP table ?

Thanks

New Member

Re: Discussion:Cisco Doc. BGP Practical Example

Hi,

Now,

1. Why do I need to remove the synchronization at RTA and RTB routers to advertise 202.250.15.0 & 202.250.13.0 respectively.

2. What relation does mask difference and synchronization has in OSPF & BGP scenario.

3. In the document after "no sync", in the RTA "sh ip bgp" says 195.211.10.0 network has next hop two entries(ofcourse one is best route). Similary RTB "sh ip bgp" displays "200.200.10.0" has two next-hop entries in the BGP table. Why not other networks has same kind of two next-hop entries, though they can be reachable in two ways.

Kindly, let me know your views

Thanks

Dinesh

Gold

Re: Discussion:Cisco Doc. BGP Practical Example

1) Why do you need to remove synchronization? First ask, "what is synchronization?"

Imagine the following network topology: You are an Internet service provider. RouterA is your upstream Internet provider, and RouterB is your border with them. RouterD is a multihomed customer of yours, and RouterC is your border with them. You own RouterB, RouterC, and everything inbetween. There are several routers and switches and such between RouterB and RouterC that do not run BGP, but they run an IGP.

RouterA <-> RouterB <--- large internal network/IGP ---> RouterC <-> Router D

RouterA and RouterB are directly connected and speak EBGP with each other, and RouterC and RouterD are likewise directly connected and speak EBGP with each other. RouterB and RouterC speak IBGP with each other, and this passes through many IP hops.

Since all routers between your BGP borders aren't running BGP, it is required that you distribute your BGP routes into your IGP, so that all the routers inbetween know how to get to the BGP-routed destinations.

Suppose you have an important network, say 10.150.11.0/24, hosting a very important website, www.example.com. You receive a new announcement from RouterA for 10.150.11.0/24. RouterB receives this and redistributes it into IGP and sends it directly via BGP to RouterC at the same time. RouterC then relays this announcement to your customer, RouterD.

This is where things get ugly. If your network and your IGP are large and complex, the route for 10.150.11.0/24 takes a relatively long time to be distributed across your network. Meanwhile, you have told your customer's router that you can reach www.example.com. The customer may send traffic destined for www.example.com to you. RouterC receives this and passes it along to what it sees as the shortest path to RouterA (or RouterB, depending on whether or not you have set next-hop-self). An internal router in your network five or six hops away from RouterB hasn't learned about the 10.150.11.0/24 prefix yet, has no idea what to do with it, and discards the traffic. This continues until your IGP has fully converged. This is very bad, since your customer may have had a perfectly valid and working path to 10.150.11.0/24 that you said you had a better path for, but in fact are blackholing the traffic.

Synchronization prevents this from happening by stopping RouterC from announcing that prefix to RouterD until RouterC can reach that route via your IGP. In this way you have some measure of confidence that you can actually pass traffic for networks that you announce. If you have BGP running on all the routers between RouterB and RouterC and you are not distributing BGP into IGP, synchronization has no value and must be disabled.

It is important to note that this is a contrived example and a service provider network would never be set up this way in the real world. Synchronization doesn't have much use in modern networks, mostly because distributing full BGP routes into your IGP is considered insane and will melt your network.

To get back to your question, RTB will not consider 203.250.13.0/24 and 203.250.14.0/24 for insertion in its routing table and propogation to its peers because it's waiting for those routes to arrive via OSPF. The same applies for 203.250.15.0/30 on RTA. Until that happens, "synchronization" has not occured. This is a scenario like above, where the network is structured such that you are expected to distribute your BGP routes into your IGP.

2) What difference does the netmask make?

Quoting from the scenario: "Let's also turn off synchronization on RTA in order for it to advertise 203.250.15.0, because it won't sync up with OSPF due to the difference in masks. We'll keep sync off on RTB in order for it to advertise 203.250.13.0 for the same reason."

RTB is configured to announce 203.250.15.0/24, however the only route it has IGP or otherwise is for 203.250.15.0/30. The route in IGP needs to match exactly in order for synchronization to enable that route. In the scenario, instead of making an IGP route for 203.250.15.0/24, they simply disable synchronization.

3) Why don't all routes show all potential paths?

BGP is a distance-vector protocol on which Cisco implements split horizon. Taking the route 200.200.10.0 in RTB for an example - RTB learns the route for 200.200.10.0 from RTD and from RTA. RTA only has one route for 200.200.10.0, via RTC. Why doesn't RTA show RTB as another path for that network? Since RTB has learned of 200.200.10.0 from RTA, it does not tell RTA that it has a route for 200.200.10.0 - this could create a routing loop.

I understand some router vendors (Juniper) do not implement this, as it may not be strictly necessary or desirable for BGP. Search CCO or Google for an explanation of split horizon.

New Member

Re: Discussion:Cisco Doc. BGP Practical Example

Hi jason,

My sincere thanks for your efforts. Mask difference is a long time mind blowing issue for me.Thanks once agin for the great answer.

Regds,

Dinesh

Gold

Re: Discussion:Cisco Doc. BGP Practical Example

Dinesh,

A very good explanation form Jason on his post, but if you really want to get to grips with BGP etc, then I'd suggest that you go and purchase a very (actually excellent) book by a very fine expert - Bassam Halabi / Internet Routing Architectures - cisco press. I'm confident that this will answer all your questions on formentioned subject.

Regards -

162
Views
5
Helpful
6
Replies
CreatePlease to create content