cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
548
Views
2
Helpful
10
Replies

hot to resolve this issue loop in ibgp when using RR

BaijuPaul
Level 1
Level 1

when in my practice lab i implemented 2 server in route reflector. when forming the neighborship with R3 then connection los for other RR client. 

what is the reason is this ?

B 1.0.0.0/8 [200/0] via 2.2.2.1, 00:56:24
B 2.0.0.0/8 [200/0] via 1.1.1.2, 01:19:46
B 10.0.0.0/8 [200/0] via 4.4.4.2, 01:37:18
100.0.0.0/32 is subnetted, 3 subnets
B 100.1.1.2 [200/0] via 3.3.3.1, 00:56:24
B 100.1.1.4 [200/0] via 4.4.4.2, 01:37:18

sho ip bgp

Network Next Hop Metric LocPrf Weight Path
*>i 1.0.0.0 2.2.2.1 0 100 0 i
* i 4.4.4.2 0 100 0 i
* i 2.0.0.0 3.3.3.1 0 100 0 i
*>i 1.1.1.2 0 100 0 i
* i 3.0.0.0 2.2.2.2 0 100 0 i
* i 3.3.3.1 0 100 0 i
*> 0.0.0.0 0 32768 i
* i 4.0.0.0 4.4.4.2 0 100 0 i
*> 0.0.0.0 0 32768 i
* i 10.0.0.0 1.1.1.1 0 100 0 i
*>i 4.4.4.2 0 100 0 i
* i 20.0.0.0 2.2.2.1 0 100 0 i
* i 1.1.1.2 0 100 0 i
Network Next Hop Metric LocPrf Weight Path
*> 40.0.0.0 0.0.0.0 0 32768 i
* i 100.1.1.1/32 2.2.2.1 0 100 0 i
* i 1.1.1.2 0 100 0 i
* i 100.1.1.2/32 2.2.2.2 0 100 0 i
*>i 3.3.3.1 0 100 0 i
*> 100.1.1.3/32 0.0.0.0 0 32768 i
* i 100.1.1.4/32 1.1.1.1 0 100 0 i
*>i 4.4.4.2 0 100 0 i

 

R4#sho ip route loops
->default:ipv4:base 1.0.0.0/8 -> base 2.2.2.1 bgp 01:01:10 N
default:ipv4:base 2.0.0.0/8 -> base 1.1.1.2 bgp 01:01:10

1 Accepted Solution

Accepted Solutions

Hello @BaijuPaul 

Based on the cfg you shared, it seems R1-3 are the RR
R2/R4 should peer ONLY to each RR and not each other.
R1/R3 (if applicable should have a direct connection to each other and have an non client IBGP peering
Lastly the RR should share the SAME CLUSTER-id as such this will make both RRs be in the same RR cluster and will negate any unwarranted loops occurring,

 


@MHM Cisco World wrote:
ip as-path access-list 1 permit ^$
neighbor x.x.x.x filter-list 1 out

Add above in R2' this prevents R2 to be transit AS between two RR
R4 must be RR client for both RR and there must be no ibgp between two RR 


Apologies @MHM Cisco World  this is not correct, the as-path filter isn't necessary, the RRs SHOULD have a non client ibgp peering with each other and with them being in the same cluster will negate any loops, by the presence of the the cluster -id, it if see this in any route with it own cluster-id , that route will get dropped (just like the as-path check)
 


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

View solution in original post

10 Replies 10

MHM

Hello @MHM Cisco World ,

all routers are in BGP AS 500 so this is an iBGP context , the use of ip as path filter play a role only on eBGP sessions as far as I know .

For OP @BaijuPaul : you should review your configurations using loopback address as BGP endpoint using neighbor x.x.x.x update-source loop0

You can use OSPF to advertise loopback interfaces between routers in this way you will have stable iBGP sessions even usiing RR servers.

Edit:

your issues are likely caused by the fact you have auto summary enabled we see Class A major networks 1.0.0.0/8 and so on this can lead to problems if packets for a major network are sent to the wrong interface. With no auto-summary networks are advertised with their prefix length with no summarization performed when crossing a major network boundary.

Edit 2:

no issues with auto-summary you are using /8 prefixes on interfaces

ip address 2.2.2.2 255.0.0.0
 

 

consider to use more specific subnets on the links and to use cluster ID on the RRS servers if there are two RRS.

Hope to help

Giuseppe

 

Only remove ibgp between two RR and dont make each one route-refoect to other and check.

You must see LO advertise by two RR in both side.

MHM

Hello @BaijuPaul 

Based on the cfg you shared, it seems R1-3 are the RR
R2/R4 should peer ONLY to each RR and not each other.
R1/R3 (if applicable should have a direct connection to each other and have an non client IBGP peering
Lastly the RR should share the SAME CLUSTER-id as such this will make both RRs be in the same RR cluster and will negate any unwarranted loops occurring,

 


@MHM Cisco World wrote:
ip as-path access-list 1 permit ^$
neighbor x.x.x.x filter-list 1 out

Add above in R2' this prevents R2 to be transit AS between two RR
R4 must be RR client for both RR and there must be no ibgp between two RR 


Apologies @MHM Cisco World  this is not correct, the as-path filter isn't necessary, the RRs SHOULD have a non client ibgp peering with each other and with them being in the same cluster will negate any loops, by the presence of the the cluster -id, it if see this in any route with it own cluster-id , that route will get dropped (just like the as-path check)
 


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

thanks 

I add tips about if he using different AS or not' I use smart phone I will use PC to check config he use

Thanks again 

MHM

when i try with different and same cluster id in for both RR- Server then same issue. but once i remove the neighborship with R3 and R4 then working fine.  

let me try with loopback interface 

Friend as I mention before only remove ibgp between RR and issue will solve 

Did you ever try that?

MHM

Hello
As stated, R1/R3 (RRs) need to have a non client ibgp peering between each other and the RC just need to have peering to each RR and NOT each other.

pauldriver_0-1725025040635.png

 


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

this correct

MHM

Are issue is solve or not?

If not mention me and I will run lab check what going on 

MHM

Review Cisco Networking for a $25 gift card