I tried this out in my home lab network. We’re having issues with it at work due to it does not really support vrf. But, that aside, I wanted to play with it somewhat, as it looks kind of fun.
It works okay in my lab, but the return path for some reason shows it going to my firewall. That is definitely not the case. I have an esx vm running Windows XP on a standard vswitch connecting to a CSR1000v router that connects to my “core” subnet on a Catalyst 3650. Then there is a 2821 router connected via a routed port on the 3650. Then there is a Meraki access point connected to a downstream 3560 connected to the 2821. That is sort of how I do a “virtual lab” area and a physical lab area. I have a bunch of CSR1000v running on esxi vswitches with no physical adapter associated except for the vswitch that connects to my “core” network. That way I can have large ospf topologies running with limited resources needed.
Anyway…the xp vm can ping and load the web admin page for the Meraki access point fine. But the return route shows it go to my firewall, rather than the ospf area 3 router, and then the vm. That seems wrong to me. Why would it do that? The core switch has a route, obviously, to the router the xp vm is connected to. This makes no sense.
I tried inserting a screen shot of the return path, but I don’t think it worked very well. Maybe it’s my browser, but the image insertion interface could use some TLC 🙂
Finally got a screen shot up there. The interface didn’t specify what kind of location for image. I wasn’t sure if it wanted a local path, or a cloud provider.
So, you can see that near the end of the return path, it veers off to my firewall instead of returning back to the router and vm.
Why would it do that?
Here is the route table from the core switch. The source device used in the next-hop tool is 10.3.3.100, and the firewall is 192.168.0.2
S* 0.0.0.0/0 [1/0] via 192.168.0.2
10.0.0.0/24 is subnetted, 4 subnets
O IA 10.1.1.0 [110/2] via 192.168.0.31, 5d20h, Vlan10
O IA 10.2.2.0 [110/2] via 192.168.0.32, 5d20h, Vlan10
O IA 10.3.3.0 [110/2] via 192.168.0.33, 5d20h, Vlan10
O IA 10.212.212.0 [110/2] via 172.16.254.2, 6d22h, GigabitEthernet0/8
172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks
S 172.16.210.0/24 [1/0] via 192.168.0.2
C 172.16.254.0/30 is directly connected, GigabitEthernet0/8
L 172.16.254.1/32 is directly connected, GigabitEthernet0/8
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, Vlan10
L 192.168.0.3/32 is directly connected, Vlan10
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, Vlan20
L 192.168.2.1/32 is directly connected, Vlan20
192.168.22.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.22.0/24 is directly connected, Vlan22
L 192.168.22.1/32 is directly connected, Vlan22
I looked at it briefly, its a bit hard to see the screen shot, need to improve image upload. It might be an issue with the return path and should take the same forward path, since this is pretty straight forward case. If possible, can you try to flip the src/dst of the route and see ifs correct in that direction, if so, its probably issue in our return path algorithm.
Feel free to send me the image directly to my email if easier firstname.lastname@example.org
Been looking at this offline with dmaker and looks like the algorithm gets confused when there is a default route and a more specific route that both use the same VLAN as egress interface. So using the address as src works because there is a specific route entry for destination but on using the address as dst, I think the algorithm gets confused and we have to look at that in more detail.