Route looping issue.

[sutharhemant90]

Dear all,

Attached is the file of config where i am facing the routing loop issue when i do the bgp neighbor ship 'shut and no shut' on DCP router. my trace route to 1.1.1.1 (loopback address of BRANCH router) from the DCS router will get loop.

My Network requirement are as below:

1. I am running EIGRP between DCP and DCS router.

2. BGP routing protocol is running between CE to PE.

3. I have applied local preference on TCL1 router e.g. local preference 200 is set for DCP orignate network and 100 is for DCS orginate network,

4. attached diagram is made for active active mode.

kindly rectify the issue if i am doing any wrong thing...

Thanks in advance

[sutharhemant90]

Please help me on this...

[Peter Paluch · Accepted solution]

Hello Hemant,

Well, it's Sunday and pushing people to solve your issue in two hours isn't going to speed up the process - this isn't TAC, this is a voluntary forum

Anyway, regarding your issue. This is what I believe is the sequence of steps causing the routing loop:

1. When the BGP peering between TCL1 and DCP is deactivated, DCS will learn about 1.1.1.1 from TCL1, redistributes it into EIGRP and advertises it to DCP with AD=170. Hence, DCP knows about the network from DCS via EIGRP. As the BGP process on DCP still runs, just a peering is deactivated, you may verify using show ip bgp that DCP still has the 1.1.1.1 network in the BGP database, thanks to the redistribution from EIGRP into BGP. At this point, DCP points to DCS, and DCS points to TCL1.
2. When the BGP peering between TCL1 and DCP is reestablished, BGP on DCP advertises 1.1.1.1 to TCL1 in a race condition (DCP is sooner at sending the update than TCL1). Because the local preference on TCL1 is set to 200 while the default local preference for all other route sources is 100, TCL1 prefers BGP-learned routes from DCP rather than trusting the original path towards Branch.
3. What you now have is TCL1 pointing back to DCP, and DCP still pointing to DCS and DCS pointing to TCL1. A routing loop is thus created.

A correct solution would be to make a PE ignore routes received from a customer site that have been advertised to the site via the same or another PE. Ideally, this would be accomplished by tagging the routes at TCL1 when sending them to DCP and DCS and dropping the routes received from DCP and DCS if they carry the same tag. The problem is, however, that DCP and DCS perform BGP-and-EIGRP redistribution and the tag value may be lost in this redistribution, voiding this protection.

An alternative way of solving this is to use the BGP Site of Origin extended community attribute. Although originally created to prevent routing loops that occur for customer site-internal routes, it should help in this scenario as well:

1. TCL1 will mark both DCP and DCS BGP peers with a particular identical SoO value
2. Routes received from both DCP and DCS will be marked on TCL1 with the configured SoO value
3. A route marked with a SoO value will never be advertised from TCL1 to a BGP peer configured with the same SoO value

How is this going to help us here? Well, assume that after the BGP peering between TCL1 and DCS comes up. DCS sends the 1.1.1.1 to TCL1, and TCL1 will mark it with a SoO attribute, say, SoO:64670:1. It will at first converge towards DCP, creating a temporary routing loop. However, as the 1.1.1.1 carries the SoO attribute of SoO:64670:1, it must not be advertised to DCS which carrier the same SoO attribute. Therefore, TCL1 shall withdraw the 1.1.1.1 from DCS. The 1.1.1.1 will thus be removed from DCS's routing table and will be removed from EIGRP as well. This in turn will cause the DCP to stop advertising the 1.1.1.1 in BGP back to TCL1, breaking the loop and allowing the TCL1 to reconverge on the correct path. Note that this solution is not perfect in that it potentially allows for a temporary routing loop to occur.

The configuration on TCL1 is very easy - simply add these commands:

router bgp 4755
 address-family ipv4 vrf TATA-DBC
  neighbor 10.80.80.2 soo 64670:1
  neighbor 10.90.90.2 soo 64670:1

