IS-IS Routing issue

[CliveG]

Hi

I have taken over a rather old network that has two DCs that require failover that has never been configured. Best explanation is as follows:

DC1 -- x-connect -- DC2

DC2 has connectivity upstream to a BGP Collector and that is working fine : BGP state is established.

The switches in question for this are Cisco 6880 in a VSS pair.

The problem is that DC1 should be a DR failover site and it has never been configured as such.

I have 2 x new tengig connections installed upstream in a port-channel. This connects directly to the same BGP Collector as DC2 (this is the start of the redundancy requirement). However, here is where the problem starts:

If I ping the collector with a source of the port-channel in DC1 it responds fine, however, when pinging with the channel being the source I get failure. I know the reason for this and the question is coming but I need to explain the setup.

The problem is that the IGP is IS-IS and the /22 Supernet that the BGP collector address is part of, is being received at DC1 across the x-connect from DC2. So naturally, what BGP is trying to do is send it's open packets via DC2 and this will not work.

How can I separate this and not affect DC2 routing to the same addressed collector?

As an add on, this network is a 24/7/365 network and there is no possible chance of a maintenance window and no test network either. The upstream link to the collector from DC2 is vital and must not be dropped.

Any help would be greatly appreciated.

[Georg Pauwen]

Hello,

post a diagram showing the entire topology, that makes it easier to visualize what your network looks like.

[Giuseppe Larosa]

Hello @CliveG ,

BGP collector || <======== new port channel =========> ||   DC1 ( DR site)

and

BGP collector || <======== old port channel  working link =========> ||   DC2 ( primary site)

and

DC1  < ===== xconnect =========== DC2

question 1:

>> The switches in question for this are Cisco 6880 in a VSS pair.

A single pair or the switches are four and they form two VSS pairs?

Do you mean that the xconnect links are used to build the VSS and that DC1 and DC2 are the two chassis of the VSS pair ?

if so the new links should be added to the current upstream port-channel as VSS supports multi chassis ether-channel. But this has some impact .

The error was done in the moment that it was decided to connect only the primary link.

You would like to have a primary path via DC2 chassis and a secondary path via DC1 chassis and you are trying to use two indipendent L3 port-channels.

In a VSS a single supervisor is the master of both chassis. The VSS pair is a good choice to provide redundancy and to avoid STP issues.

if DC1 and DC2 are single switches members of a single VSS pair all you need to do is to add the new links to the existing port-channel however, doing so you would get load balancing and not redundancy.

Using LACP you can define the new members as standby hot link members.

If you have a single VSS pair there is no routing issue, it is the way the VSS works that make the primary DC2 likely to host the master supervisor.

Hope to help

Giuseppe

[CliveG]

Hi Giuseppe,

This is not 2 x switches in a VSS pair over the two DC's. If that was the case then this would be quite simple to rectify.

2 x 6880 VSS in DC1

2 x 6880 VSS in DC2

As mentioned, I have inherited a very poorly planned network that cannot be shutdown anywhere. I have found some other pointers with regards to the actual issue.

IS-IS is utilised throughout the whole network (DC3 - also 2 x 6880 VSS Connected to DC1 and DC2). There is no failover anywhere. For example:

Network 1 is connected to DC1 - When tracing a route from my laptop, the packets go to DC3 then DC2 then DC1. This should not be happening. It should go directly from DC3 to DC1 via the direct connection and then to Network 1.

So, routing at DC3 is not right.

What makes this worse is that everywhere the connected routes are being redistributed into IS-IS (advertised) so I cannot even utilise a staic route workaround. The reason, this will give you a chuckle:

1: Routing protocols prefer a longer prefix - /22 at DC2 and /21 at DC1 - So, it is taking the wring route to get to the collector.

2: Admin distance - Connected redistributed into IS-IS - Admin distance 0 - Static route 1

3: I cannot remove the x-connect because, as I mentioned, of incorrect routing at DC3 (going via DC2 and across the x-connect).

What an absolute nightmare. I want to tear this down and rebuild it correctly from scratch but I cannot. I have to deal with what is there.

I will create a diagram and add to this.

[CliveG · Accepted solution]

I will actually close this topic. Having spoken to a Cisco Senior Engineer this problem is resolvable but not in an environment where the changing of routing could result in the drop of the only upstream link currently available.

Process is for me to source and purchase 6 x C6880-X switches and replicate the environment.

These switches are not supported on GNS3 or eve-ng.

Thank you for your time. Very much appreciated.