4/30/2019

Arista MLAG reload-delay timers

In this blog post, I will cover the following MLAG related topics:
  • What is the MLAG reload-delay and why it is needed
  • The difference of 2 different timers
  • How to tune the timer values
After an MLAG peer boot up, all its ports are placed in err-disabled state (except the peer-link) with a reason of "mlag-issu". During the reload-delay, the MLAG agents sync all MAC and ARP information with the active peer. 

Another trigger of mlag reload delay is forwarding plane agent restart. On some platforms like TH or T3, a port speed change needs a hitful agent restart, which forces mlag interfaces to transition and starts reload-delay.

From 4.15.2F, the default reload-delay timers are different per platform:
  • All fixed systems: 300 sec
  • 7500* (Arad/Jericho): 1800 sec (due to long hw initialization time)
  • 7300* (Trident*/TH): 1200 sec
When to start the reload timer? The timers start to tick after the start of MLAG agent. In old releases, it is triggered by the sysdb agent. 

Can I lower the reload-delay timers? Yes, but be careful since if the interfaces exit err-disabled mode before sync is done, the mlag peer will blackhole the traffic. 

Which value should be used, it is highly based on system and configuration. You can look at the log messages closely. 

! this is MLAG agent up and timers are on
Apr 19 11:33:32 localhost Mlag: %AGENT-6-INITIALIZED: Agent 'Mlag' initialized; pid=3030
! LCs power on
Apr 19 11:34:08 R1 NorCalCard: %HARDWARE-6-CARD_POWERED_ON: Card Fabric3 has been powered on. model: 7512R-FM rev: 11.02 serial number: JPE16305615
....
Apr 19 11:34:24 R1 NorCalCard: %HARDWARE-6-CARD_POWERED_ON: Card Linecard11 has been powered on. model: 7500R-36Q-LC rev: 02.01 serial number: JPE16204252
! LC initialization
Apr 19 11:38:40 R1 SandFap: %SAND-6-INIT_SUCCEEDED: Initialization of Linecard12 switch asics succeeded.
....
Apr 19 11:43:12 R1 SandFap: %SAND-6-INIT_SUCCEEDED: Initialization of Linecard13 switch asics succeeded.
! interfaces up
Apr 19 11:43:01 R1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet12/26/3 (mlag.207_leaf_et9/3_et10/3=>et12/17/3), changed state to up
....
Apr 19 11:46:33 R1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet14/34/1 (peerLink=>mlagSec.et14/34/1.100g), changed state to up

This is the messages of a 7512N with 8 J/J+ LCs. So you can see, 13 mins after MLAG agent up, the last peer-link interface is up. Given 5 mins to allow IGP/iBGP session and corresponding hw programming finished, a 20-min (1200 sec) reload-delay timer should be safe with an additional 2-minute buffer. 

And there are 2 timers:
  • MLAG reload-delay timer: this is for all MLAG port-channel links. It can be changed by CLI - "reload-delay mlag <seconds>"
  • Non-MLAG reload-delay timer: most of the time, they are the timeout values for L3 uplinks. And can be modified by CLI - "reload-delay non-mlag <seconds>"
