[c-nsp] ME3600 BFD session to A9K breaks after upgrade to 15.3(3)S1a

Fri Nov 15 04:05:27 EST 2013

Hi Folks

That is right even with padding disabled the several first hellos (i.e.
until adj-comes up) are padded to full interface MTU -3. 

Though with A9K and ME3600 the use of CLNS MTU is a bit funky. 

I'm glad to hear that the ancient bug is finally fixed in .S1a and the CLAN
MTU is computed correctly but they still missed that one byte offset I was
pointing out as well :). 

c3600x.test#sh clns int po1 
Port-channel1 is up, line protocol is up
  Checksums enabled, MTU 9195, Encapsulation SAP

Opposite site receives:
RP/0/RSP0/CPU0:Nov 15 16:33:50.644 : isis[1003]: RECV P2P IIH (L1) from
Bundle-Ether2 SNPA 203a.07c3.a642: System ID c3600x.test, Holdtime 30,
length 9194

As far as the acceptable CLNS MTU differences between A9K and ME3600:

A9K can accept CLNS hellos that are max 5 bytes larger than the interface
CLNS MTU. 
ME3600 can accept CLNS hellos that are max 8 bytes larger than the interface
CLNS MTU. 

adam
-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
Jason Lixfeld
Sent: Friday, November 15, 2013 1:08 AM
To: Pshem Kowalczyk
Cc: cisco-nsp at puck.nether.net NSP
Subject: Re: [c-nsp] ME3600 BFD session to A9K breaks after upgrade to
15.3(3)S1a

Docs seem to indicate that it's still enabled by default, padded all the way
up to the full MTU size.

On Nov 14, 2013, at 6:51 PM, Pshem Kowalczyk <pshem.k at gmail.com> wrote:

> I can't check right now but what are the defaults for ISIS hello 
> padding on ME3600x?
> 
> kind regards
> Pshem
> 
> On 15 November 2013 06:39, Jason Lixfeld <jason at lixfeld.ca> wrote:
>> Hi all,
>> 
>> I got an answer on this and thought I'd share.  It bit me in the ass and
I'd hate for it to bite anyone else.
>> 
>> The root cause was due to a fix implemented in 15.3(3)S1a for CSCtl54835.
Essentially, the CLNS mtu is now properly calculated from the L3 interface
MTU whereas before, the CLNS MTU was always 1497 no matter what the L3
interface MTU was set to.  This fix was not listed in the list of resolved
caveats for that release, but it is now.
>> 
>> So,
>> 
>> After the upgrade, the CLNS MTU was calculated to be 9213 (based on a L3
interface MTU of 9216) which caused an incompatibility with it's adjacent 9K
which has a CLNS MTU of 9202 (based on a L3 interface MTU of 9216).
>> 
>> The fix was to lower the L3 MTU on the ME3600 to 9202 (which is the
correct MTU anyway when the A9K MTU is 9216).  This lowered the ME3600 CLNS
MTU to 9199 at which point ISIS/BFD was again operational.
>> 
>> I haven't read the CLNS or ISIS RFC, so I don't understand what the
expected behaviour is terms of CLNS MTU, but my findings are as follows:
>> 
>> Pre-15.3(3)S1a upgrade:
>> ME3600 interface MTU: 9216
>> ME3600 inherited CLNS MTU: 1497
>> ASR9K interface MTU: 9216
>> ASR9K inherited CLNS MTU: 9202
>> 
>> ME3600 CLNS MTU < ASR9K CLNS MTU
>> 
>> Result: ISIS/BFD Up
>> --
>> Post-15.3(3)S1a upgrade (no config change):
>> 
>> ME3600 interface MTU: 9216
>> ME3600 inherited CLNS MTU: 9213
>> ASR9K interface MTU: 9216
>> ASR9K inherited CLNS MTU: 9202
>> 
>> ME3600 CLNS MTU > ASR9K CLNS MTU
>> 
>> Result: ISIS/BFD Down
>> --
>> Post-15.3(3)S1a upgrade (config changed):
>> 
>> ME3600 interface MTU: 9202
>> ME3600 inherited CLNS MTU: 9199
>> ASR9K interface MTU: 9216
>> ASR9K inherited CLNS MTU: 9202
>> 
>> ME3600 CLNS MTU < ASR9K CLNS MTU
>> 
>> Result: ISIS/BFD Up
>> 
>> I have heard that it is the understanding of other people (who have
presumably read the RFC) that this configuration should still not work
because the CLNS MTU always needs to match on both ends.  So it seems that
there might be another issue afoot here?  To me, it seems that the A9K
cannot negotiate an ISIS adjacency when a neighbour CLNS MTU is larger than
itself, but the ME3600 can, but if the CLNS MTU is supposed to match always,
then both devices are actually misbehaving?
>> 
>> On Nov 12, 2013, at 9:57 AM, Jason Lixfeld <jason at lixfeld.ca> wrote:
>> 
>>> Before an upgrade to 15.3(3)S1a, a BFD session between a 9K and an
ME3600 worked just fine.  After the upgrade, BFD session wouldn't come up.
I looked at the release notes and couldn't see any notes about behaviour
changes in BFD or any specific caveats.  BFD still works fine if the
adjacent device is another ME3600 (only tested adjacent ME3600s that were
*not* upgraded to 15.3(3)S1a).
>>> 
>>> I've got Cisco looking at it, but I'm just curious if anyone else has
seen this change in behaviour.  Previously, this ME3600 was running 15.3(3)S
and it worked just fine to this same 9K (which is running XR 4.3.1).
>>> 
>>> ! A9K
>>> !
>>> router isis
>>> is-type level-2-only
>>> net 00.0720.1504.8009.0000.00
>>> nsf cisco
>>> log adjacency changes
>>> log pdu drops
>>> address-family ipv4 unicast
>>> metric-style transition
>>> !
>>> interface TenGigE0/0/0/6
>>> bfd minimum-interval 300
>>> bfd multiplier 3
>>> bfd fast-detect ipv4
>>> link-down fast-detect
>>> address-family ipv4 unicast
>>> !
>>> 
>>> ! ME3600
>>> !
>>> interface TenGigabitEthernet0/1
>>> no switchport
>>> dampening
>>> mtu 9216
>>> ip address 72.15.51.45 255.255.255.254 ip router isis 21949 logging 
>>> event link-status carrier-delay msec 0 mpls ip bfd interval 300 
>>> min_rx 300 multiplier 3 isis bfd !
>>> router isis 21949
>>> net 00.0720.1505.0138.0000.00
>>> is-type level-2-only
>>> metric-style transition
>>> spf-interval 5 1 50
>>> prc-interval 5 1 50
>>> lsp-gen-interval 5 1 50
>>> bfd all-interfaces
>>> !
>>> 
>>> Thanks in advance.
>> 
>> 
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/