This should do the trick. Please note that as I explained earlier, the SoO is originally intended for a different purpose but it does prevent a route learned from a customer site to be readvertised to that site, which is a part of the routing loop problem you are facing.

If you want to read more about SoO attribute please visit these documents and discussions:

http://www.cisco.com/en/US/docs/ios/ios_xe/iproute_bgp/configuration/guide/irg_neighbor_soo_xe.html

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/L3VPNCon.html#wp359897

https://supportforums.cisco.com/message/3536081#3536081

https://supportforums.cisco.com/message/3740364#3740364

Best regards,

Peter

[sutharhemant90]

Hello Peter,

      I really appreciate your help on this. i have the some doubts and i will get in touch with you at the earliest.  once again thanks on this.

[sutharhemant90]

Dear Peter,

     below  is the diagram where i have

mentioned the details, if i apply the site of

origin on my PE router than how my internal

network 192.168.7.0, 8.0 & 9.0 will communicate

with 192.168.10.0, 11.0 & 12. will they

communicate through internally eigrp or through

the BGP.

I have applied the prefix list to DR subnet as

shown below.

DRP:

192.168.10.0, 11.0 & 12.0 (Local preference 300)
and for rest of network the LP will only 50.

DRS

192.168.10.0, 11.0 & 12.0 (Local preference 250)
and for rest of network the LP will only 40.

Note: Branch will get the update the update of DR

network from the DR only so i have set the local

preference high to the DR subnet.

[Praveen AR]

Hi Hemant,

I don't  think there will be a  loop for internal eigrp routes because of AD 90

[sutharhemant90]

Dear Peter/Pravin,

But my internal network 192.168.7.0, 8.0 & 9.0 will communicate

with 192.168.10.0, 11.0 & 12. will they

communicate through internally eigrp or through

the BGP(MPLS).

[sutharhemant90]

my DC to DR point to point link also working on EIGRP.

[Praveen AR]

Hi Hemant,

For DRP  are you  running BGP in dfferent AS.

You need to match the routes  using access-list and change AD of the routes(192.168.7.0,8.0,9.0)    if you want o commmunicate through eigrp.

Change according to your IP routing table.

Also SOO as peter told you to avoid loop.

Post traceroute output which can help

Regards

Praveen

[Praveen AR]

Hi Hemant

Could you please paste output of traceroute to 1.1.1.1

need toknow which path it is getting looped

Regards

Praveen

[sutharhemant90]

Hello Pravin,

    We have not done anything on our routers for orgnization, however our IPs are commnucating through EIGRPonly. we have only mentined configuration in the above snapshot. i dont know why is it happening? i am also trying to understande that only.

Note: our point to point link is being used for only DC DR communication. the synchronization of the servers will heppen throgh the EIGRP only.

Thanks.

Hemant

[sutharhemant90]

Dear Pravin,

   my routing loop issue has been resolved as per the said statement of Mr. Peter. but the query is related to the my DC DR synchrinization which is happening through point to point link only which is on EIGRP and we are using differernt AS number for BGP. I wanted to just know that is there is there anything which is prefering EIGRP instead of BGP.

Note: I have not made DC DR connfiguration in LAB but it is happening in my orgination and configuration is same as mention above in the Diagram.

[Praveen AR]

Hi Hemant,

check shutting down EIGR link and see  routes is   getting through BGp or not.

You need to check routes are recived through both BGP and EIGRP.

[sutharhemant90]

Hi,

As per the SOO rules, the router will not re advertise to that one from where it is received and in the mentioned above diagram my network for 192.168.10.0 will be received on TCL1 from two ways. one from the DCP router and the second from the DRP. now you tell me which route will be dropped?? i am thinking, this is the the reasone where my internal eigrp is communicaing through the intarnal eigrp instead of EBGP.

[Peter Paluch]

Hello Hemant,

I apologize, I was out of this thread for several days and I see certain advances in your issue. I am confused, though, whether there is still something that needs to be corrected in your setup. Can you perhaps try to concisely summarize the points that still needs solution?

Best regards,

Peter