7/30/2018

VXLAN Routing with MLAG

VXLAN Routing with MLAG
https://eos.arista.com/vxlan-routing-with-mlag/
  • VXLAN routing routes pkt based on IP address in inner header, not outer VXLAN header. 
  • 有个示意图,可以帮助理解
    • 在SW-1其实就是简单的Inter VLAN SVI routing
    • 只是SVI-VLAN 20有个VTEP/VNI,所以可以Learn到DEST MAC of Svr2
    • Srv-2‘s GW SVI-VLAN-20 is on VTEP-1/SW-1
    • VNI 1020 链接左右的L2 Domain
  • Routing Topologies
    • Direct Routing - routing at 1st-hop leaf node for ALL subnets. 
    • Indirect Routing - only route for ONE subnet, reduce amt of ARP/MAC resource on leaf
    • Indirect is a derivative of direct
  • Direct Routing
    • works by creating anycast IP address:
      • Leaf acts as GW, owns and responds ARP req
    • 所有Leaf Config same "ip address virtual" and "ip virtual mac"
  • ip address virtual 10.10.10.254/24
    • No routing over an VLAN interface w/ "ip address virtual"
    • VTEP w/ "ip address virtual" will fwd any ARP responses to virtual router MAC to all neighbor VTEPs via HER(head-replication). So neighbor VTEPs host same ARP tables. 
    • in MLAG, ARP res to "virtual ip addr" are sync'ed with MLAG peer. 
    • Note: ARP sync between MLAG is done via VXLAN agent, hence "ip virtual address" is ONLY supported with VXLAN config
  • virtual VTEP:
    • 每个Leaf都有Virtual IP addr + MAC, 所以都可以response ARP req. 
    • 所以建立一个vVTEP. 不太明白
  • ARP Timer
    • Serv1 sends ARP req to VTEP1. By routing, VTEP1 would learn MAC of Serv4 via initial ARP req. 
    • But not via subsequent bi-directional data traffic, because returning traffic could be ECMP'd to VTEP2, which also routes and rewrite SrcMAc of  inner pkt by VTEP2 mac. 
    • To avoid MAC being flush (default timeout is 5 min), it is advised to config ARP aging timeout (default 4 hours) less than MAC timeout. 
    • So force a ARP refresh and re-learning MAC. 
  • Direct Routing Config:
    • VTEP only needs to announce its loopback/end-point into BGP. 
    • Then tenant subnets exit only on the leafs, NOT in BGP or on spines. 
    • show vxlan address-table
    • show mac address-table

VXLAN (2) - RFC 7348

  • 明白一个概念, Overlay - overlay L2 connectivity over L3 network
    • Inter-VM 需要L2 access mode
    • 但是DC Infra都是 L3/IP, 因为ECMP,
    • 所以Overlay = provide L2 network over L3 infra
  • Bcast/Unknown traffic via Mcast
    • 这个在EOS里面没有implement,客户不喜欢this approach; 
    • 现在就是简单Flood, 所以Mcast/Bcast/Unknown traffic会被复制多份
  • Pkt @ IP/UDP (dest port 4789)

VXLAN Bridging with MLAG

VXLAN Bridging with MLAG
  • Key takeaways:
    • FH VTEP Encap/Decap
    • Routing between MLAG peers
    • MLAG peers share the same loopback/VTI address
  • https://eos.arista.com/vxlan-with-mlag-configuration-guide/
  • Provides remote L2 connectivity between racks or DC;
  • Each MLAG domain(2 MLAG peers) has ONE logical VTEP
    • Same virtual tunnel ip address (VTI)
    • 因为两个MLAG Peer work as ONE physical switch
  • MAC Sync:
    • For encap/decap traffic, both local and remote MAC address need to be sync'ed between peers via peer-link
    • remote = remote MAC associated with remote VTEP ip address. 
