Ok well talking this through in the thread here got me looking more closely at the routing tables. Netsight VM traffic was exiting our 2nd core switch (all vm’s are mlag’d between 2 cores). Some VM’s go out one core, some the other.
The second core had that transport network advertised in its OSFP configuration and an IP interface on it, however that WAN is not connected. We were going to earmark a port on it to go “swing the cable” in the event something happened to our primary core switch, however we don’t have any ports for that right now and we have a different, alternative backup path should we need to reach those locations out core 2.
So the 192.168.100.x/24 transport network that 3 remote sites were on, were not making it through to the second core switch. I mean you could ping and trace PAST that network, but the EXOS switch INSISTED (as Stefan K. shows some examples) to use the interface in that 192.168.100.x network. So to end users and servers, traditionally they noticed no issue. They live and work in different IP networks that are all in the routing table.
So I removed that VLAN from core 2’s OSPF configuration and now it traverses an OSPF link we have between both cores and out that WAN provider that is physically connected into our core 1 switch stack.
(Our core switch stacks are X690’s, our access stacks are X450G2’s or 5520’s depending on location).
So in actuality this was a routing issue and now I was able to retrieve configurations successfully.
Thanks for talking me through it. Sometimes you don’t notice the mundane details until you start typing it out and having a casual conversation.
