cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1769
Views
5
Helpful
7
Replies

iBGP loop prevention feature for IGP mutual route-redistribution

abolampe
Level 1
Level 1

I've been shown a loop prevention feature in iBGP and I'm trying to find where it is documented.

 

This is a lab modelling exercise we are doing -

We are re-distributing from BGP to OSPF and also have network statements for the same prefixes.

.

There are 2 routers, R1 and R2, doing the redistribution.

Without iBGP running between the routers, and when the local OSPF router is down, R1 can learn the route from BGP and redistribute it into OSPF.  R2 learns the route by OSPF, injects it into BGP.  Once in BGP it is the best route, having a higher weight than the external BGP route.  (Presumably the OSPF route is injected to BGP before the eBGP route is learnt).  R2 then advertises the local route out to MPLS with a null AS path, potentially causing a loop or sub-optimal routing.

 

If we enable iBGP between R1 and R2 this does not happen.  Immediately iBGP comes up R2 sees the eBGP route as best.  The OSPF route is no longer in the routing table and no longer injected into BGP.  iBGP has less preferable to eBGP and the locally injected OSPF route (due to weight) and has a higher admin distance, so its difficult to explain this in terms of path selection.  I'm told it is a feature of iBGP, presumably to prevent loops ?

 

I'm not looking for advice on how to improve this design, or the problems of mutual route-redistribution, just trying to understand what iBGP is doing.

 

thanks

 

 

 

1 Accepted Solution

Accepted Solutions

abolampe
Level 1
Level 1

I think I have found the answer.

When you enable iBGP, R2 propagates the OSPF learned route back to R1.  Because the OSPF injected route has a zero AS path it becomes the best route on R1.  iBGP routes are not by default re-distributed into into an IGP, so this effectively kills the route in OSPF.  The locally injected route on R2 disappears, leaving no trace of what happened.

Reading this article helped my understand it.

"Unable to Redistribute iBGP Learnt Routes into an IGP such as EIGRP, OSPF
Route Redistribution is used to propagate routes learned with the use of one protocol, into another routing protocol. When BGP is redistributed into an IGP, only eBGP learned routes get redistributed. The iBGP learned routes known on the router are not introduced into the IGP in order to prevent routing loops from being formed.

By default, iBGP redistribution into IGP is disabled. Issue the bgp redistribute-internal command in order to enable redistribution of iBGP routes into IGP. Precautions need to be taken to redistribute specific routes using route maps into IGP."

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5242-bgp-ospf-redis.html

View solution in original post

7 Replies 7

can you draw the topology ?

Hello
The first part of your OP I think I understand,However the OP is hard to follow after that , So as suggested by @MHM Cisco World  possibly you could submit a topology diagram show we can visualise the query you have?


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

abolampe
Level 1
Level 1

Diagram below.  I can't remember whether R1 and R2 had an OSPF neighbor relationship, I believe they did, however I've been told it was tested both with and with out the OSPF neighbor in place.   iBGP prevented the race condition occurring, and also 'bumped' the locally injected OSPF route out of R2 when iBGP was established.

Hello


@abolampe wrote:

I'm not looking for advice on how to improve this design, or the problems of mutual route-redistribution, just trying to understand what iBGP is doing.


Now I see your diagram it makes more sense, by default EBGP/IBGP routers need to be able to advertise their updates to each other and for that to happen all IBGP rtrs within an ASN need to have peering to each otherwise all internal bgp rts won’t be updated correctly.
However, by design any update received from an IBGP rtr can ONLY readvertise that prefix to another EBGP rtr. And not any IBGP rtr
So as/when R1/R2 dont have that necessary IBGP peering to each other, Their internal BGP ASN isn't being updated correctly, the EBGP prefix they receive is being redistributed into OSPF and then back into the local internal ASN instead of both IBGP rtrs updating each directly with their received EBGP prefix.

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

I don't think that's it, see my reply about iBGP not being redistricted in an IGP

abolampe
Level 1
Level 1

I think I have found the answer.

When you enable iBGP, R2 propagates the OSPF learned route back to R1.  Because the OSPF injected route has a zero AS path it becomes the best route on R1.  iBGP routes are not by default re-distributed into into an IGP, so this effectively kills the route in OSPF.  The locally injected route on R2 disappears, leaving no trace of what happened.

Reading this article helped my understand it.

"Unable to Redistribute iBGP Learnt Routes into an IGP such as EIGRP, OSPF
Route Redistribution is used to propagate routes learned with the use of one protocol, into another routing protocol. When BGP is redistributed into an IGP, only eBGP learned routes get redistributed. The iBGP learned routes known on the router are not introduced into the IGP in order to prevent routing loops from being formed.

By default, iBGP redistribution into IGP is disabled. Issue the bgp redistribute-internal command in order to enable redistribution of iBGP routes into IGP. Precautions need to be taken to redistribute specific routes using route maps into IGP."

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5242-bgp-ospf-redis.html

Hello
In relation those two rtrs they are ebgp/ibgp rtrs they not pure ibgp, any route from an ebgp rtr or igp would classed as external, So say if/when those two rtrs advertise that igp route to each other, you don't want it to be readvertised back into ospf for loop prevention


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Review Cisco Networking for a $25 gift card