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 <[email protected]> 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 <[email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