Configuration (same on both Mlag peers)
    interface loopback1
     ip address 192.168.0.1/32
    interface vxlan1
     vlan source-interface loopback 1
     vxlan udp-port 4789
     vxlan vlan 10 vni 10
     vxlan vlan 10 flood 192.168.0.2

      MAC, ARP, Traffic例子
      • serverA (macA) under MLAG domain 1 (Peer1A和1B),比方说VLAN 10,sends ARP request
        • ARP Req 会被Hash over 1 link of 2-port LAG. 
      • Peer1A受到这个ARP req, 有4个Actions
        • Act#1: peer1A floods this ARP Req所有本地VLAN 10的端口,因为是Bcast Pkt
        • Act#2: peer1A floods it to peer1B,这是给peer1B上面的Singly端口
          • peer1B只会flood singly ports,而不会flood dual-home ports
        • Act#3: peer1A sync with 1B,peer1B知道 macA 是在Port-channel上面
          • 这个Sync是另外的 MLAG signaling, 
        • Act#4: peer1A ENCAP ARP in VXLAN and floods all VTEP
          • FH GW 负责encap/decap vxlan traffic
      • VXLAN pkt is ECMP'ed to spine then to remote Peer2A/B,
        • Pear2A/B 和 1A/B一样,share一个VTI address,所以逻辑上是一个
        • peer1A ECMP to one spine;
        • This spine 有2个path to VTEP 192.168.0.2, 比方说ECMP to peer2A
        • Peer2A首到ARP req, DECAP VXLAN pkt and learns MACa in from VTEP 192.168.0.1, 以下是标准的MLAG流程 和 Peer1A很类似
          • Act#1: Peer2A flood ARP req all local ports
          • Act#2: Peer2A flood it via peer-link for those singly ports on Peer2B
          • Act#3: Peer2A sync‘s with Peer2B, MACa from VTEP 192.168.0.1
            • peerRemoteDynamic
        • ServerB unicasts ARP response to ServerA
          • dstMAC = MAC.AAA; srcMAC = MAC.BBB
        • Now both peer2A/2B know MAC.AAA is on VTEP 192.168.0.1, and ARP response is encap into VXLAN and routed to peer1B
          • ENCAP ARP reply on FH device
        • 如果peer1B 收到这个ARP reply, 
          • Learns MAC.BBB from VTEP 192.168.0.2, remoteDynamic;
          • sync with peer1A
          • and pkt fwd down to port-ch 10
        Useful CLIs:
        • show mac address, Ports里面有Vx1
        • show vxlan address-table, 有Mac/Vtep/Port
          Switch over 例子,例如Peer1A lose all uplinks
          • First Hop MLAG Peer/VTEP,负责encap/decap pkts, 这个是Principle
          • 例如MLAG peer1A lost all uplinks,但是device is up running
            • 还是Peer1A encap/decap pkts
            • 需要Routing between peer via Peerlink
          • Best Practise是建议routing on a dedicated VLAN而不是Peerlink VLAN 

          7/24/2018

          Arista EOS - "ip virtual mac-address mlag-peer"

          Say, in a mlag environment, 

          • The hosts can not understand the vMAC in the ARP packets. For example, some F5 and Netapp devices only check the srcMAC of ARP reply, instead of the srcHwMAC inside the ARP.
          • These host hashes the traffic with gateway's system mac to 2 mlag peers. 
          • When mlagPeer1 receives packets with dstMAC = mlagPeer2 system MAC, it should forward it to peer2 via peerlink, not good, a totally waste of peerlink
          • We can configure "ip virtual-router mac-address mlag-peer", which enables the peer to consume packets destined to peer and route them directly. 

          psp111.14:56:21#sh platform trident l3  shadow my-station
          My Station Tcam:
          --------------------------------------------------------------------------------
          Id    Vlan/Mask                                  Mac/Mask       VVVVMACD         T/       ModId/    IngPort/
                                                                          4646PRPS       Mask         Mask        Mask
                                                                          UUMMLPUC
                                                                          CCCCS  D
          7         0/0x0       44:4c:a8:93:22:9b/ff:ff:ff:ff:ff:ff       00000000        0/1        0/0x0      0/0x7f
          8         0/0x0       44:4c:a8:93:22:9b/ff:ff:ff:ff:ff:ff       11001000        0/0        0/0x0       0/0x0
          9         0/0x0       01:00:5e:00:00:00/ff:ff:ff:00:00:00       00000100        0/0        0/0x0       0/0x0
          10        0/0x0       44:4c:a8:93:29:d5/ff:ff:ff:ff:ff:ff       11001100        0/0        0/0x0       0/0x0
          11        0/0x0       00:dc:00:02:00:01/ff:ff:ff:ff:ff:ff       11001100        0/0        0/0x0       0/0x0

          7/20/2018

          Arista EOS - BGP maintenance mode

          Basically the BGP maintenance mode on Eos is an implementation of BGP G-SHUT in RFC 8326. The mechanism is quite simple and effective:
          • Add an outbound policy to attach GSHUT community to all prefixes, and it triggers a re-advertisement;
          • Add an inbound policy to set LOCAL_PRF = 0 to all incoming prefixes. 
          • Wait bgp convergence then shut bgp session
          The issue to be solved here is: if backup path is hidden by RR or nodes of an AS, it will trigger relearn routes and put them effective. 

          Configuration: (system-level in Arista)
          config
          maintenance
             unit System
                profile unit System
          install source scp:solomon@server/export/images/EOS.swi destination flash:
          copy runn start
          quiese
          reload now force
          show ip bgp summary
          show ip bgp 0.0.0.0/0 detail (in any leaf to verify GSHUT)


          show output (before quiesce)

          !! Gshut initiator (dut to reload)

          ck421.15:08:47(config-builtin-unit-System)#sh ip bgp neighbors | egrep '^BGP|Updates:'
          BGP neighbor is 100.1.11.1, remote AS 65110, external link
                                   Sent      Rcvd
              Updates:             2810      2574

          !! BGP neighbor

          pts321.15:06:07(config)#sh ip bgp 2.2.2.2/32 detail
          pts321.15:06:14#sh ip bgp 2.2.2.2/32 det
          BGP routing table information for VRF default
          Router identifier 100.1.11.1, local AS number 65110
          BGP routing table entry for 2.2.2.2/32
           Paths: 5 available
          ....
            65100 65120
              192.1.0.0 from 192.1.0.0 (169.169.169.1) <<< Initiator 
                Origin IGP, metric -, localpref 100, weight 0, valid, external, ECMP, ECMP contributor
                Not best: ECMP-Fast configured

          show output (after quiesce)

          ck421.15:11:28(config-builtin-unit-System)#sh ip bgp sum
          BGP summary information for VRF default
          Router identifier 169.169.169.1, local AS number 65100
          Neighbor Status Codes: m - Under maintenance
            Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State  PfxRcd PfxAcc
          m 192.1.0.1        4  65110            100       103    0    0 01:15:55 Estab  11     11
          m 192.1.0.3        4  65110            100       104    0    0 01:15:55 Estab  11     11

          ck421.15:11:13(config-builtin-unit-System)#sh ip bgp neighbors | egrep '^BGP|Updates:|Sent.*Rcvd'
          BGP neighbor is 100.1.11.1, remote AS 65110, external link
                                   Sent      Rcvd
              Updates:             4233      2574  <<< 2810 vs 4233 (resend)

          pts321.15:06:20#sh ip bgp 2.2.2.2/32 det
          BGP routing table information for VRF default
          Router identifier 100.1.11.1, local AS number 65110
          BGP routing table entry for 2.2.2.2/32
           Paths: 5 available
          ....
            65100 65120
              192.1.0.0 from 192.1.0.0 (169.169.169.1)
                Origin IGP, metric -, localpref 0, weight 0, valid, external
                Not best: Local preference
                Community: GSHUT <<<<< 

          7/12/2018

          Arista EOS: tcpdump the VRF interface

          Use the Linux name space: 

          [admin@dc7050 ~]$ sudo ip netns exec ns-<vrf> tcpdump -i vlan2101 arp

          7/10/2018

          Arista: BGP neighbor next-hop-unchanged doesn't work in gated mode

          A bit background, in Arista EOS, there is 2 implementations of BGP process. Default is gated, and late one is multi-agent, which can be enabled via cli - service routing protocols model multi-agent. 

          BGP neighbor next-hop-unchanged is only supported in multi-agent mode, not in gated. This feature works in route-map with both modes. 

          7/09/2018

          Arista - traffic disruption during LAG reprogramming

          No traffic disruption is expected during LAG reprogramming like adding/removing member ports. There is only one exception - on Sand(Arad/Jericho) platforms, if software Lag is enabled, traffic loss will be seen when # of Lag is changed from 1 to 2,  and vice versa. And software Lag can be disabled by knob - "platform sand lag hardware-only".

          6/26/2018

          Arista J/J+ FlexRoute with Internet Routing Table

          https://www.arista.com/assets/data/pdf/Whitepapers/FlexRoute-WP.pdf
          • CLI: 
            • ip hardware fib optimize prefix-length internet
            • show ip bgp summary
            • show ip route summary
            • show hardware capacity | grep Routing
          • Routing HW resources are sliced to fit the route distribution of REAL internet routing table
          • If loading a lab configuration like Ixia, you mean see the error message like - "%CAPACITY-1-UTILIZATION_HIGH. LEM table utilization is currently at 91%, crossed threshold 90%"
          • For example, if too many /24, it will be moved to LEM
          • And another important concept of prefix, route and FIB:
            • 3 x internet feeds = 3 x 600K prefixes
            • 3 prefixes of same dest = 1 route with 3 NH if ECMP
            • 1 route = 1 FIB entry

          IP fragmentation on Arad platform


          • Fragmented/MTU violated packet is sw forwarded and shaped by CoPP or PDP;
          • CoPP = 2~2.5 Mbps
            • "no shape" under copp-system-mtu can make it 100Mbps
          • PDP = 100 Mbps
          • But not a good idea to do it. 

          6/15/2018

          TH/Trident low LPM

          On Arista DCS-7260CX-64-F platform, if you see hw resource - LPM/V4Routes running out, have to change the "platform trident forward partition". Agent will restart but doesn't a reboot. 

          nv475.08:45:07(config)#sh hardware capacity utilization percent exceed 50
          Forwarding Resources Usage

          Table   Feature    Chip       Used   Used      Free    Committed    Best Case        High
                                     Entries    (%)   Entries      Entries          Max   Watermark
                                                                                Entries
          ------- ---------- ------ --------- ------ ---------- ------------ ------------ ---------
          LPM                           8190   100%         0            0         8190        8190
          LPM     V4Routes              8190   100%         0            0         8190        8190

          nv475.08:52:45(config)#sh ip route 151.131.34.0

          VRF: default
          ======================================================
          WARNING: Some of the routes are not programmed in
          hardware, and they are marked with '*'.
          ======================================================

          *B E    151.131.34.0/24 [200/0] via 100.1.0.44, Vlan10

          nv476.11:05:47#sh platform trident forwarding-table partition
          L2 Table Size: 72k
          L3 Host Table Size: 72k
          LPM Table Size: 16k, uRPF is disabled

          nv475.09:27:35(config)#platform trident forwarding-table partition ?
            0  136k l2 entries, 8k l3 host, 16k lpm entries
            1  104k l2 entries, 40k l3 host, 16k lpm entries
            2  72k l2 entries, 72k l3 host, 16k lpm entries
            3  40k l2 entries, 104k l3 host, 16k lpm entries
            4  8k l2 entries, 8k l3 host, 90k lpm entries <<< this one!

          But this change will impact MLAG because lower MAC capacity. 

          6/04/2018

          Take away notes from RFC5549 video by AMX-IX


          • https://www.youtube.com/watch?v=uJOtfiHDCMw
          • AMS-IX running out /22 ipv4 NH address space
          • Solution #1: more address space:
            • ARP broadcast too much
          • Solution #2: private address by RFC1918, 10/8, 172.16/12, 192.168/16
            • Space used by ISP customer
            • More specific in IGP
            • Break traceroute
          • Solution #5: RFC5549
            • IPv4 NLRI over IPv6 NH
            • 2 ways to implement it:
              • v4 in v6 tunnel, add 40B head
              • direct forwarding - just replace the MAC, no change;

          5/22/2018

          MLAG Fast Convergence - MAC Redirection/Promption

          https://eos.arista.com/eos-4-18-0f/mlag-unicast-convergence/

          Problem Description:


          Consider the following setup 

          • mlagA and mlagB are 2 mlag peers with port-ch 2000;
          • The host MAC - 0000:1111:2222 is learnt on MLAG 10 and A is the owner. 
            • In another way, MAC 0000:1111:2222 is A's local MAC and B's remote
          • A bit background:
            • The MAC address and ARP information are all sync'ed during boot-up;
            • After that, only MAC table is sync'ed, for example, A tells B that MAC a.b.c is from mlag po10, or singly interface, or remote vtep. 
            • So in the MAC table, the MAC has at least 4 states:
              • learnedDynamic (local mlag), 
              • peerDynamic (remote mlag), 
              • learnedRemoteDynamic (vxlan) 
              • peerRemoteDynamic (remote vxlan)
            • Get this information by command - show mac address mlag-peer



          Now saying we have 

          • link failure, which has 2 loss: down and up
            • when B's po 10 is down, all MAC are re-programmed from po 10 to po 2000, so be MAC move is done one by one in old releases before 4.18.1F. (#1)
            • when B's po1 10 is back up, the ACL on peerLink to block BUM traffic immediately to break L2 loop while the MAC move needs time to be completed. (#2)
          • node failure, which introduces 3 loss, down, up and delay timeout
            • node down, 100s msec loss depending on scale
            • node up, 100s msec loss (#3)
              • When the peerlink is up, why? At this time, peerB has no uplink or downlink up, which are all in reload-delay. 
              • Remember the MAC sync mentioned above? A needs to sync up with B on the MAC, so on A these MAC learnt from B will be flushed!!
              • A has to relearn these MAC, 50% all of sudden. Still ok for locally switched packets because the hw flooding kicks in. 
              • But bad for Vxlan, which requires software flood for the head-end-replication. 
            • reload-delay timeout, 100s msec, actually 2 times
              • Need to have iBGP or IGP L3 routing between 2 peers.
              • Since peerlink is up fast and much earlier than mlag/non-mlag interface. So when non-mlag or mlag interfaces are up, they can send the traffic to peer link before the optimal path converged. 
          Feature and solution

          So from 4.18F, a feature called MLAG fast MAC redirection is developed to address above issues. This feature has 2 aspects:

          1. MAC redirect, for #1 and #2 loss
          • With this feature, the the interface attribute of impacted MACs still point to MLAG po 10 in host table. So, no move at all. 
          • Strata and Sand implementation are slightly different but same idea. 
          • On Sand, it is to use a recirc channel on each Arad/Jericho chip to recycle the MLAG destined packets over to peer-link. 
          • Requirements and limitation:
            • Peerlink must be a LAG not Ethernet on Strata. 
            • On Sand "platform sand lag hardware-only" must be enabled, I believe only hw LAG can share member port - the recirc channel. 
            • MLAG ASU2 cannot co-exist. 
          2. MAC address promotion, targeting #3. 
          • When 1) peer reboot; 2) hitful restart of fwding plane, the remote MACs (learnt via peer switch) will be flushed, which cause
          • 1) before the MAC is re-learnt, packets needs to flooded. Still ok in pure L2/L3 environment because done by hw;
          • 2) software forward of Vxlan packets. That's a big issue because it results in drops by CoPP. 
          • Why the MACs are flushed?
            • when peerB is up, MAC are sync'ed from A to B. These remote MAC are flushed. No MAC, then flooding. 
          • Solution: 
            • when peerB is down, the ownership of MAC are transfered to peerA
            • when peerB recovers, *ALL* MAC are sync'ed from A to B
          • Details:
            • when peerB is down, peerA enters failover state;
            • peerDynamic, peerLearnedRemote to learnedDynamic, learnedRemoteDynamic
            • NOT single-leg host
          Misc:
          • From AD1554:
            • If all uplinks are L3 interfaces, then it is preferable to keep non-mlag reload-delay timer < mlag timer, so
              • Upstream/L3 up first before downstream/L2;
              • In this way, S-N traffic should be no loss. 
            • Enabled "reload-delay mode lacp standby", need to have non-mlag timre >= mlag timer,
              • MLAG interfaces with LACP are kept warm for LAG membership table, MAC table programming. 
              • But upstream/L3 must be up after L2/downstream/mlag interfaces, otherwise S/N traffic are blackhole'd. 
          • From AD3152:
            • SandL3Unicast - managing NH and ensuring EEDB no change
            • SandACL - programming DROP ACL on the peerLinkRecircPort avoid pkts from peerLink back to peerLink
            • Assigning LagMemberID is interesting, this peerLinkRecircPort needs a member id. what about overflown?
            • LAG member, C/D bit
              • C = collecting, D = Distributing
              • if static LAG, C/D=True, added to LAG
              • if LACP enabled, only C=True, D=True, member can be added. 
              • peerLinkRecircPort is always C/D=False/True
            • LC removal event
              • If all ports on this LC, 
                • L3 will have some downtime since losing all ARP entries; 
                • L2 should be fine once recirc port is programmed. 
              • If at least 1 member on another LC, L2/L3 should be fine
            • This is quite complicated! 
              • 3/1, 3/36, 4/1 are local member of mlag Po 10
              • all 3 ports down, all 3 members retained with C/D=False
              • PeerLinkRecicFap is added from either 3/0, 3/2 or 4/0 
              • If LC3 is pulled, peerLinkRecirFap 4/0 is added. 
              • And a lot of combination of events, LAG config change, member port down...
            • 4 events:
              • LC removal
              • LAG config change: unconfig and change config
              • Member port down or cable unplug
              • port-ch shutdown
          • CLIs:
            • show plat trident counter int e27/1
            • Drops counts in Vlan boundary = Vlan ID missed. In another word, the VLAN id programming on this interface is not done yet. 
          Reference:
          • PeerOne Vxlan + MLAG
          • AD3398, BG141435/96642
          • AD3152
          • AD1554

          5/15/2018

          Arista EOS - %HARDWARE-3-DROP_COUNTER_ALERT, DchUnreachables

          What does the following log message mean?

          May 15 15:45:42 bn302 EventMgr: %HARDWARE-3-DROP_COUNTER_ALERT: Persistent Internal Drop 'DchUnreachables': 792271126642 detected on Fe3600-3/1

          And there is high # of drop in the output of "sh hardware counter drop"

          bn302.jhm.mlagB.profA0.w.15:47:58#show hardware counter drop
          Summary:
          Total Adverse (A) Drops: 20098028670058
          Total Congestion (C) Drops: 0
          Total Packet Processor (P) Drops: 72029
          Type  Chip         CounterName                    :           Count : First Occurrence    : Last Occurrence
          --------------------------------------------------------------------------------------------------------------
          A     Fe3600-4/2   DchUnreachables-1              :    103285456899 : 2018-05-15 15:34:55 : 2018-05-15 15:35:07

          Basically when the LCs are not ready and up, the Fabric modules don't know where to forward the packets, they will drop them and increase this counter. It is quite common during system booting up. 

          5/11/2018

          How to use python/yaml

          import yaml
          import sys

          with open(sys.argv[1], 'r') as stream:
             try:
                paramDict = yaml.load(stream)
             except yaml.YAMLError as err:
                print(err)
                sys.ext(0)

          print paramDict['Devices']['Switch']['mlagA']['Mgmt']['Host']

          ============
          Devices:
             Switch:
                mlagA:                                 # MLAG Dut1
                   Mgmt:                               
                      Host: bn303
                      AccessMethod:    ssh             # ssh or capi
                      SshUsername:     admin           # default admin
                      ChassisType:     modular         # fixed or modular
                      CapiProtocol:    https

          ~/py @arst1.sjc> python test.py test.yaml

          bn303

          4/17/2018

          Arista L3 Leaf/Spine Step by Step (2d) - VxLAN Bridging, interesting behavior



          This post is for the paranoid, who really wants to know how it works under the hood. Based on previous setup, we see 2 interesting behaviors

          1. Jericho MLAG peers also receive the arp reply

          wa462.vtepB1#bash tcpdump -nvvi vlan2000 arp
          tcpdump: listening on vlan2000, link-type EN10MB (Ethernet), capture size 262144 bytes
          20:49:20.171267 44:4c:a8:97:72:b7 > Broadcast, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Request who-has 20.0.12.250 tell 20.0.8.250, length 42

          20:49:20.171590 28:99:3a:3d:68:61 > 44:4c:a8:97:72:b7, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Reply 20.0.12.250 is-at 28:99:3a:3d:68:61, length 42

          wa463.vtepB2#bash tcpdump -nvvi vlan2000 arp
          tcpdump: listening on vlan2000, link-type EN10MB (Ethernet), capture size 262144 bytes
          20:49:20.172821 44:4c:a8:97:72:b7 > Broadcast, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Request who-has 20.0.12.250 tell 20.0.8.250, length 42

          20:49:20.173117 28:99:3a:3d:68:61 > 44:4c:a8:97:72:b7, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Reply 20.0.12.250 is-at 28:99:3a:3d:68:61, length 42

          44:4c:a8:97:72:b7 is the MAC address of host2 belonging to vtep2. Why these 2 peers receive this unicast packet? The reason is that, when the VtepX1/X2 the first packet from remote Vtep, it will need some time to create a hw tunnel. During this gap, Vtep has to flood this ucast packet to all Vteps. 

          When Vtep has no remote Vxlan MAC

          ckp341.vtepX1#sh mac address-table dynamic interface vxlan 1
                    Mac Address Table
          ------------------------------------------------------------------

          Vlan    Mac Address       Type        Ports      Moves   Last Move
          ----    -----------       ----        -----      -----   ---------
          Total Mac Addresses for this criterion: 0

                    Multicast Mac Address Table
          ------------------------------------------------------------------

          Vlan    Mac Address       Type        Ports
          ----    -----------       ----        -----
          Total Mac Addresses for this criterion: 0

          So Vtep has no remote vtep

          ckp341.vtepX1#show vxlan vtep
          Remote VTEPS for Vxlan1:
          Total number of remote VTEPS:  0


          Let's create a static MAC pointing to remote VTEP. After there is a remote Vtep. 


          ckp341.vtepX1(config)#mac address-table static 0000.1111.2222 vlan 2000 interface vxlan 1 vtep 200.255.200.8

          ckp341.vtepX1(config)#show vxlan vtep
          Remote VTEPS for Vxlan1:
          200.255.200.8
          Total number of remote VTEPS:  1

          Repeat the ping. Now the Mlag peer doesn't receive the unicast packet. 

          wa462.vtepB1(config)#bash tcpdump -nvvi vlan2000 arp
          tcpdump: listening on vlan2000, link-type EN10MB (Ethernet), capture size 262144 bytes
          22:22:16.623983 44:4c:a8:97:72:b7 > Broadcast, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Request who-has 20.0.12.250 tell 20.0.8.250, length 42

          2. ONLY 1 T2+ MLAG peer see receive the arp request, and no arp reply.

          vtep1 has no arp req

          snp262.vtepA1(config)#bash tcpdump -nvvi vlan2000 arp
          tcpdump: listening on vlan2000, link-type EN10MB (Ethernet), capture size 262144 bytes
          ^C
          0 packets captured

          vtepA2 sees arp req

          snp263.vtepA2(config)#bash tcpdump -nvvi vlan2000 arp
          tcpdump: listening on vlan2000, link-type EN10MB (Ethernet), capture size 262144 bytes
          06:27:56.665383 44:4c:a8:97:72:b7 > Broadcast, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Request who-has 20.0.12.250 tell 20.0.8.250, length 42
          ^C
          1 packet captured

          This is because Trident family ASIC pipeline can't handle vxlan decap and routing in 1 pass. The arp req seen on vtepA2 is flooded by vtepA1. From the output of "show mac address mlag-peer", you can see vtepA2 learning this MAC from mlag-peer.

          snp263.vtepA2(config)#sh mac address-table mlag-peer
                    Mac Address Table
          ------------------------------------------------------------------

          Vlan    Mac Address       Type        Ports      Moves   Last Move
          ----    -----------       ----        -----      -----   ---------
          2000    0000.1111.2222    STATIC      Vx1
          2000    001c.73ff.405e    STATIC      Po2000
          2000    444c.a897.72b7    DYNAMIC     Vx1        1       0:00:25 ago
          4094    001c.73ff.405e    STATIC      Po2000
          Total Mac Addresses for this criterion: 4


          Arista L3 Leaf/Spine Step by Step (2c) - VxLAN Bridging, packet walkthru

          Step 1: Ping hostX from host2. 

          Before that we clear arp so force the host2 to send out broadcast arp req. Also run "bash tcpdump -nvvi vlan2000 arp" to see the arp packet behavior


          Step2: host2 sends the arp to vtep2. 




          Step 3: Vtep flood ARP req.


          Besides flooding out the local vlan ports, the vtep will also do hardware replication to send 1 copy to each remote vtep, which is called HER (head-end-replication)

          Please note that, only ONE mlag peer receive this arp request based on the hashing. Because 2 mlag peers share the same loopback, they appear as 1 destination with 2-way ecmp. 




          Step 4: Remote Vtep learn and flood


          When the remote VTEP receives this arp req, they will do:
          1) flood all local ports to reach the destination; 
          2) send it to mlag peer via peer link if applied; 
          3) learn the MAC address of host2, like

          wa462.vtepB1#sh mac address-table dynamic | grep 72b7

          2000    444c.a897.72b7    DYNAMIC     Vx1        1       0:00:42 ago

          wa463.vtepB2#sh mac address-table dynamic | grep 72b7

          2000    444c.a897.72b7    DYNAMIC     Vx1        1       0:00:42 ago

          Why flooding to MLAG peer? Say if there is one singly connected host but this arp request was hashed to the other MLAG peer. So we need this step to reach these orphan clients. 

          Please note that both MLAG peers assign the srcHost's MAC to interface Vx1. Basically, MLAG peer never learns the MAC via peer link. Instead, they use MLAG message to sync MAC learning. 



          Step 5. dstHost unicasts ARP reply back to srcHost

          Since VtepX1 nad VtepX2 already learn srcMAC, it knows how to unicast it back to srcVtep

          ckp342.vtepX2#sh mac address-table dynamic
          Vlan    Mac Address       Type        Ports      Moves   Last Move
          ----    -----------       ----        -----      -----   ---------
          2000    444c.a897.72b7    DYNAMIC     Vx1        1       0:00:03 ago



          4/16/2018

          Arista L3 Leaf/Spine Step by Step (2b) - Recirculation

          Topology:

          Recirculation

          In the previous blog, we see the host1 and host2 can NOT ping vtep3's SVI - VLAN2000 within the same VLAN. But host3 can reach this SVI. Why this happens?

          This is because the Trident II ASIC doesn't support routing with overlay, recirculation channel is needed to loop the VXLAN inter-VLAN traffic back to the pipeline for routing lookup on some Arista switches like 7050QX. 

          Bridging or Routing?


          Based on the dstMAC, the ASIC determines the incoming packets to go to bridging or routing. The ping/ICMP packets from host2 to vtep3 will proceed vxlan decapsulation. Because its dstMAC is to routerMAC of vtep3, it is routing. So T2 can't handle vxlan decap and routing in 1 pass, thus ping failed

          But if host2 pings host3, after vxlan decap, the packets are bridged. 

          Similar host3 pings vtep3, the packets don't go thru vxlan decap, so ping is good. 

          Which platform needs recirculation?

          Only all Trident-2 or TH based platforms have this limitation. From above topology, other vteps like Jericho, T2+ doesn't need this. 

          How to tell the chip model? The best way is to ask the account engineer who serves your account. Another way is to run the following CLI (based on my own experiences, if you know a better one please comment here. thanks!)

          7280QR-C36-F(config)#sh platform fap
          .....
          Jericho0   !!! clearly this is a Jericho-based

          7050QX-32-F#show platform fap
          % Invalid input !!! FAP = Sand/Petra/Arad/Jericho, not supported

          7050QX-32-F#show platform trident sys !! well this is a Trident 
                   Slice              Chip       ModId    GenId
          ----------------- ----------------- ----------- -----
             FixedSystem       Linecard0/0           1        1  
          ------------------------------------------------------

          Front panel vs internal ports

          On the T2 system, the circulation can be done by front panel port and internal ports, depending on the switch model. A T2 chip can support 32 x 40G ports, some platforms like 7050TX-72/96, 7050SX/72/96, 7050S-64 don't use all ports at front panel, while the remaining ports are called internal portsUsing internal ports is definitely better than front panel, because it doesn't impact your switch connectivity capacity. 

          So the next question is, how to tell if this switch has internal ports:-) Use CLI - "show inventory". 

          7050SX-64-F.10:36:59(config)#show inventory
          System has 81 ports
            Type             Count
            ---------------- ----
            Management       1
            Switched         64
            Unconnected      16  !!! has 16 unconnected ports

          7050QX-32-F(config)#show inventory
          System has 105 ports
            Type             Count
            ---------------- ----
            Management       1
            Switched         104 !!! No unconnected ports

          Configuration:

          Step1: Expose all internal ports (if the system has Unconnected ports under "show inventory", actually we don't need this for vtep3)
          mLeafB.cd631.Z(config)#service interface unconnected expose
          mLeafB.cd631.Z(config)#switch scheduler oversubscribed

          Step2: Configure Recirc-channel (if T2 system)
          upp224.vtep3(config)#int recirc-Channel 1
          upp224.vtep3(config-if-Re1)#switchport recirculation features vxlan

          Step3: Assign physical (front panel or internal) ports to recirc-channel

          upp224.vtep3(config-if-Re1)#int et34
          upp224.vtep3(config-if-Et34)#traffic-loopback source system device mac
          upp224.vtep3(config-if-Et34)#channel-group recirculation 1
          upp224.vtep3(config-if-Et34)#


          Step4: Verify

          upp224.vtep3#sh int recirc-Channel 1
          Recirc-Channel1 is up, line protocol is up (connected)
            Hardware is Port-Channel, address is 2899.3a8b.e6fa
            Ethernet MTU 9214 bytes , BW 10000000 kbit
            Full-duplex, 10Gb/s
            Active members in this channel: 1
            ... Ethernet34 , Full-duplex, 10Gb/s
            Fallback mode is: off

          Step5: ping from remote hosts

          wa466.host2(vrf:host2)#ping 20.0.9.253
          PING 20.0.9.253 (20.0.9.253) 72(100) bytes of data.
          80 bytes from 20.0.9.253: icmp_seq=1 ttl=64 time=0.218 ms
          80 bytes from 20.0.9.253: icmp_seq=2 ttl=64 time=0.150 ms
          80 bytes from 20.0.9.253: icmp_seq=3 ttl=64 time=0.109 ms
          80 bytes from 20.0.9.253: icmp_seq=4 ttl=64 time=0.107 ms
          80 bytes from 20.0.9.253: icmp_seq=5 ttl=64 time=0.106 ms

          --- 20.0.9.253 ping statistics ---
          5 packets transmitted, 5 received, 0% packet loss, time 0ms
          rtt min/avg/max/mdev = 0.106/0.138/0.218/0.043 ms, ipg/ewma 0.195/0.175 ms

          4/14/2018

          Notes of EOS VXLAN Chapter

          EOS VXLAN Chapter
          • Architecture, couple of new concepts with similar one in VLAN world
            • VXLAN = VLAN
            • VTEP = Switch
            • VTI = Port
            • VNI = VLAN
              • 1 VNI can attach different VLANs on different VTEP
          • HER (head-end replication) handles BUM traffic by using flood list
          • VXLAN vs MLAG
            • From downstream L2 devices perspective, MLAG peers appear as ONE single virtual switch, which is by MLAG protocol AUTOMATICALLY, like STP, system MAC, etc. 
            • But from upstream L3 devices, you have to configure MANUALLY to ensure one router, so the following info MUST BE SAME:
              • VLAN-VNI mapping
              • VTEP IP of loopback address
              • Flood VTEP list
            • And be careful:
              • OSPF ID must be manually configured to avoid duplicated to confuse the routing
              • On DCS-7050X platform (Trident II ASIC), need a recir interface to process the packets twice in case of VXLAN routing. 

          4/13/2018

          Arista L3 Leaf/Spine Step by Step (2a) - Vxlan Bridging, configuration

          Topology:


          Configuration:


          As long as you can reach the loopback 10 of each VTEPs, the Vxlan bridging configuration is quite straightforward:

          wa465.vtep2#sh run int vxlan 1
          interface Vxlan1
             vxlan source-interface Loopback10
             vxlan udp-port 4789
             vxlan vlan 2000 vni 2000
             vxlan flood vtep 200.255.200.7 200.255.200.8 200.255.200.9 200.255.200.12 200.255.200.34 200.255.200.56

          Basically, you need to specify the following parameters:

          • vxlan source interface. (loopback10 in this case)
          • vxlan udp port (by default is 4789)
          • vlan and vni mapping
          • vxlan vtep flood list. 
          Please note that you can include the local VTI in the flood list to keep vxlan interface configuration same across the whole domain. 

          Ping tests

          We can verify the setup by pinging the host address, and GW phy/virtual address. For example, from wa466.host2 (the host behind the bow-tie MLAG), 


          ping 20.0.12.250
          ping 20.0.12.251
          ping 20.0.12.252
          ping 20.0.12.253
          !
          ping 20.0.34.250
          ping 20.0.34.251
          ping 20.0.34.252
          ping 20.0.34.253
          !

          ping 20.0.56.250

          ping 20.0.56.251
          ping 20.0.56.252
          ping 20.0.56.253
          !
          ping 20.0.7.250

          ping 20.0.7.253
          !

          ping 20.0.8.250
          ping 20.0.8.253
          !
          ping 20.0.9.250
          ping 20.0.9.253 <<<< failed
          ....

          ! all successful except 20.0.9.253
          --- 20.0.9.250 ping statistics ---
          5 packets transmitted, 4 received, 20% packet loss, time 12ms

          rtt min/avg/max/mdev = 0.088/0.230/0.577/0.201 ms, ipg/ewma 3.049/0.424 ms

          The ping to all host and GW are successful, except the one from wa466.host2 to Vtep3. But the ping from bn303.host3 to vtep3's SVI works. Why?

          bn303.spine.host3(s1)(vrf:host3)#ping 20.0.9.253
          PING 20.0.9.253 (20.0.9.253) 72(100) bytes of data.
          80 bytes from 20.0.9.253: icmp_seq=1 ttl=64 time=0.214 ms
          80 bytes from 20.0.9.253: icmp_seq=2 ttl=64 time=0.096 ms
          80 bytes from 20.0.9.253: icmp_seq=3 ttl=64 time=0.100 ms
          80 bytes from 20.0.9.253: icmp_seq=4 ttl=64 time=0.086 ms
          80 bytes from 20.0.9.253: icmp_seq=5 ttl=64 time=0.087 ms

          This is because recirculation, which is required for Vxlan routing on T2 platform. We will cover it in next blog. 

          Configuration Files