cancel
Showing results for 
Search instead for 
Did you mean: 

OSPF learnt route difference with VOSS.

OSPF learnt route difference with VOSS.

Anonymous
Not applicable

Hi

Hoping someone more clever then myself can help me workout why a route on the Palo Alto shown below (10.119.71.0) is add a route via the EXOS devices on the EOS switches as you would expect, but I am not seeing anything via the VSP.

I think its to do with the same routes via the VSP being seen as type 3 LSA’s?

bc9d9940e9ea4f32b304e863e7d85c4b_a82dcaa5-4e41-4dec-b188-2272f0e28df0.png

 

In essence I am migrating the the L3 links on the firewalls from EXOS to the VSP’s. The whole Data Centre is run North of the firewall. So I want to be careful about moving the L3 links across so not to cause any disruption.

I don’t think there is anything necessarily wrong, as the VSP learned routes will I believe kick in when fully migrated across, but what to fully understand what I am seeing to be sure it is safe.

Many thanks in advance.

Martin

1 ACCEPTED SOLUTION

Anonymous
Not applicable

On close examination the Palo Alto is using a cost of 10, EXOS is using 14 and VOSS is using 20. So have come to an conclusion the EOS switch is installing the route via EXOS with a preference of 24 rather then 30 via VOSS.

What I expected to see in the EOS routing table (subject to not having a command like show alternative), was the additional route shown via VOSS under the EXOS route, but showing the higher cost - think that’s how its done in EOS. This is what has effectively thrown me off as I have no way of validating it (that I know)

Anyway, the plan is to add some config on the EXOS links to increase the cost to see if the route via the VOSS switch is installed. The premise is that generally everything seems to be OK, adjacencies are all up, routes are being shared, so in theory it should work.

Once I’ve done it and got the results I will post back.

 

View solution in original post

7 REPLIES 7

Anonymous
Not applicable

Just updating this post based on the results. 

After removing the path via EXOS, the routes on EOS showed that via VOSS, so in the end was just related to cost.

The switch over from EXOS to VOSS worked seamlessly as the routes via VOSS kicked in on the EOS switch.

Anonymous
Not applicable

On close examination the Palo Alto is using a cost of 10, EXOS is using 14 and VOSS is using 20. So have come to an conclusion the EOS switch is installing the route via EXOS with a preference of 24 rather then 30 via VOSS.

What I expected to see in the EOS routing table (subject to not having a command like show alternative), was the additional route shown via VOSS under the EXOS route, but showing the higher cost - think that’s how its done in EOS. This is what has effectively thrown me off as I have no way of validating it (that I know)

Anyway, the plan is to add some config on the EXOS links to increase the cost to see if the route via the VOSS switch is installed. The premise is that generally everything seems to be OK, adjacencies are all up, routes are being shared, so in theory it should work.

Once I’ve done it and got the results I will post back.

 

Miguel-Angel_RO
Valued Contributor II

Martin,

It seems that the EOS is not sending the ip routes to the VOSS.

Can you check with “show ip route protocol ospf”?

Mig

Anonymous
Not applicable

Here you go….

Basically what you are seeing is the adjacency on VSP-Core1 & 2 back to the Palo Alto.

VSP-Core1 has an adjacency back to the EOS switch (172.20.250.217 - 2.2.2.2)

Noticed an error in my diagram. There is actually x4 VSP8400’s in this topology, but only added two to the diagram with one of the links to the EOS switches being incorrectly placed, but effectively it will be the same thing.

The other adjacencies are basically a /29 subnet (VLAN 3401) to all the x4 VSP’s mentioned..

One thing to note is that all the subnets north of the Palo are in area 0.0.0.255, but all the connections to all the switches are in area 0.0.0.0

VSP-Core1:1#% show ip ospf neighbor
************************************************************************************
Command Execution Time: Thu May 27 10:55:03 2021 GMT
************************************************************************************
====================================================================================================
OSPF Neighbors - GlobalRouter
====================================================================================================
INTERFACE NBRROUTERID NBRIPADDR PRIO STATE RTXQLEN PERM TTL
----------------------------------------------------------------------------------------------------
172.20.250.217 2.2.2.2 172.20.250.218 1 Full 0 Dyn 35
172.20.251.66 172.20.255.111 172.20.251.65 1 Full 0 Dyn 35
172.20.250.129 172.20.248.212 172.20.250.130 1 TwoWay 0 Dyn 31
172.20.250.129 172.20.248.221 172.20.250.131 1 Full 0 Dyn 35
172.20.250.129 172.20.248.222 172.20.250.132 1 Full 0 Dyn 33



VSP-Core2:1#% show ip ospf neighbor
************************************************************************************
Command Execution Time: Thu May 27 10:55:36 2021 GMT
************************************************************************************
====================================================================================================
OSPF Neighbors - GlobalRouter
====================================================================================================
INTERFACE NBRROUTERID NBRIPADDR PRIO STATE RTXQLEN PERM TTL
----------------------------------------------------------------------------------------------------
172.20.251.70 172.20.255.111 172.20.251.69 1 Full 0 Dyn 33
172.20.250.130 172.20.248.222 172.20.250.132 1 Full 0 Dyn 40
172.20.250.130 172.20.248.221 172.20.250.131 1 Full 0 Dyn 32
172.20.250.130 172.20.248.211 172.20.250.129 1 TwoWay 0 Dyn 31

Thanks

GTM-P2G8KFN