BGP RR cluster ID confusion
I have a question regarding BGP RR cluster id.
check to check if you came across or interested
in https://www.juniper.net/customers/csc/documentation/techdocs/downloads/pdf/350009.pdf.
page 6:
I can understand item 1, but for item 2, i have a hard time to understand. for example in sybex jncip book, R3 is RR for R1 and R2, R4 is also the RR for R1 and R2. R3 and R4 have same cluster ID. item 2 makes me think that if on R4 to config R3 as a non-client, if R1 and R4 IBGP is dead, R4 will get the routes coming from R1. but I tested, R4 still can not get the R1 route .
Am i miss sth?
check to check if you came across or interested
in https://www.juniper.net/customers/csc/documentation/techdocs/downloads/pdf/350009.pdf.
page 6:
- if a route is recieved from a client in a cluster that has our own cluster ID(for the same cluster), the route is discarded and not installed in the routing table.
- if a route is received from a non-client that has our own cluster ID, the route is accepted because it might have to be reflected to be another cluster if the router is supporting multiple clusters.
I can understand item 1, but for item 2, i have a hard time to understand. for example in sybex jncip book, R3 is RR for R1 and R2, R4 is also the RR for R1 and R2. R3 and R4 have same cluster ID. item 2 makes me think that if on R4 to config R3 as a non-client, if R1 and R4 IBGP is dead, R4 will get the routes coming from R1. but I tested, R4 still can not get the R1 route .
Am i miss sth?
Comments
-
rossonieri#1 Member Posts: 799 ■■■□□□□□□□hi cheng,
hmm, i'll try to understand your question :R3 is RR for R1 and R2, R4 is also the RR for R1 and R2. R3 and R4 have same cluster ID. item 2 makes me think that if on R4 to config R3 as a non-client, if R1 and R4 IBGP is dead, R4 will get the routes coming from R1. but I tested, R4 still can not get the R1 route .
perhaps you mean if R1-R4 IBGP is dead then R4 will get the R1 route from R3? because R3 is non RR -client?the More I know, that is more and More I dont know. -
zrcheng Member Posts: 44 ■■□□□□□□□□yes, since i config R3 as R4's non-client, according the article, i should get R1 route from R3, right? but my lab result is negative. using "keep all" i can find they are hidden routes.
-
rossonieri#1 Member Posts: 799 ■■■□□□□□□□interesting.
did you lab it up using that jncip book scenario?
what did the #run sh route prot bgp inactive-path say?the More I know, that is more and More I dont know. -
zrcheng Member Posts: 44 ■■□□□□□□□□Yes, it is interesting. thats the IBGP case study.
but the difference is : i config the R3 as non-client, but the book config R3 as client.
I just want to check the article's theory.
================================
# run show route protocol bgp logical-router r4 hidden detail
inet.0: 34 destinations, 35 routes (33 active, 0 holddown, 2 hidden)
192.168.10.0/24 (2 entries, 1 announced)
BGP
Next-hop reference count: 4
Source: 10.0.3.3
Next hop: 10.0.4.18 via fe-1/3/1.114, selected
Protocol next hop: 10.0.6.1
Indirect next hop: 85cc100 262146
State: <Hidden Int Ext>
Inactive reason: Unusable path
Local AS: 65412 Peer AS: 65412
Age: 1:45:38 Metric2: 10
Task: BGP_65412.10.0.3.3+179
AS path: I (Originator) Cluster list: 1.1.1.1
AS path: Originator ID: 10.0.6.1
Router ID: 10.0.3.3
192.168.20.0/24 (1 entry, 0 announced)
BGP
Next-hop reference count: 1
Source: 10.0.3.3
Next hop: 10.0.4.10 via fe-1/3/1.124, selected
Protocol next hop: 10.0.6.2
Indirect next hop: 85cc300 262158
State: <Hidden Int Ext>
Local AS: 65412 Peer AS: 65412
Age: 1:45:38 Metric2: 10
Task: BGP_65412.10.0.3.3+179
AS path: I (Originator) Cluster list: 1.1.1.1
AS path: Originator ID: 10.0.6.2
Router ID: 10.0.3.3
here, 192.168.10.0 is generated on R1 and 192.168.20.0 is generated on R2 by static route. -
rossonieri#1 Member Posts: 799 ■■■□□□□□□□well, from what i've saw - those 2 hidden routes is a correct behavior on junos. i could guess that will happen also on R3 - and this thing was what i've learned previously to troubleshoot the MPLS section.
the solution is you have to resolv this : "Inactive reason: Unusable path" issue.
so, you have the routes advertisement actually from R3 to R4.
HTH.the More I know, that is more and More I dont know. -
zrcheng Member Posts: 44 ■■□□□□□□□□make R3 and R4 cluster-id different will solve the inactive route, so what do you think? : )
-
rossonieri#1 Member Posts: 799 ■■■□□□□□□□hi cheng
i'm sorry for this late reply
well, your hidden route problem - it took me five days to make it work
then i supposed you can give me your best shotmake R3 and R4 cluster-id different will solve the inactive route, so what do you think? : )
i've told you previously - that, actually that R4 already received the route from R3 since R3 is not an RR client, but you have some hidden route instead. under junos? thats what i've got to learn to understandthe solution is you have to resolv this : "Inactive reason: Unusable path" issue.
a very simple but huge clue from me for you to work it out is to fix "route redistribution policy".
so, how long will you work it out?
just kidding my friend - smile upthe More I know, that is more and More I dont know.