search

netenglabs / suzieq

Using network observability to operate and design healthier networks
https://www.stardustsystems.net/
Apache License 2.0
793 stars 106 forks source link

Path show ospf-ibgp shows spine01 and spine02 to exit01/exit02 have the same path when they shouldn't #340

Open jopietsch opened 3 years ago

jopietsch commented 3 years ago

Describe the bug This is tricky. ospf-ibgp, path show from 172.16.1.101 to 172.16.253.1 image

The issue is what is going on between spine01/spine02 and exit02/exit01. It looks like spine01/spine02 both don't have a routed connection to exit01, but I don't think that's correct. There is a missing bgp connection between spine02 and exit02, but there is a bgp connection between spine01 and exit02. In this picture they look like they are the same, but they shouldn't be. Also, if you click on the links between spine01 and spine02, you see a different answer.

spine01 -> exit02 image

spine02 -> exit02 image

If you look at the spine01 -> exit02, you'll see that there are two nexthopIPs and two oifs, but in the spine02 -> exit02 there is only one next hop. So these shouldn't look the same but they do.

jopietsch commented 3 years ago

also notice the debug from spine02 -> exit02. The first line says that oif is swp6, which would be spine01. the second line says that the arp/nd table points to swp5. why are there conflicting oifs and why does path show swp5 -> exit02?

ddutt commented 3 years ago

Unable to reproduce. I see only a connectivity to swp5 (exit02), not exit02 and exit01. Was this a bug during a transient state in the IOSXR branch?

jopietsch commented 3 years ago

This is in the data in tests/data/multidc. If you click on the links in the path (link between spine02 -> exit02) and not spine02 you will see it.

ddutt commented 3 years ago

swp5 is exit02, not exit01. You can verify that.