Border redundancy and iBGP

[iores]

Hi,

in this document , it says that in case of External+Internal border where BGP is imported into LISP and LISP is redistributed back into BGP, tags are needed to prevent iBGP to LISP route imports and hence avoid potential loops.

Can someone, please, explain how routing loop will occur in such case?

[jalejand]

Because of BGP withdrawal timers, once an eBGP route is lost, it must be withdrawn from iBGP to the other border. Within that time, iBGP routes can get imported into LISP database, registered to the CP and then redistributed back to eBGP.

I've explained this symptom in a video/pptx in the past, you can use this link
https://www.ciscolive.com/on-demand/on-demand-details.html?#/session/1636062051596001zjzh

[iores]

@jalejand Great presentation, thank you. I have one more question regarding redistribution from BGP to IGP on fusion routers. In some Cisco document I have read that route tagging should be used to avoid loops. If eBGP uses AD of 20, how loop can occur if AD of any IGP behind fusion routers is greater than 20?

[jalejand]

Not necessarily a loop, but sub-optimal routing can happen.

Lets say that you have two Fusion routers. Both facing eBGP down the fabric and both facing OSPF upstream and you redistribute BGP into OSPF and OSPF into BGP. Let's say 10.10.10.0/24 is a prefix learned from BGP and its redistributed into OSPF.

At first glance, this will work just fine, 10.10.10.0 will be reachable from BGP because AD of 20 wins over 110, but what if Fusion 2 loses its eBGP route for a moment?

1) Fusion 2 loses eBGP peering, removes 10.10.10.0/24 from the BGP table
2) BGP table is removed from the RIB, OSPF route from Fusion 1 is preferred (AD 110)
3) OSPF route in the RIB is redistributed into BGP; it creates a BGP route with weight of 32768 (this route will no longer have the original AS in its AS-PATH, which can lead to other problems)
4) Fusion 2 eBGP peering is recovered, 10.10.10.0/24 is now in the BGP table, but it cannot win over the OSPF redistributed route, weight of 32k is preferred, it will not go up to the RIB in this state.

Fortunately, thats as far as it can go as downstream BGP routers will prevent a redistributed OSPF route being sent from Fusion 2 to Border  and then to Fusion 1 (as AS-PATH from Fusion 2 will be denied at Fusion 1). Only with the following scenarios you  will have a loop.

Fusion 1 and Fusion 2 are in different AS
Fusion 1 and Fusion 2 have iBGP and BGP redistribute internal is enabled
Borders remove Fusion 2 AS-PATH by importing iBGP routes into LISP  without any form of tagging/control/policy

Regards

[iores]

@jalejand Do you happen to have any materials on the last three scenarios?

[iores]

@jalejand 

In step 3, you are assuming iBGP between fusion routers? Which fusion router redistributes the OSPF route into BGP? If fusion 1, it still has eBGP route. If fusion 2, the refistributed route will not be visible on fusion 2 itself. What am I missing?

[georgehewittuk1]

Is this not solved by using pub/sub fabric?

[MHM Cisco World]

I think @iores study  bgp and this not real network.

@iores I will start study DC interconnect next year (I hope) but now I will share some doc. 

I will send by private messages 

Thanks 

MHM

[iores]

I am studying border-fusion routing and possible loop scenarios for various types of deployment.

[MHM Cisco World]

I know friend I follow your posts and I know you hard study bgp.

For your other post of bgp and ospf and suboptimal' I will try run lab abd answer few of your Q (not all) since your Q need alot of work.

Have a nice summer 

MHM