New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Traceroute in batfish says no route but traceroute from the router works fine #8981
Comments
If you are using VRRP, you need to be supplying L1 topology. Are you doing that? You may wish to run the |
Same for the switch -- definitely need to supply L1 topology anytime L2 concepts are used! |
Looking a bit deeper -- Batfish disables management interfaces by default as the management network usually gets in the way of analysis. I saw that you had that on the switch. |
but management interface is not used for any routing. Also I am specifying to use Lo0 in trace. |
ospf is only for loopback distribution within the AS but outside the as everything is advertised using ebgp. i see the routes being advertised to R1 from R4. Routing looks all fine on the virtual switches itself.
|
Can you add |
Also, note that I added ``` around your message so that it rendered correctly, not as markdown :) |
|
R4 and R1 |
|
This is very surprising. Can you attach |
Sorry for not being explicit, but can you please include the |
Sorry. attached it as a file. |
So I'll tell you why I'm confused:
To me, that says that But your R1 show data says it is. Can you explain the difference? |
havent looked at the bgp advertise inactive. However the routing looks fine because OSPF is only used as IGP and then since R1 and R4 are ebgp neighbors the routes learned by R4 are advertised to R1. in the above comment at no.2 you mean learned from R6 right because R4 learns iBGP route for 2.2.2.3/32 from R6.
In fact we have this configuration everywhere in production with default no bgp advertise-inactive. I have tried to run batfish on prod devices configuration and it just runs fine. I see the expected results. |
Yes, I updated my prior comment to say R6. |
Can you add |
Here you go |
I can't understand why |
it is installed in RIB using OSPF right. sh ip route does show that. its a loopback0 ip address of R6. |
Right. So here's the EOS documentation I'm referencing (which confirms what's in my head): https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp
Note the text I bolded: If a preferred route is available through another protocol (like OSPF), the BGP route will become inactive and not be advertised |
right but I think this only applies to iBGP which makes sense because admin distance of ibgp is 200 and ospf is 110. here it is ebgp (admin distance 20) between R1 <> R4. Thats the reason RIB is learning route via OSPF and then it advertises it to its ebgp neighbor which is expected behaviour in this kind of topology. |
But we're talking about whether R4 advertises it, not whether R1 does -- right? So on R4 110 < 200 which is why OSPF is in the R4's main rib. |
but that is fine. R4 advertises that to R1 which is eBGP not its ibgp neighbors. that whole R4, R5, R6 will learn it via ospf. |
On R4, this should be true:
So it should not advertise the route to R1. As far as I can tell, this is not specific to IBGP routes or EBGP routes, or the remote-as of the neighbor |
hmmmm AFAIK this is the standard design. and the fact that on the actual switch it shows the same. All trace / pings work as expected from the switch. If you want to advertise 2.2.2.3/32 outside the bgp domain, EBGP is the option to go. Thats what is happening here. all loopbacks are learned via ospf within the ospf domain and then using ebgp those loopbacks will be advertised to the ebgp neighbors. same happens from R5 > R2 as well. Take a look below
|
Describe the bug and expected behavior
A clear and concise description of what the bug is and what you expect to happen instead.
In the above topology I am trying to trace from R1's lo0 to R6 lo0. When i login to the R1 directly and run traceroute using source lo0 I see the trace fine but batfish shows no route
R1(config-router-bgp)#traceroute 2.2.2.3 source lo0
traceroute to 2.2.2.3 (2.2.2.3), 30 hops max, 60 byte packets
1 192.168.1.2 (192.168.1.2) 0.088 ms 0.020 ms 0.017 ms
2 2.2.2.3 (2.2.2.3) 1.515 ms 1.922 ms 2.299 ms
Runnable example
Additional context
Add any other context about the problem here.
R1-config.txt
R2-config.txt
R3-config.txt
R4-config.txt
R5-config.txt
R6-config.txt
SW1-config.txt
The text was updated successfully, but these errors were encountered: