Set up as per the the following:
CPE --> LNS --> Core --> Upstream ISP ---- Datacentre 1
CPE --> LNS --> Core --> Upstream ISP ---- Datacentre 2
With the X-Connects in place between the two datacentres, everything is fully operational as expected. However, for DR testing, one of the critical tests is the pulling of the X-Connects to ensure both data centres can continue functioning separately in a seamless fashion.
CPE test address on Datcentre 1: 192.168.10.10
I have aggregated and advertised 192.168.10.0/24 to the upstream ISP. I pull the X-Connects to simulate complete link failure. I try to traceroute and ping the 192.168.10.10 device and get nothing.
Here is the strange part:
If I change the default route on the Core to point to the LNS rather than the other Core, it works. But the default is required for failover if we lose the upstream ISP.
So, the route for 192.168.10.10 exists in ISIS pointing to the correct egress interface. The LNS has the correct route in ISIS for 192.168.10.10.
The default route of 0.0.0.0/0 next-hop <other Core> is correct. If I point it to the other Core it does not work with no X-Connects, if I point it to the LNS, it works..... But then we would have no failover if we lose upstream ISP.
Question: If 192.168.10.10 exists in ISIS on the Core and on the LNS, pointing to the correct interfaces, why is the forwarding-table choosing the default route (it appears)? It should prefer the CORRECT ISIS route.....
I am not sure I follow your test scenario.
I assume the x-connect is between the two core devices. And this is removed.
When removed core at DC1 no longer sees the downstream routes the LNS1
The main question is what does the route table on the core affected look like before and after the loss of the x-connect.
In other words what routes are learned by this x-connect and what backup non-active routes are there for when the active primary routes are lost.
Apologies for the late response. Only just finished and first chance to update.
I resolved the issue. Because the VPN and also the subscribers were not working with disconnected X-Connects it made the whole scenario look like the problem was on the core. It was actually on the LNS.
Whne the X-Connects were disconnected, there were no routes on the LNS to external sites, but when the X-Connects were connected there were routes, but these routes were learned through ISIS. This meant that something on the opposing site was injecting the routes into ISIS. I found where this was, on a policy that I thought was no longer used. I removed this injection and on each LNS I placed a default pointing to the Core. This resolved the subscriber issue but there is still an outstanding problem with the VPN, but I can investigate that in the office.
From a DR perspective, everything else worked as expected.