Before discussing how to tune them, let me give a good example to help your understandings:
  • Imagine there is a house which has a front door (non-MLAG/uplinks to go out) and a back door (MLAG interfaces/to reach hosts/tenants)
  • And there is a side to your neighbor (MLAG peer), which shares the same tenants/hosts. 
  • So the first thing to do is to communicate with your neighbor to have all the address information, to know who is where. 
  • With all the knowledge, open which door first?
    • First of all, the side door is opened first. (so peer-link doesn't have reload-delay and a BGP/IGP peering is required)
    • During the gap of the front and back door, the traffic will not be lost since there is a side door to exit. 
    • The opening of the back door will have half south-north traffic in, and will go thru the side door. Similar to front door, half north-south traffic. 
    • Most of the time, the MLAG interfaces are facing servers which means south-north traffic is much higher than the opposite traffic. 
  • So it is preferable to configure non-mlag reload delay <= mlag timer. 
  • The ONLY exception is, if "reload-delay mode lacp-standby" is enabled, non-mlag timer > mlag timer. This feature keeps the LACP interfaces up to speed up hardware programming. So if the north-south coming first, the router has to drop them because the MLAG port-channels are not really ready. 

Arista EOS: sand hardware-only LAG

CLI: 
platform sand lag hardware-only

目的:
  • 一般情况下,1-port LAG是software LAG;
  • 如果增加一个port,变成2-port LAG,就会变成hardware LAG,会有traffic interruption,特别是interface flap! 
  • 什么意思啊?很简单,如果是2-port LAG,断了一根线,变成1-port/software LAG,有Traffic impact. 如果这根线在Flapping,traffic就一直受影响
  • 所以索性一上来就是hw-LAG
  • 唯一的影响是,占有的资源(啥资源啊?不知道,LAG table?)会多一些

Arista EOS Memory Util%

https://eos.arista.com/introduction-to-managing-eos-devices-memory-utilisation/

经常Arista Switch会显示Mem Util% at 70%,特别是低端的Switch。其实没有用到,而是Linux Caching System把他们Reserve到Cache和Buffer里面。下面红字的都是Free Mem

------------- show processes top memory once -------------

top - 01:14:08 up 21 days,  1:18,  1 user,  load average: 0.62, 0.39, 0.41
Tasks: 310 total,   1 running, 252 sleeping,   0 stopped,  57 zombie
%Cpu(s): 10.3 us,  2.0 sy,  0.0 ni, 87.3 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st
KiB Mem:   3900776 total,  3730136 used,   170640 free,   201908 buffers
KiB Swap:        0 total,        0 used,        0 free,  2034600 cached

ckp348.jhm.ebgp.profB.WORKING.05:46:31#sh proc top mem once
top - 05:46:40 up 25 days,  7:21,  2 users,  load average: 0.42, 0.25, 0.24
Tasks: 289 total,   2 running, 287 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4.4 us,  0.7 sy,  0.0 ni, 94.1 id,  0.0 wa,  0.2 hi,  0.5 si,  0.0 st
KiB Mem:   7931828 total,  4395336 used,  3536492 free,   218976 buffers
KiB Swap:        0 total,        0 used,        0 free,  2371220 cached

Arista optics with DOM support

DOM: 
  • Digital Optical Monitoring. 
  • Per industry standard - SFF-8742, and it gives end users the ability to monitor real-time parameters of SFP, such as in/output power, temperature, laser current and supply voltage
  • 2 Arista optical parts don't support full DOM:
    • 40G AOC doesn't support Tx Power
    • 10G AOC doesn't support DOM
  • EOS CLIs:
    • show int eth22/1 transceiver [detail]
  • https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html


upp106#show inv | grep SWDM

  22   Arista Networks  QSFP-100G-SWDM4  ATH173200003     20

upp106#show int eth 22/1 transceiver
If device is externally calibrated, only calibrated values are printed.
N/A: not applicable, Tx: transmit, Rx: receive.
mA: milliamperes, dBm: decibels (milliwatts).
                               Bias      Optical   Optical
          Temp       Voltage   Current   Tx Power  Rx Power
Port      (Celsius)  (Volts)   (mA)      (dBm)     (dBm)     Last Update
-----     ---------  --------  --------  --------  --------  -------------------
Et22/1     33.00      3.30      7.69     1.32      0.44      0:00:01 ago


upp106#show int eth 22/1 transceiver de
mA: milliamperes, dBm: decibels (milliwatts), NA or N/A: not applicable.
++ : high alarm, +  : high warning, -  : low warning, -- : low alarm.
A2D readouts (if they differ), are reported in parentheses.
The threshold values are calibrated.
                         High Alarm  High Warn   Low Alarm   Low Warn
           Temperature   Threshold   Threshold   Threshold   Threshold
Port       (Celsius)     (Celsius)   (Celsius)   (Celsius)   (Celsius)
-------    ------------  ----------  ----------  ----------  ----------
Et22/1     33.00         75.00       70.00       -5.00       0.00
                         High Alarm  High Warn   Low Alarm   Low Warn
           Voltage       Threshold   Threshold   Threshold   Threshold
Port       (Volts)       (Volts)     (Volts)     (Volts)     (Volts)
-------    ------------  ----------  ----------  ----------  ----------
Et22/1     3.30          3.60        3.47        2.97        3.10
                         High Alarm  High Warn   Low Alarm   Low Warn
           Current       Threshold   Threshold   Threshold   Threshold
Port       (mA)          (mA)        (mA)        (mA)        (mA)
-------    ------------  ----------  ----------  ----------  ----------
Et22/1     7.71          11.00       10.00       2.00        3.00
                         High Alarm  High Warn   Low Alarm   Low Warn
           Tx Power      Threshold   Threshold   Threshold   Threshold
Port       (dBm)         (dBm)       (dBm)       (dBm)       (dBm)
-------    ------------  ----------  ----------  ----------  ----------
Et22/1     1.33          6.00        5.00        -7.00       -6.00
                         High Alarm  High Warn   Low Alarm   Low Warn
           Rx Power      Threshold   Threshold   Threshold   Threshold
Port       (dBm)         (dBm)       (dBm)       (dBm)       (dBm)
-------    ------------  ----------  ----------  ----------  ----------
Et22/1     0.44          5.50        4.50        -16.00      -13.00

bn303.jhm.mlagA.profB.WORKING.17:56:54#sh int status  | grep 9/1/1
Et9/1/1        eth.mlag1601::2x25g::upp223_et1/1_et17/1<-->bn302|303_et9/1/1                 connected    in Po1601 full   25G    100GBASE-AR4

bn303.jhm.mlagA.profB.WORKING.17:56:39#sh int e9/1/1 transceiver
If device is externally calibrated, only calibrated values are printed.
N/A: not applicable, Tx: transmit, Rx: receive.
mA: milliamperes, dBm: decibels (milliwatts).
                               Bias      Optical   Optical
          Temp       Voltage   Current   Tx Power  Rx Power
Port      (Celsius)  (Volts)   (mA)      (dBm)     (dBm)     Last Update
-----     ---------  --------  --------  --------  --------  -------------------
Et9/1/1    31.11      3.23      7.08     0.36      -2.36     0:00:03 ago
bn303.jhm.mlagA.profB.WORKING.17:56:46#sh int e9/1/1 transceiver detail
mA: milliamperes, dBm: decibels (milliwatts), NA or N/A: not applicable.
++ : high alarm, +  : high warning, -  : low warning, -- : low alarm.
A2D readouts (if they differ), are reported in parentheses.
The threshold values are calibrated.
                         High Alarm  High Warn   Low Alarm   Low Warn
           Temperature   Threshold   Threshold   Threshold   Threshold
Port       (Celsius)     (Celsius)   (Celsius)   (Celsius)   (Celsius)
-------    ------------  ----------  ----------  ----------  ----------
Et9/1/1    31.53         80.00       75.00       -10.00      -5.00
                         High Alarm  High Warn   Low Alarm   Low Warn
           Voltage       Threshold   Threshold   Threshold   Threshold
Port       (Volts)       (Volts)     (Volts)     (Volts)     (Volts)
-------    ------------  ----------  ----------  ----------  ----------
Et9/1/1    3.23          3.63        3.46        2.97        3.14
                         High Alarm  High Warn   Low Alarm   Low Warn
           Current       Threshold   Threshold   Threshold   Threshold
Port       (mA)          (mA)        (mA)        (mA)        (mA)
-------    ------------  ----------  ----------  ----------  ----------
Et9/1/1    7.08          12.00       10.00       3.00        4.50
                         High Alarm  High Warn   Low Alarm   Low Warn
           Tx Power      Threshold   Threshold   Threshold   Threshold
Port       (dBm)         (dBm)       (dBm)       (dBm)       (dBm)
-------    ------------  ----------  ----------  ----------  ----------
Et9/1/1    0.36          5.40        2.40        -11.40      -8.40
                         High Alarm  High Warn   Low Alarm   Low Warn
           Rx Power      Threshold   Threshold   Threshold   Threshold
Port       (dBm)         (dBm)       (dBm)       (dBm)       (dBm)
-------    ------------  ----------  ----------  ----------  ----------
Et9/1/1    -2.39         5.40        2.40        -13.30      -10.30

Arista EOS ASU and ASU2

ASU = Accelerated Software Upgrade
  • EOS Docu
  • 就是在Control Plane booting的时候,Hardware继续Fwd Traffic based on old state
  • 等Control Plane is up and running, refresh hw. 所以Traffic disruption大概是30 seconds. 
  • CLI: reload fast-boot
  • 还有一个ASU+
ASU2
  • 没有Document ?
  • 就是加上Protocol GR,例如BGP, OSPF
  • Traffic disruption is about 50ms
  • CLI: reload hitless

Arista EOS PBR (1)

  • PBR = Policy Based Routing - 就是不走IP routing path,而是policy defined path
  • Arista EOS PBR configuration和Cisco有点不一样, Arista允许 Raw match
  • Cisco:
    • access-list 1 perm ip 1.1.1.0 0.0.0.255
    • route-map pbrRtmap perm 10
    • match ip address 1
    • set ip next-hop 2.2.2.2
    • Arista:
      • policy-map type pbr pbrPolicy
      • 10 match ip 1.1.1.0/24 any set nexthop recursive 2.2.2.2
      • Sand Platform实施有点特别:
        • 如果是routed/LAG上面配置, 只要一个set of TCAM,而且只在Faps that host this routed/LAG ports. 和Port ACL类似
        • 如果是VLAN/SVI上配置,每个SVI都有一个copy of TACM rules,而且是在所有Faps。
        • 所以routed/LAG scale更好
      • set nexthop recursive是为了ECMP
      • 如果no set = no action = bypass pbr and move to next stage. 
      • 如果不satisfy 如何match,就去routing
      • 如果NH不能Resolved, 直接drop
        • 知道via = vlan, eth and MAC
      • Configuration:
        • class-map type pbr match-any pbrClassMap
        • 10 match ip access pbrACL1
        • policy-map type pbr pbrPolicy
        • 10 class pbrClassMap
        • set next-hop ip-address <ip1> <ip2>....
        • interface e1
        • service-policy type pbr input pbrPolicy 
      • 如果policy-map applied to a Lag,但是Lag member port有policy-map,咋办?
        • member port's policy-map就作废了
      • ECMP support for PBR
        • set next-hop ip-addr nh1 nh2... nhN
        • N = max# of ECMP
        • No UCMP, 如果是同样的Via, 会被filter out
      • Reference:

      Arista 7160S-32CQ Error Msg: % Error: Cannot apply ip ACL test2 to Ethernet2/1 (Out of SW resources on Chip-0)

      Platform: Arista 7160S-32CQ, XP80, 32QSFP100
      2 large ip ACL with 1500 entries
      System is kind of strenched, and hitting limit with hash collision with mask-group
      IP Access List test2
              10 deny pim host 70.0.70.210 any
              20 deny ospf host 0.70.210.70 any
              30 deny pim host 140.140.70.210 any
              40 permit gre host 70.0.0.0 any
              50 permit ospf host 70.140.0.210 any
              60 deny icmp host 140.70.210.70 any
              70 permit igmp host 0.70.0.0 any
              80 permit vrrp host 0.0.0.210 any
              90 deny tcp host 70.70.210.70 any
              100 deny ospf host 0.210.210.140 any
              110 deny gre host 210.140.0.210 any
              120 deny ip host 0.0.210.210 any
              130 deny igmp host 140.70.140.70 any
              140 permit ip host 70.0.70.0 any

      dut23:44:51(config-if-Et2/1)#ip access-group test2 in
      % Error: Cannot apply ip ACL test2 to Ethernet2/1 (Out of SW resources on Chip-0)

      fu590.09:21:58#show platform algo chip 0 acl table usage
      Table ID Entries used
      -------- ------------
      0        7968
      1        5567
      2        6415
      3        0
      4        8010
      5        2520

      show platform algo chip 0 acl mask-group
      Initial revision
         Hw Acl ID 1
            Mask group ID Mask group descriptor                      Entries
            ------------- ------------------------------------------ -------
            2             ipv4PAcl,sip:8,dip:0,sport:0,dport:0       159
            1             ipv4PAcl,sip:8,dip:0,sport:0,dport:0,proto 1385
            3             ipv4PAcl,sip:9,dip:0,sport:0,dport:0,proto 19
      Final revision
         Hw Acl ID 1
            Mask group ID Mask group descriptor                      Entries
            ------------- ------------------------------------------ -------
            3             ipv4PAcl,sip:9,dip:0,sport:0,dport:0,proto 30480

      show platform algo chip 0 acl table la

      Final revision
         Hw Acl ID 1

            Table ID Mask group ID Mask group descriptor
            -------- ------------- ------------------------------------------
            0        3             ipv4PAcl,sip:9,dip:0,sport:0,dport:0,proto
            1        3             ipv4PAcl,sip:9,dip:0,sport:0,dport:0,proto
            2        3             ipv4PAcl,sip:9,dip:0,sport:0,dport:0,proto
            4        3             ipv4PAcl,sip:9,dip:0,sport:0,dport:0,proto
            5        3             ipv4PAcl,sip:9,dip:0,sport:0,dport:0,proto


      ECN: Explicit Congestion Notifcation, PFC

      • 在DC里面,特别是Storage Network/FCOE,对pkt drop很敏感,常用的是2种QOS
        • ECN
        • PFC
      • PFC - Prority Flow Control.
      • ECN - Explicit Congestion Notification,
        • 是DSCP后面的2 bit. 
        • 00 - Not supported
        • 01/10 - Supported
        • 11 - CE : congestion encountered
      • 如何Work:
        • Server pkt 通过 Router
        • Router发现有Egress congestion, 或者定义的min/max threshold, 开始set ECN to CE
        • Client收到CE pkt后,通过TCP adjust window to slow down traffic. 
      • 一般是定义在Egress interface,config在后面

      interface et3/1/1
       mtu 9000
       speed force 40gfull
       no switchport
       ip address 10.1.1.1/24
       qos trust dscp
       tx-queue 0
          random-detect ecn minimum-threshold xxxx bytes max yyyy bytes

      LACP rate fast vs MLAG

      Arista does NOT recommend LACP rate fast enabled with MLAG, which is not reliable especially in scale environment.

      In 4.20.2.1F Release Note, on page 21

      "LACP PDU fast rate ("lacp rate fast" on an Arista switch) should not be configured on any port in an MLAG pair, or any port connected to an MLAG pair. (13950)"

      4/29/2019

      How to see the open bug in Arista EOS

      Generally, you can see the list of the open bugs in the software release note. Another way is to go to arista.com, click Support in the menu bar, then select the "Software Bug Portal".

      Or if you know the specific bug id, you can get it like https://www.arista.com/en/support/software-bug-portal/bugdetail?bug_id=<bug_id>

      4/16/2019

      How to debug ISIS/BFD neighbor issue

      Topology:

      [R1/DCS-7512N]:et11/36/1--{180.13.1.0/24}--et11/1:[R2/DCS-7050QX]

      * both routers run 4.20.11M
      * Between R1 and R2, ISIS/BFD is enabled shown as below

      Router Configuration:

      R1 configuration:

      router isis isis.def
         net 49.0001.0000.0000.0001.00
         is-type level-1
         log-adjacency-changes
         redistribute connected
         spf-interval 1 50 100
         timers lsp generation 1 10 1000
         !
         address-family ipv4 unicast
            maximum-paths 32
         !
         address-family ipv6 unicast
            maximum-paths 32
      !
      interface Ethernet11/36/1
         description UpEt_A_3.1
         speed forced 10000full
         no switchport
         ip address 180.13.1.1/24
         ipv6 address 180:13:1::1/64
         isis enable isis.def
         isis bfd
         isis circuit-type level-1
         isis network point-to-point
         isis authentication mode md5 level-1
         isis authentication key 7 QI3r+/7nP3Q= level-1

      R2 configuration:
      router isis isis.def
         net 49.0001.0000.0000.0103.00
         is-type level-1
         log-adjacency-changes
         spf-interval 1 50 100
         timers lsp generation 1 10 1000
         !
         address-family ipv4 unicast
            maximum-paths 32
         !
         address-family ipv6 unicast
            maximum-paths 32
      !
      interface Ethernet11/1
         description UpEt_A_3.1
         speed forced 10000full
         no switchport
         ip address 180.13.1.100/24
         ipv6 address 180:13:1::100/64
         isis enable isis.def
         isis bfd
         isis circuit-type level-1
         isis network point-to-point
         isis authentication mode md5 level-1
         isis authentication key 7 QI3r+/7nP3Q= level-1

      Symptom:

      R1: No ISIS and BFD neighbor


      R1.13:53:14(config)#show isis nei | grep uspine3
      R1.13:53:16(config)#show bfd nei | grep 180.13
      R1.13:53:18(config)#

      R2: ISIS neighbor stuck in INIT, and BFD is down

      R2#sh isis nei
      Instance  VRF      System Id        Type Interface          SNPA              State Hold time   Circuit Id
      isis.def  default  R1               L1   Ethernet11/1       P2P               INIT  26          2D

      R2#sh bfd nei

      VRF name: default
      -----------------
      DstAddr                    MyDisc        YourDisc             Interface         Type               LastUp             LastDown                LastDiag    State
      -------------------- --------------- --------------- --------------------- ------------ -------------------- -------------------- ----------------------- -----
      180.13.1.1             2628313401               0      Ethernet11/1(47)       normal       04/15/19 13:25       04/15/19 13:26       Nbr Signaled Down     Down

      Step1: R1/R2 - "show lldp nei" good and ping works, so no connectivity issue but high latency


      -- show lldp nei --
      R2#sh lldp nei
      Port       Neighbor Device ID               Neighbor Port ID           TTL
      Et11/1     R2                               Ethernet11/36/1            120

      -- ping -- R2#ping 180.13.1.1
      PING 180.13.1.1 (180.13.1.1) 72(100) bytes of data.
      80 bytes from 180.13.1.1: icmp_seq=1 ttl=64 time=390 ms
      80 bytes from 180.13.1.1: icmp_seq=2 ttl=64 time=437 ms
      ....

      -- show interface <intf> | grep error --
      R1.13:46:01(config)#sh int et11/36/1 | grep error
           0 input errors, 0 CRC, 0 alignment, 0 symbol, 0 input discards

           0 output errors, 0 collisions

      R2.13:45:34(config)#sh int et11/1 | grep error
           0 input errors, 0 CRC, 0 alignment, 0 symbol, 0 input discards

           0 output errors, 0 collisions

      Step2: R2's Down BFD shows NO incoming bfd pkts

      -- show bfd neighbor dest-ip <ip> detail --
      R2#sh bfd neighbors dest-ip 180.13.1.1 detail
      VRF name: default
      -----------------
      Peer Addr 180.13.1.1, Intf Ethernet11/1, Type normal, State Down
      VRF default, LAddr 180.13.2.100, LD/RD 2628313401/0
      Session state is Down and not using echo function
      Last Up Apr 15 13:25:27 2019
      Last Down Apr 15 13:26:23 2019
      Last Diag: Nbr Signaled Down
      TxInt: 1000, RxInt: 1000, Multiplier: 3
      Received RxInt: 300, Received Multiplier: 3
      Rx Count: 0, Rx Interval (ms) min/max/avg: 0/0/0 last: never
      Tx Count: 87681, Tx Interval (ms) min/max/avg: 508/996/870 last: 627 ms ago
      Detect Time: 3000
      Sched Delay: 1*TxInt: 87898, 2*TxInt: 0, 3*TxInt: 0, GT 3*TxInt: 0

      R2 sends out BFD but no receiving

      -- bash tcpdump -ni <intf> udp --
      [admin@R2 ~]$ tcpdump -ni et11_1 udp
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on et11_1, link-type EN10MB (Ethernet), capture size 262144 bytes
      11:48:22.309536 28:99:3a:3b:15:39 > 44:4c:a8:a5:11:40, ethertype IPv4 (0x0800), length 66: 180.13.1.100.57657 > 180.13.1.1.bfd-control: BFDv1, Control, State Down, Flags: [none], length: 24


      11:48:23.301574 28:99:3a:3b:15:39 > 44:4c:a8:a5:11:40, ethertype IPv4 (0x0800), length 66: 180.13.1.100.57657 > 180.13.1.1.bfd-control: BFDv1, Control, State Down, Flags: [none], length: 24

      Same observation on R1, only receiving no sending

      R1.13:53:18(config)#bash tcpdump -ni et11_36_2 udp
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on et11_36_2, link-type EN10MB (Ethernet), capture size 262144 bytes
      13:55:10.568533 28:99:3a:3b:15:39 > 44:4c:a8:a5:11:40, ethertype IPv4 (0x0800), length 66: 180.13.2.100.57657 > 180.13.2.1.bfd-control: BFDv1, Control, State Down, Flags: [none], length: 24

      13:55:11.445074 28:99:3a:3b:15:39 > 44:4c:a8:a5:11:40, ethertype IPv4 (0x0800), length 66: 180.13.2.100.57657 > 180.13.2.1.bfd-control: BFDv1, Control, State Down, Flags: [none], length: 24

      ISIS should notify the BFD to establish session after ISIS neighbor up. So the symptom is narrowed down to ISIS neighbor issue. 

      Step 3: Tcpdump ISIS IIH (isis hello) on both sides 

      -- show ver | grep MAC to get system MAC --

      R1#show ver | grep MAC
      System MAC address:  444c.a8a5.1140

      R2#show ver | grep MAC
      System MAC address:  2899.3a3b.1539

      R2: IIH 2-way and looks good, R1/R2 send IIH every 10 seconds

      -- bash tcpdump -ni <intf> iih --
      [admin@R2 ~]$ tcpdump -ni et11_1 iih
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on et11_1, link-type EN10MB (Ethernet), capture size 262144 bytes
      11:18:16.104275 44:4c:a8:a5:11:40 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0001, length 1497
      11:18:18.000062 28:99:3a:3b:15:39 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0103, length 1497
      11:18:24.723990 44:4c:a8:a5:11:40 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0001, length 1497
      11:18:27.597320 28:99:3a:3b:15:39 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0103, length 1497

      R1: IIH, only 1 way, from R1 to R2, no R2 to R1

      [admin@bn303 ~]$ tcpdump -ni et11_36_2 iih
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on et11_36_2, link-type EN10MB (Ethernet), capture size 262144 bytes
      11:23:53.268387 44:4c:a8:a5:11:40 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0001, length 1497

      11:24:02.823894 44:4c:a8:a5:11:40 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0001, length 1497

      IIH packets are destinated to well-known LAN broadcast address (0900:2b00:0005). These packets can't reach from R2 to R1. 

      Step 4: Arping

      Arping shows similar, R1 to R2 is good, but seeing broadcast packets (all ff) drop on the direction of R2 to R1 even with arp ping

      * Arp ping is to send our brocast L2 arp request to probe hosts

      [admin@R1 ~]$ arping -b -I et11_36_1 180.13.1.100
      ARPING 180.13.1.100 from 180.13.1.1 et11_36_1
      Unicast reply from 180.13.1.100 [28:99:3A:3B:15:39]  419.967ms
      Unicast reply from 180.13.1.100 [28:99:3A:3B:15:39]  409.205ms
      Unicast reply from 180.13.1.100 [28:99:3A:3B:15:39]  401.616ms
      Unicast reply from 180.13.1.100 [28:99:3A:3B:15:39]  410.797ms
      ^CSent 4 probes (4 broadcast(s))
      Received 4 response(s)

      [admin@R2 ~]$ arping -b -I et11_1 180.13.1.1
      ARPING 180.13.1.1 from 180.13.1.100 et11_1
      ^CSent 9 probes (9 broadcast(s))

      Received 0 response(s)

      [admin@R2 ~]$ tcpdump -ni et11_1 arp
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on et11_1, link-type EN10MB (Ethernet), capture size 262144 bytes
      11:46:04.859574 28:99:3a:3b:15:39 > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 180.13.1.1 (Broadcast) tell 180.13.1.100, length 28

      11:46:05.859645 28:99:3a:3b:15:39 > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 180.13.1.1 (Broadcast) tell 180.13.1.100, length 28

      At this point, the issue is narrowed down to, broadcast packets from R2 to R1 are dropped unexpectedly, which causes R1 not seeing R2's IIH packets, then no ISIS/BFD neighbor.  

      Step 5: hardware issue, but who drops the packets?

      Ok, now we can say, most likely the problem is hardware, but who? The best way to nail down the culprit is to mirror packets to cpu, to see if the broadcast packets leave the R2. 

      * The feature of mirroring interface packets to CPU is only supported on Sand (Jericho/Arad) platform. 

      R1.14:32:14(config)#monitor session 1 source ethernet 11/36/1 rx
      R1.14:32:19(config)#monitor session 1 destination cpu

      Seeing IIH from R2 to R1 on the mirror cpu. << This is the packets received on the wire of et11/36/1

      R1.14:32:20(config)#bash tcpdump -ni mirror0 iih
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on mirror0, link-type EN10MB (Ethernet), capture size 262144 bytes
      14:33:04.105249 28:99:3a:3b:15:39 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0103, length 1497
      14:33:13.257565 28:99:3a:3b:15:39 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0103, length 1497
      14:33:21.554871 28:99:3a:3b:15:39 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0103, length 1497

      But not on the physical ethernet port << This is the packets received by the kernel via et11/36/1

      R1.14:33:22(config)#bash tcpdump -ni et11_36_1 iih
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on et11_36_1, link-type EN10MB (Ethernet), capture size 262144 bytes
      14:33:35.056748 44:4c:a8:a5:11:40 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0001, length 1497

      14:33:42.990686 44:4c:a8:a5:11:40 > 09:00:2b:00:00:05, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): p2p IIH, src-id 0000.0000.0001, length 1497

      Now we know the broadcast packets are dropped on R1 between eth and kernel. 

      Step 6: Counters

      And this is approved by the counter output on both R1 and R2

      R2/Trident - No loss

      R2#clear counters
      R2#clear platform trident counters
      R2#sh cpu counters queue | nz

      --------------------------------------------------------------------------------
                                       Linecard0/0
      --------------------------------------------------------------------------------
      Queue                                          Counter/pkts*          Drops/pkts
      ---------------                          ------------------- -------------------
      OSPF/ISIS                                                  2                   0
      BFD                                                       10                   0
      R2#sh platform trident counters interface e11/1 | egrep -i 'card|drop' | nz
      R2#

      R1/Jericho - Loss seen

      R1#clear hardware counter drop
      R1#clear counters

      R1#sh cpu counters queue | grep 'Et11/36/1' | nz

      CoppSystemLldp             Et11/36/1                  4                924                  0                  0

      R1#sh hardware counter drop | grep o11/1
      A     Jericho11/1   DeqDeletePktCnt                :           39148 : 2019-04-16 11:59:39 : 2019-04-16 11:59:39
      P     Jericho11/1   dropVoqInNullRoute             :      3800339040 : 2019-04-16 11:59:39 : 2019-04-16 11:59:39

      R2#sh hardware counter drop | grep o11/1
      A     Jericho11/1   DeqDeletePktCnt                :           39153 : 2019-04-16 11:59:39 : 2019-04-16 11:59:45
      P     Jericho11/1   dropVoqInNullRoute             :      3800605701 : 2019-04-16 11:59:39 : 2019-04-16 11:59:45

      So, should goes to DeqDeletePktCnt or dropVoqInNullRoute. What does they mean?