Is IS-IS supported in LACP SVI?

[Maria Schiaffino]

Hi there,
we have some SVI configured in a LACP Channel from one Cisco 6500 towards two different Juniper devices and running IS-IS.
There was a maintenance window and one Juniper switch went down for some time. At that moment only one of our link in the PO went down but the IS-IS adjacencies had an outage and only came back when the link went up.
Could this be a bug on our side?
Please refer to the configuration below.
Thanks in advance for your help!

ROUTER-6500#

interface Port-channel10
description Nordic BackBone Link to IPONLY
mtu 9000
no ip address
load-interval 30
end
!
interface Port-channel10.2088
description IS-IS SVI 1
encapsulation dot1Q 2088
ip address 1.1.1.1 255.255.255.254
no ip redirects
no ip proxy-arp
ip flow ingress
ip router isis
clns mtu 8982
isis circuit-type level-2-only
isis network point-to-point
isis metric 50
isis csnp-interval 10
end

!
interface Port-channel10.2090
description IS-IS SVI 2
encapsulation dot1Q 2090
ip address 2.2.2.2 255.255.255.254
no ip redirects
no ip proxy-arp
ip flow ingress
ip router isis
isis circuit-type level-2-only
isis network point-to-point
isis metric 50
isis csnp-interval 10
end

!
interface GigabitEthernet3/1
description JUNIPER-A
mtu 9000
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
logging event link-status
load-interval 30
channel-group 10 mode active
end

interface GigabitEthernet3/4
description JUNIPER-B
mtu 9000
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
logging event link-status
load-interval 30
channel-group 10 mode active
end

Jun 1 09:55:43 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/1, changed state to down
Jun 1 09:55:43 CEST: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet3/1, changed state to down
Jun 1 11:12:48 CEST: %LINK-5-CHANGED: Interface GigabitEthernet3/1, changed state to administratively down
Jun 1 11:12:48 CEST: %LINK-SP-5-CHANGED: Interface GigabitEthernet3/1, changed state to administratively down
Jun 1 11:12:50 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet3/1, changed state to down
Jun 1 11:12:51 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet3/1, changed state to up
Jun 1 11:12:50 CEST: %LINK-SP-3-UPDOWN: Interface GigabitEthernet3/1, changed state to down
Jun 1 11:12:51 CEST: %LINK-SP-3-UPDOWN: Interface GigabitEthernet3/1, changed state to up
Jun 1 11:12:53 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/1, changed state to up
Jun 1 11:12:53 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/1, changed state to down
Jun 1 11:12:53 CEST: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet3/1, changed state to up
Jun 1 11:12:53 CEST: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet3/1, changed state to down
Jun 1 12:54:57 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/1, changed state to up
Jun 1 12:54:57 CEST: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet3/1, changed state to up

ROUTER-6500#sh isis lsp-log

Level 2 LSP log
When Count Interface Triggers
2d07h 1 Port-channel10.2090 DELADJ
2d07h 1 Port-channel10.2088 DELADJ
2d07h 1 Port-channel10.2088 NEWADJ
2d07h 1 Port-channel10.2090 NEWADJ

[Maria Schiaffino]

Hi, to clarify the device with the above config is a cisco WS-C6504-E with Version 12.2(33)SXJ7.  The Juniper boxes only provide Layer 2 connectivity towards other Cisco routers which are the ones with the IS-IS neighbors.

Thanks for your help in giving some light to this issue.

Regards,

[Giuseppe Larosa]

Hello @Maria Schiaffino ,

well first of all, you have L3 subinterfaces in a port-channel and not SVIs.

You have an LACP port-channel going from the Cat6504E  to two different OSI  L2 Juniper switches that are clearly configured to act as a single entity ( virtual-chassis in Juniper terms and multi chassis LAG).

The LACP timers can be too slow to detect the link failure so an IS-IS adjacency flapping can be expected.

But in your first post you say that IS-IS adjacencies were restored only when the affected link was restored

>> but the IS-IS adjacencies had an outage and only came back when the link went up.

In your second post you add :

>> The Juniper boxes only provide Layer 2 connectivity towards other Cisco routers which are the ones with the IS-IS neighbors.

As noted the two Juniper boxes are not indipendent devices they form a virtual-chassis and as in any similar technology there is a master or active element and a standby element ( elected at supervisor / routing engine level). As in similar technologies like Cisco VSS, SVL to avoid a case of active / active or split brain ( more Juniper term) the standby device will promote itself to an active role only if it is able to determine that the master device is down.

So the suggestion is to try to understand if device juniper A went down or not during the maintenance and if there are between Juniper A and Juniper B links that allow them to detect each other status.

Hope to help

Giuseppe

[Maria Schiaffino]

Hi Giuseppe, thanks for your reply.

You are absolutely right about the SVI, it is actually a Layer 3 subinterface.. sorry for the lapsus..

About your suggestion in checking the Juniper´s configuration, it is one of the things I was focusing on but as it is a third provider it´s difficult to get info.  So, I wanted to discard any issues in our own environment.

I was not able to find any supporting documentation stating that LACP and IS-IS don´t work well together in a Catalyst but I was afraid there could be a bug or incompatible thing going on with Juniper as well.

The logs don´t show anything about IS-IS adjacencies or time stamps in the output of the show isis lsp-log, so when I say that the adjacency came up when the Juniper link went up, I am relaying on the outage the customer told us (almost 2 hours) and I am forced to investigate.

Thanks again for your reply!

[Giuseppe Larosa · Accepted solution]

Hello @Maria Schiaffino ,

>> I was not able to find any supporting documentation stating that LACP and IS-IS don´t work well together in a Catalyst

Actually in theory there should be not be any issue between using LACP for  managing the bundle and IS-IS as a routing protocol . IS-IS L2 hellos are sent as L2 multicast and not being an IP packet makes the IS-IS hello to be treated as an ethernet frame load balancing based on MAC addresses  ( Source MAC EXOR Destination MAC should be in your case).

>> About your suggestion in checking the Juniper´s configuration, it is one of the things I was focusing on but as it is a third provider it´s difficult to get info.

I understand your point of view.

However, if for any reason the "standby" Juniper B box did not promote itself to active it probably didn't pass user traffic.

Hope to help

Giuseppe

[Maria Schiaffino]

Thank you very much for your help.

I will try to find out more information from the Juniper´s team.

Regards,

[Maria Schiaffino]

Thank you very much for your help.

I will try to find out more information from the Juniper´s team.

Regards,