Arista EOS: RSVP related features

  References:

• https://eos.arista.com/eos-4-25-1f/rsvp-te-ler/
• https://eos.arista.com/eos-4-23-2f/rsvp-te-lsr/
• https://eos.arista.com/eos-4-23-1f/bgp-nexthop-resolution-ribs-evpn-and-ipv4-6-labeled-unicast-support/
• https://eos.arista.com/eos-4-22-1f/bgp-nexthop-resolution-ribs-mpls-vpn-support/
• https://eos.arista.com/eos-4-22-0f/user-defined-tunnel-ribs/

Arista EOS: %ETH-4-ERRDISABLE: no-internal-vlan error detected

If you are seeing the following error message 

Jan 12 19:03:19 sn452 Ebra: %ETH-4-ERRDISABLE: no-internal-vlan error detected on Ethernet81.

And the output of "show interface status" indicates some ethernet ports are error-disabled like

sn452.19:00:35(config-if-Et1-104)#show interfaces status errdisabled
   Port        Name             Status         Reason
----------- ---------------- ----------------- ----------------
   Et81                         errdisabled    no-internal-vlan
   Et82                         errdisabled    no-internal-vlan

The reason for the above error is that EOS running out of internal VLAN for routed ports. The EOS needs to assign an internal VLAN for the none switching ports. If you have the following 2 lines of configuration, you may hit this error

switchport default mode routed <<< all ports are routed
vlan internal order descending range 4001 4080 <<< but only 80 VLANs assigned

So the solution is to remove the internal VLAN range. 

Why unprotected ISIS segment routing prefix with TiLFA enabled

 

In the above topology, the output of "show isis segment-routing prefix" on PE11 shows the SID of PE22 is not protected. 

bn303-PEa1.23:58:00(config-router-isis-af)#show isis segment-routing prefix-segments

System ID: 0000.0000.0011 Instance: 'isis-sr'

SR supported Data-plane: MPLS SR Router ID: 200.250.250.1

Node: 10     Proxy-Node: 0      Prefix: 0       Total Segments: 10

Flag Descriptions: R: Re-advertised, N: Node Segment, P: no-PHP

                   E: Explicit-NULL, V: Value, L: Local

Segment status codes: * - Self originated Prefix, L1 - level 1, L2 - level 2

  Prefix                      SID Type       Flags                   System ID       Level Protection

  ------------------------- ----- ---------- ----------------------- --------------- ----- ----------

......

  100.250.250.22/32            22 Node       R:0 N:1 P:0 E:0 V:0 L:0 0000.0000.0022  L2    unprotected

  100.255.255.31/32            31 Node       R:0 N:1 P:0 E:0 V:0 L:0 0000.0000.0031  L2    node

The reason the SID of PE22 is "unprotected" is that the PE11 has a 2-way ECMP to the destination. 

bn303-PEa1.23:58:01(config-router-isis-af)#show ip route 100.250.250.22/32

 I L2     100.250.250.22/32 [115/50] via 100.2.11.0, Ethernet3/1/1

                                     via 100.1.11.0, Ethernet10/36/1

Now let's the shutdown the interface between PE11 and P2 to break this ECMP. Now the prefix-segment is proteced now. 

bn303-PEa1.00:14:21(config)#int e3/1/1

bn303-PEa1.00:14:27(config-if-Et3/1/1)#shu

bn303-PEa1.00:14:31#show ip route 100.250.250.22/32

 I L2     100.250.250.22/32 [115/50] via 100.1.11.0, Ethernet10/36/1

bn303-PEa1.00:14:34#show isis segment-routing prefix-segments

Segment status codes: * - Self originated Prefix, L1 - level 1, L2 - level 2

  Prefix                      SID Type       Flags                   System ID       Level Protection

  ------------------------- ----- ---------- ----------------------- --------------- ----- ----------

...

  100.250.250.22/32            22 Node       R:0 N:1 P:0 E:0 V:0 L:0 0000.0000.0022  L2    node

  100.255.255.31/32            31 Node       R:0 N:1 P:0 E:0 V:0 L:0 0000.0000.0031  L2    node

Arista 7050CX - Packet Forwarding Pipeline

 

Reference: https://www.arista.com/assets/data/pdf/Whitepapers/Arista_7050X_Switch_Architecture.pdf

Arista EOS: how to ping link local address under VRF

Here is the subinterface configuration:

interface Ethernet34.4007
   description =>v7:Sp4-ck478
   mtu 9214
   encapsulation dot1q vlan 4007
   vrf cust
   ipv6 address fe80::1/64 link-local

To ping the remote link-local address, we could use 

RtrA#ping vrf cust ipv6 fe80:: interface et34.4007
PING fe80::(fe80::) from fe80::1%et34.4007 et34.4007: 72 data bytes
80 bytes from fe80::1%et31.4007: icmp_seq=1 ttl=64 time=0.076 ms
80 bytes from fe80::1%et31.4007: icmp_seq=2 ttl=64 time=0.029 ms
80 bytes from fe80::1%et31.4007: icmp_seq=3 ttl=64 time=0.027 ms
80 bytes from fe80::1%et31.4007: icmp_seq=4 ttl=64 time=0.027 ms
80 bytes from fe80::1%et31.4007: icmp_seq=5 ttl=64 time=0.032 ms

Arista EOS: % - Pending BGP convergence when "show bgp evpn"

1. Router(RR) receives 4 bgp evpn prefixes from RRC

wa465-PD.P1-JHM.SR.14:35:52(config-router-bgp-af)#show bgp evpn summary
BGP summary information for VRF default
Router identifier 100.250.250.30, local AS number 65000
Neighbor Status Codes: m - Under maintenance
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  100.250.250.11   4 65000            500       487    0    0 00:02:15 Estab   4      4
  100.250.250.12   4 65000            504       488    0    0 00:02:15 Estab   4      4

2. But "show bgp evpn" complains about "Pending BGP convergence"

wa465-PD.P1-JHM.SR.14:36:48(config-router-bgp-af)#show bgp evpn

BGP routing table information for VRF default

Router identifier 100.250.250.30, local AS number 65000

Route status codes: s - suppressed, * - valid, > - active, E - ECMP head, e - ECMP

                    S - Stale, c - Contributing to ECMP, b - backup

                    % - Pending BGP convergence

Origin codes: i - IGP, e - EGP, ? - incomplete

AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  LocPref Weight  Path

   %     RD: 100.250.250.12:100 auto-discovery 0 0000:0000:0000:1111:0000

                                 100.250.250.12        -       100     0       i

   %     RD: 100.250.250.12:1 auto-discovery 0000:0000:0000:1111:0000

                                 100.250.250.12        -       100     0       i

3. Check the NH, it was resolved in the tunnel rib

wa465-PD.P1-JHM.SR.14:37:33(config-router-bgp-af)#show tunnel rib brief | grep 100.250.250.12

   100.250.250.12/32       IS-IS SR IPv4       3               65                      115               20

4. The cause is the mis-configuration under router bgp evpn address family. The EOS needs to know to resolve the NH by using the mpls NH tunnel rib. 

wa465-PD.P1-JHM.SR.14:36:53(config-router-bgp-af)#router bgp 65000

wa465-PD.P1-JHM.SR.14:36:57(config-router-bgp)#add evpn

wa465-PD.P1-JHM.SR.14:37:00(config-router-bgp-af)#neighbor default encapsulation mpls next-hop-self source-interface loopback 0

wa465-PD.P1-JHM.SR.14:37:25(config-router-bgp-af)#show bgp evpn

BGP routing table information for VRF default

Router identifier 100.250.250.30, local AS number 65000

Route status codes: s - suppressed, * - valid, > - active, E - ECMP head, e - ECMP

                    S - Stale, c - Contributing to ECMP, b - backup

                    % - Pending BGP convergence

Origin codes: i - IGP, e - EGP, ? - incomplete

AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  LocPref Weight  Path

 * >     RD: 100.250.250.12:100 auto-discovery 0 0000:0000:0000:1111:0000

                                 100.250.250.12        -       100     0       i

 * >     RD: 100.250.250.12:1 auto-discovery 0000:0000:0000:1111:0000

BFD flaps in scale environment

 In a lab scenario, says between 2 routers, there are hundreds of sub-interfaces and a BGP session with BFD on each subinterface. Then BFD flaps is seen. The scale information is as followed:

• 256 subinterfaces
• 256 ebgp session enabled with BFD
• BFD timers are 50ms x 3

Addressing           Type                         Up        Init        Down    AdminDown

-------------------- -------------------- ------------- ----------- ----------- ---------

All                  All                     239 [0]       8 [0]       9 [0]        0 [0]

IPv4                 All                     239 [0]       8 [0]       9 [0]        0 [0]

    single hop       All                     239 [0]       8 [0]       9 [0]        0 [0]

                     normal                  239 [0]       8 [0]       9 [0]        0 [0]

From the above output, you can see 17 of 256 sessions are not up. And HW BFD is enabled (by default in Eos), but no helps. 

ghb289#show bfd hardware utilization
Chip Name          Number Of HW Sessions*    Maximum Number Of HW Sessions*
--------------- ---------------------------- ------------------------------
Jericho0                                0                               200
Jericho1                              128                               200
Jericho2                              128                               200

"show cpu counter queue" indicates high # of drop of CoppSystemBfd class, which means the receiving BFD packets exceeds the b/w limit of Copp.

ghb289#sh cpu counters queue |nz |grep -i bfd

CoppSystemBfd              Et16/2                5584344          390904080                  0                  0
CoppSystemBfd              Et51/2              783529888        57981211712            3985376          294917824

After increasing the shape/bandwidth of copp-system-bfd, there is bfd flaps anymore.

  Class-map: copp-system-bfd (match-any)

       shape : 25000 kbps

       bandwidth : 2500 kbps

Arista EOS Lag/ECMP Hashing Features

References/Manual:

• EOS Manual Section 12.4: Load Balancing Hash Algorithms

References/TOI:

• EOS 4.24.2F TOI - Support for dynamic load balancing on ECMP groups (Trident Only)
• EOS 4.22.1F TOI - ECMP Load Balance Profile Support (Sand/Jericho Only)
• EOS 4.21.3F TOI - Symmetric header selection in LAG load-balancing profiles (Jericho Only)
• EOS 4.21.0F TOI - UDF flex hashing improvements (Trident Only)
• EOS 4.20.6F TOI - LAG hashing enhancement for configuring member-selection method (Jericho Only)
• EOS 4.20.5F TOI - LAG hashing on Ingress Interface
• EOS 4.20.5F TOI - Lag Hashing Key Shift
• EOS 4.20.5F TOI - VxLAN over MPLS LAG hashing optimizations for Bridged ports
• EOS 4.20.1F TOI - LAG and ECMP selectable hashing fields (Jericho Only)
• EOS 4.18.0F TOI - Hardware load-balancing for ingress/egress and fabric/egress replication
• EOS 4.17.2F TOI - Configurable field selection for ECMP hash, (Trident Only)
• EOS 4.17.2F TOI - Disable usage of ingress interface in ECMP hashing
• EOS 4.17.1F TOI - Inner IP hashing for MPLSoGRE
• EOS 4.17.0F TOI - Global LAG Hashing Profiles (Jericho Only)
• EOS 4.17.0F TOI - ECMP Hash Visibility
• EOS 4.15.2F TOI - GRE in LAG hash
• EOS 4.15.2F TOI - LAG/ECMP hashing on TTL/Hop Limit
• EOS 4.15.0F TOI - Dynamic and symmetric LAG hashing
• EOS 4.15.0F TOI - Tap aggregation enhancements

Sample: In this below sample, I like to show how to use the above features to fix an ipv6 multicast unbalanced issue. 

Says, in the above topology, there are 2000 ipv6 multicast streams flowing ixia-harness-[vrrp primary| secondary]-nexthop router. Let's see the output of srnz on VRRP primary. 

1) w/o any hashing config, lowest vs highest = 220 vs 317

ghs259-GW2.21:24:15(config-if-Po2)#srnz | grep HUB

Et3/1     GW2-HUB2     0:05       0.0   0.0%        0     220.1   0.2%       35

Et4/1     GW2-HUB2     0:05       0.0   0.0%        0     316.9   0.3%       50

Et13/1    GW2-HUB2     0:05       0.0   0.0%        0     266.1   0.3%       42

Et14/1    GW2-HUB2     0:05       0.0   0.0%        0     269.3   0.3%       43

Po2       GW2-HUB2     0:05       0.0   0.0%        0    1072.3   0.3%      171

2) hash key shift

Let's try 1 hashing feature - Lag Hashing Key Shift. Create a LB profile - mcast-v6 + key shift, apply it globally. 

ghs259-GW2.21:37:22(config)#load-balance policies

ghs259-GW2.21:37:28(config-load-balance-policies)#   load-balance sand profile mcast-v6

ghs259-GW2.21:37:35(config-sand-load-balance-profile-mcast-v6)#      ecmp hash key shift 3

ghs259-GW2.21:37:57(config)#port-channel load-balance sand profile mcast-v6

ghs259-GW2.21:39:50#srnz | grep HUB

Et3/1     GW2-HUB2     0:05       0.0   0.0%        0     220.1   0.2%       35

Et4/1     GW2-HUB2     0:05       0.0   0.0%        0     316.9   0.3%       50

...

Clearly, not much help. 

3) hash seed

ghs259-GW2.21:42:47(config-load-balance-policies)#load-balance sand profile mcast-v6

! profile mcast-v6 is the current global profile

ghs259-GW2.21:42:52(config-sand-load-balance-profile-mcast-v6)#no ecmp hash key shift

ghs259-GW2.21:43:03(config-sand-load-balance-profile-mcast-v6)#ecmp hash seed 1001

ghs259-GW2.21:43:25(config-sand-load-balance-profile-mcast-v6)#end

ghs259-GW2.21:43:36#srnz | grep HUB

Et3/1     GW2-HUB2     0:05       0.0   0.0%        0     220.2   0.2%       35

Et4/1     GW2-HUB2     0:05       0.0   0.0%        0     316.9   0.3%       50

...

4) hash polynomial + Hardware load-balancing for ingress/egress and fabric/egress replication (4.18.0F)

ghs259-GW2.21:45:26(config)#load-balance policies

ghs259-GW2.21:45:30(config-load-balance-policies)#load-balance sand profile mcast-v6

! profile mcast-v6 is the current global profile

ghs259-GW2.21:45:35(config-sand-load-balance-profile-mcast-v6)#no ecmp hash seed 1001

ghs259-GW2.21:45:42(config-sand-load-balance-profile-mcast-v6)#port-channel hash polynomial 5

ghs259-GW2.21:45:43(config-load-balance-policies)#    port-channel load-balance sand replication egress

ghs259-GW2.21:46:52#srnz | grep HUB

Et3/1     GW2-HUB2     0:05       0.0   0.0%        0     265.3   0.3%       42

Et4/1     GW2-HUB2     0:05       0.0   0.0%        0     272.3   0.3%       43

Nice! The hash polynomial works! Actually EOS 8 polynomial functions, the #5 works. 

Understanding the output of "show qos interface eth#"

In this post, I like to explain the output of the EOS command - "show qos interface eth#" based on my understanding from EOS document. 

wa461.00:58:25#sh qos interfaces e17/1
Ethernet17/1:
   Trust Mode: DSCP
   Default COS: 0
   Default DSCP: 0

   Port shaping rate: disabled
   Burst-size: disabled

  Tx    Bandwidth         Shape Rate               Burst-Size          Priority   ECN/WRED
 Queue  (percent)          (units)                  (units)
 ------------------------------------------------------------------------------------------
   7      - / -       - / -          ( - )           -  /  -           SP / SP       D
   6      - / -       - / -          ( - )           -  /  -           SP / SP       D
   5      - / -       - / -          ( - )           -  /  -           SP / SP       D
   4      - / -       - / -          ( - )           -  /  -           SP / SP       D
   3      - / -       - / -          ( - )           -  /  -           SP / SP       D
   2     20 / 20    1.2 / 1.0        (Gbps)     2048 KB / 2048 KB      RR / RR       D
   1     30 / 30      - / -          ( - )           -  /  -           RR / SP       D
   0     50 / 50      - / -          ( - )           -  /  -           RR / SP       D

Note: Values are displayed as Operational/Configured
Legend:
RR -> Round Robin
SP -> Strict Priority
 - -> Not Applicable / Not Configured
 % -> Percentage of line rate

• Values are displayed as Operational/Configured, like RR/SP which means this Q is configured as strict priority but operational as round-robin. 
• If one queue is configured as no priority (RR), then all the lower queues are changed to RR. 
• In this example, Q 2 is RR, then 0 and 1 are automatically changed to RR. 
• And Q 0 and 1 are RR/SP, which means their configuration are SP by default, but operational mode is RR.
• If both interface and tx-queue are configured with shape, which is effective? 
• From EOS manual chapter 27.5 - Enabling port shaping on an FM6000 interface disables queue shaping internally. Disabling port shaping restores queue shaping as specified in running-config.

interface Ethernet17/1
   speed forced 10000full
   !
   tx-queue 0
      bandwidth percent 50
   !
   tx-queue 1
      bandwidth percent 30
   !
   tx-queue 2
      no priority
      bandwidth percent 20
      shape rate 1000000

• Bandwidth vs shape.  
• Bandwidth% is the b/w percent this RR queue can get. Says the above configuration:
• In the sample below, the interface 17/1 is 10 Gbps interface 
• Q3-7 are the strict priority and, say use total 2 Gbps traffic, which left 8Gbps for Q0-2
• The tx-Q 2 can have 20% of left-over capacity which is 1.6Gbps
• But the shape rate is 1.2Gbps
• So the maximum throughput of tx-Q 2 is 1.2 Gbps, even it is assigned with 1.6Gbps.

EOS: A simple Qos design example

This article - "A Simple Quality of Service Design Example" is a very good starting point for understanding the EOS Qos architecture and starting a Qos design. 

Some points:

• 3 ways in the ingress points to map packets to Tx queues:
• qos cos trust + cos-tc map
• qos dscp trust + dscp-tc map
• service-policy + policy-map
• 3 big categories of traffic:
• network-control = control plane
• latency/jitter sensitive traffic
• best-efforts = scavenger traffic
• qos profile = 
• policy-map for input
• tx-queue set for output
• "no priority" in a tx-queue, all lower queues become RR

Support for CPU traffic policy

The default EOS Copp only provides protocol level traffic policy, for example, the maximum throughput of bgp traffic destined to the cpu. But there is no granularity of source address. So this feature - Support for CPU traffic policy is for this purpose. 

Set DSCP value for CPU outbound packets

In Arista EOS, the following protocol packets are able to set a DSCP value other than the default value 0:

• RADIUS, TACACS, SNMP, SSH, and sFlow (feature supported from 4.18.1F)
• NTP, DNS, Syslog, Traceroute, OSPF, and OSPF3 protocols (from 4.22.1F)

Notes:

• The setting must be done individually and under the protocol section
• hostname is not supported. 

For example, setting all locally originated CP packets to DSCP value nc1/cs6/110000/63:

logging qos dscp 48

!

dns qos dscp 48

!

ntp qos dscp 48

!

traceroute qos dscp 48

!

sflow qos dscp 48

！

snmp-server qos dscp 48

！

radius-server qos dscp 48

！

tacacs-server qos dscp 48

！

management ssh

   qos dscp 48

!

router ospf general

   qos dscp 48

EOS: % Not supported when show bgp summary

If you see the error message with EOS command - show bgp <AF> summary, it is probably caused the routing mode. To be more specific, you are probably running ribd mode and the CLI - "show bgp <AF> summary" is only supported in multi-agent mode

ghs259#show bgp ipv6 unicast summary
% Not supported

ghs259-CIN-DPA2.23:32:18#show ip route summary
Operating routing protocol model: ribd
Configured routing protocol model: multi-agent (will apply after next reboot)

Arista EOS - BGP Selective Route Download

 In this post, I will share my experience with a relatively old (was released back in 2015) but very useful Arista EOS feature - BGP Selective Route Download (SRD). 

The use cases are quite straightforward:

• Program the necessary routes on the routers with small hardware resources. In the above TOI link, only 30K prefixes of 520K (back in 2015) cover 99% traffic. The left small traffic can be directed by the default route. 
• Another useful case (for me) is to control what routes be programmed, or even not installed at all. At meanwhile the BGP runs transparently, which processes, receives and advertises the BGP prefixes. A good example is the RR which is not in the data path.  Or hardness router in the lab, it just sends bgp updates. The traffic can be handled by a couple of static routes. 

In the below example, BGP only installs /24 IPv4 routes within 110.0.0/8 range and /64 IPv6 routes in 2000:110:1::/48. 

router bgp 65501

   bgp route install-map part-peer-v46

!

route-map part-peer-v46 permit 10

   match ip address prefix-list part-peer-route

!

route-map part-peer-v46 permit 20

   match ipv6 address prefix-list part-peer-route-v6

!

ip prefix-list part-peer-route seq 10 permit 110.0.0.0/8 eq 24

!

ipv6 prefix-list part-peer-route-v6

    seq 10 permit 2000:110:1::/48 eq 64

bn309#show ip route summary

...

VRF: default

   Route Source                                Number Of Routes

------------------------------------- -------------------------

...

   ospfv3                                                     0

   bgp                                                     1814

     External: 1814 Internal: 0

...

   Total Routes                                            1871

Number of routes per mask-length:

   /8: 2         /12: 2        /16: 1        /24: 1816     /25: 1

   /30: 7        /32: 42

bn309#show ip bgp installed | egrep '^ \* ' | wc -l

1816

At this time actually, this router receives/accepts over 1.4M prefixes. 

bn309#show ip bgp summary

BGP summary information for VRF default

Router identifier 192.168.230.2, local AS number 65501

Neighbor Status Codes: m - Under maintenance

  Description              Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc

  IpTransit#1-7504         100.101.1.1      4  12083          44303    119708    0    0 01:08:12 Estab   690049 690049

  Local-Aris-Simu          192.168.230.1    4  65510         129394         5    0    0 01:03:57 Estab   819857 819857

As of August 2020, this feature is only supported on RIBD (so multi-agent mode doesn't work)

EOS: alias to sum up total num of received bgp prefixes

EOS-R1#show ip bgp neighbors 

BGP neighbor is 100.101.1.2, remote AS 100, external link

  Prefix Statistics:

                                   Sent      Rcvd     Best Paths     Best ECMP Paths

    IPv4 Unicast:                688000    818876         808929                   0

    IPv6 Unicast:                     0         0              0                   0

If we like to know the total number of rcvd prefix from all bgp peers, here is the alias command could be useful

alias totbgp show ip bgp neighbors | grep "IPv4 Unicast: \s\s" | awk  '{s+=$4}END{print s}'

EOS-R1#totbgp

6001256

EOS: sum up and compare in/egress throughput

Sometimes you want to compare the ingress/egress throughput on a particular router to see if any possible traffic loss (of course, the loss should be large enough like 3% more).  On EOS, srnz (alias srnz Show interface counters rates | nz) is a good alias. But if incoming or outgoing on multiple ports, you have to sum up and compare.

Here is a couple of useful tips and commands.

bn309#srnz
Port      Name        Intvl   In Mbps      %  In Kpps  Out Mbps      % Out Kpps
Et9/1/1   ixia:LC8     0:05       0.0   0.0%        0   13435.8  35.0%     3543
Et9/2/1   ixia:LC8     0:05       0.0   0.0%        0   13435.3  35.0%     3543
...
Et11/6/1  ixia:LC7     0:05   13433.7  35.0%     3543       0.0   0.0%        0
Et11/11/1 ixia:LC7     0:05   13433.7  35.0%     3543       0.0   0.0%        0
Et11/12/1 ixia:LC7     0:05   13434.6  35.0%     3543       0.0   0.0%        0
Et11/13/1 ixia:LC7     0:05   13432.3  35.0%     3543       0.0   0.0%        0
Et11/14/1 ixia:LC7     0:05   13434.4  35.0%     3543       0.0   0.0%        0
Et11/15/1 ixia:LC7     0:05   13434.3  35.0%     3543       0.0   0.0%        0
Et11/16/1 ixia:LC7     0:05   13433.9  35.0%     3543       0.0   0.0%        0

In the above example, you want to compare ingress from ixia:LC7 and egress of ixia:LC8

bn309#srnz | grep LC7 | awk '{s+=$4}END{print s}'
161206  <<< ingress
bn309#srnz | grep LC8 | awk '{s+=$7}END{print s}'
161198  <<< egress

"no-internal-vlan" error for routed interfaces

Creating several L3 routed port-channels and sub-interfaces, but they failed to come up with errdisabled status. The output "show interface status err" displays the following reasons:

yo411.16:22:08(config-if-Po1201)#show int status errdisabled
   Port           Name             Status         Reason
-------------- ---------------- ----------------- ---------------------
   Et3/12/1                        errdisabled    port-channel-shutdown
   Et4/12/1                        errdisabled    port-channel-shutdown
   Po1201.3                        errdisabled    no-internal-vlan
   Po1201.2                        errdisabled    no-internal-vlan
   Po1201                          errdisabled    no-internal-vlan

Basically, the "port-ch-shutdown" error was caused by the Po1201 being down. Checked the EOS document, the system will reserve an internal VLAN for any "no switchport" interfaces. And the internal VLAN ranges start from 1006 to 4094 (ref: EOS Manual section 19.4.3)

yo411.16:22:59(config-if-Po1201)#show vlan internal usage
1006  Port-Channel1900.4002
1007  Ethernet3/36/3
1008  Port-Channel1900
1009  Ethernet3/36/1
1010  Port-Channel1900.4003
1011  Ethernet3/36/4
1012  Ethernet3/36/2
1013  Ethernet3/36/4.2
1014  Ethernet3/36/4.3

And internal VLAN assignment stops at 1015. 

yo411.16:23:23(config-if-Po1201)#sh vlan 1015
VLAN  Name                             Status    Ports
----- -------------------------------- --------- -------------------------------
1015  VLAN1015                         suspended

So the root cause is that there is an accidental configuration of vlan 1015 with a suspended state, and this blocks the internal VLAN assignment. 

yo411.16:24:19(config)#no vlan 1006 - 1099
yo411.16:24:36(config)#sh int status errdisabled

After removing the VLAN configuration, there is no internal-VLAN error anymore. 

yo411.16:24:47(config)#show vlan internal usage
...
1015  Port-Channel1201.2
1016  Port-Channel1201.3
1017  Port-Channel1201

Another way is to specify the internal VLAN range to an unused space (ref: EOS manual section 21.3) 

yo411(config)# vlan internal order descending range 4000 4094

Arista EVPN VXLAN Configuration Example (3c) - Single-homing, L3 EVPN, Symmetric IRB

One of the purposes of symmetric IRB is to address the scale issue of asymmetric IRB solution. And here is the list of differences compared with asymmetric IRB:

• VTEPs only need to hold the VLANs and SVIs of directly connected subnets
• An intermediate IP-VRF to carry the remote subnets

Arista EVPN VXLAN Configuration Example (3b) - Single-homing, L3 EVPN, Asymmetric IRB

To solve the sub-optimal routing pattern in the solution of centralized routing, the IRB EVPN Draft proposes 2 solutions, asymmetric IRB and symmetric IRB. Because the local VTEP does both inter-VLAN routing and intra-VLAN switching, it is called IRB (Integrated Routing and Bridging).

The asymmetric IRB is illustrated as below



Explanations:

• VTEP on has 1 directly connected VLAN:
• VTEP1 - VLAN 641
• VTEP2 - VLAN 642
• But the VTEPs must have
• 2 x SVI interface, VLAN 641 and 642
• 2 x VLANs under MAC VRF
• 2 x VLAN/VNI bindings under Vxlan interfce
• Routing is performed on the ingress VTEP, and egress VTEP only decapsulates the Vxlan header and switches into destination VLANs. 
• The returning traffic does the same, so routing is done on different VTEPs, hence the term Asymmetric IRB
• Advantage:
• Optimal traffic path and no traffic trombone 
• Disadvantage:
• VTEPs must have all SVIs and VLANs configured, even not locally connected. 
• That means ALL VTEPs hold ALL MAC and ARP of hosts for source and destination VLANs. 
• So the scale is the biggest issue. To make things worse, TOR devices normally don't much high capacity.  

From the below output, the VTEP1 has 6 ARP entries, 3 local VLANs and 3 remote VLANs

snp261-eVtep1.23:11:00#sh arp

Address         Age (sec)  Hardware Addr   Interface

160.64.1.101      0:02:54  444c.a8a5.1140  Vlan641, Ethernet78

160.64.1.102      0:01:08  444c.a8a5.1140  Vlan641, Ethernet78

160.64.1.103      0:01:04  444c.a8a5.1140  Vlan641, Ethernet78

160.64.2.201            -  444c.a8a5.1141  Vlan642, Vxlan1

160.64.2.202            -  444c.a8a5.1141  Vlan642, Vxlan1

160.64.2.203            -  444c.a8a5.1141  Vlan642, Vxlan1

Arista EVPN VXLAN Configuration Example (3a) - Single-homing, L3 EVPN, Centralized Routing

In traditional DC design, the most common inter-VLAN routing is centralized routing, and illustrated as below, 



Explanation:

• A dedicated router - up506/cenRtr is used to route the traffic between vlans;
• All gateway SVIs on the cenRtr
• Advantages:
• Low resource requirement on VTEPs, which only need to know how to reach gateway. So fewer MAC and no ARP
• Easy managed. 
• Disadvantages:
• Sub-optimal traffic flow. 
• Single point failure

Control Plane Check-up:

1. IMET:

On centralized router, under vlan 631, only 2 VTEPs - local and VTEP1

up506-CentRtr#show bgp evpn route-type imet vni 631
          Network                Next Hop              Metric  LocPref Weight  Path
 * >     RD: 160.255.255.10:630 imet 631 160.255.255.10
                                160.255.255.10        -       100     0       i Or-ID: 160.255.255.10 C-LST: 180.255.255.1
 * >     RD: 160.255.255.20:630 imet 631 160.255.255.100
                                -                     -       -       0       i

Similarly, under vlan 632, only 2 VTEPs - local and VTEP2

up506-CentRtr#show bgp evpn route-type imet vni 632
          Network                Next Hop              Metric  LocPref Weight  Path
 * >     RD: 160.255.255.20:630 imet 632 160.255.255.20
                                160.255.255.20        -       100     0       i Or-ID: 160.255.255.20 C-LST: 180.255.255.1
 * >     RD: 160.255.255.20:630 imet 632 160.255.255.100
                                -                     -       -       0       i

2. MAC-IP:

up506-CentRtr#show bgp evpn route-type mac-ip vni 631
          Network                Next Hop              Metric  LocPref Weight  Path
 * >     RD: 160.255.255.10:630 mac-ip 631 444c.a8a5.1140
                                160.255.255.10        -       100     0       i Or-ID: 160.255.255.10 C-LST: 180.255.255.1

up506-CentRtr#show bgp evpn route-type mac-ip vni 632
          Network                Next Hop              Metric  LocPref Weight  Path
 * >     RD: 160.255.255.20:630 mac-ip 632 444c.a8a5.1141
                                160.255.255.20        -       100     0       i Or-ID: 160.255.255.20 C-LST: 180.255.255.1

Ping check-up:

Host1#ping vrf EvpnHost1 160.63.2.202
PING 160.63.2.202 (160.63.2.202) 72(100) bytes of data.
80 bytes from 160.63.2.202: icmp_seq=1 ttl=63 time=0.157 ms
80 bytes from 160.63.2.202: icmp_seq=2 ttl=63 time=0.112 ms
80 bytes from 160.63.2.202: icmp_seq=3 ttl=63 time=0.144 ms
80 bytes from 160.63.2.202: icmp_seq=4 ttl=63 time=0.106 ms
80 bytes from 160.63.2.202: icmp_seq=5 ttl=63 time=0.133 ms

--- 160.63.2.202 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/0.130/0.157/0.021 ms, ipg/ewma 0.156/0.143 ms

Arista EVPN VXLAN Configuration Example (2c) - Single-homing, L2 EVPN, Vlan-aware vs Vlan-based

According to draft-krattiger-evpn-modes-interop-0, the vlan-based should interop with vlan-aware bundled MAC VRF. But I did a quick test on 4.24.0F EOS, it doesn't work obviously



And the problem is that, flood set is not correct.

snp261#sh l2rib input bgp floodset
L2 RIB EVPN Input flood set:
   Vlan              Address       Type            Destination
---------- -------------------- ---------- -------------------
    601       0000.0000.0000        All    VTEP 160.255.255.20
    602       0000.0000.0000        All    VTEP 160.255.255.20
    611       0000.0000.0000        All    VTEP 160.255.255.20
    612       0000.0000.0000        All    VTEP 160.255.255.20
<<<< there is no VTEP flood set for VLAN 621 and 622

Even the "show bgp evpn route-type imet <prefix>" shows correct RT values, the but import doesn't work here. 

wa464#sh bgp evpn route-type imet rd 160.255.255.10:621 detail

BGP routing table information for VRF default

Router identifier 160.255.255.20, local AS number 65162

BGP routing table entry for imet 160.255.255.10, Route Distinguisher: 160.255.255.10:621

 Paths: 1 available

  Local

    160.255.255.10 from 160.255.255.1 (180.255.255.1)

      Origin IGP, metric -, localpref 100, weight 0, valid, internal, best

      Originator: 160.255.255.10, Cluster list: 180.255.255.1

      Extended Community: Route-Target-AS:65100:620 TunnelEncap:tunnelTypeVxlan

      VNI: 621

      PMSI Tunnel: Ingress Replication, MPLS Label: 621, Leaf Information Required: false, Tunnel ID: 160.255.255.10

Arista EVPN VXLAN Configuration Example (2b) - Single-homing, L2 EVPN, Vlan-aware

The VLAN-based MAC VRF has RD/RT values per VLAN/VNI. But most of the time, one tenant customer uses multiple VLANs. In this case, we can use just 1 RD/RT to mark the EVPN routes, which is called VLAN-aware bundle MAC VRF, and is illustrated as below:



Explanations:

• Configuration is much like the VLAN-based MAC VRF
• Configure VLAN-aware MAC-VRF under router BGP with RD/RT and it can have multiple VLANs
• "redistribute learned" is to advertised the learnt MAC under VLAN as type-2 routes to remote EVPN peers.
• Under interface Vxlan 1, configure VNI values for above VLANs

Control Plane Check-up:

1. IMET, almost same as VLAN-based, but under 1 RD/RT with 2 VNIs/VTEP

snp261-eVtep1#sh bgp evpn route-type imet rd 160.255.255.20:610 detail
BGP routing table information for VRF default
Router identifier 160.255.255.10, local AS number 65161
BGP routing table entry for imet 611 160.255.255.20, Route Distinguisher: 160.255.255.20:610
 Paths: 1 available
  Local
    160.255.255.20 from 160.255.255.1 (180.255.255.1)
      Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
      Originator: 160.255.255.20, Cluster list: 180.255.255.1
      Extended Community: Route-Target-AS:65100:610 TunnelEncap:tunnelTypeVxlan
      VNI: 611
      PMSI Tunnel: Ingress Replication, MPLS Label: 611, Leaf Information Required: false, Tunnel ID: 160.255.255.20
BGP routing table entry for imet 612 160.255.255.20, Route Distinguisher: 160.255.255.20:610
 Paths: 1 available
  Local
    160.255.255.20 from 160.255.255.1 (180.255.255.1)
      Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
      Originator: 160.255.255.20, Cluster list: 180.255.255.1
      Extended Community: Route-Target-AS:65100:610 TunnelEncap:tunnelTypeVxlan
      VNI: 612
      PMSI Tunnel: Ingress Replication, MPLS Label: 612, Leaf Information Required: false, Tunnel ID: 160.255.255.20

2. MAC-IP, under 1 RD/RT, but 2 VNI for 2 VLANs

snp261-eVtep1#sh bgp evpn route-type mac-ip rd 160.255.255.20:610 detail
BGP routing table information for VRF default
Router identifier 160.255.255.10, local AS number 65161
BGP routing table entry for mac-ip 611 444c.a8a5.1141, Route Distinguisher: 160.255.255.20:610
 Paths: 1 available
  Local
    160.255.255.20 from 160.255.255.1 (180.255.255.1)
      Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
      Originator: 160.255.255.20, Cluster list: 180.255.255.1
      Extended Community: Route-Target-AS:65100:610 TunnelEncap:tunnelTypeVxlan
      VNI: 611 ESI: 0000:0000:0000:0000:0000
BGP routing table entry for mac-ip 612 444c.a8a5.1141, Route Distinguisher: 160.255.255.20:610
 Paths: 1 available
  Local
    160.255.255.20 from 160.255.255.1 (180.255.255.1)
      Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
      Originator: 160.255.255.20, Cluster list: 180.255.255.1
      Extended Community: Route-Target-AS:65100:610 TunnelEncap:tunnelTypeVxlan
      VNI: 612 ESI: 0000:0000:0000:0000:0000

Ping check-up:

Host1#ping vrf EvpnHost1 160.61.1.201
PING 160.61.1.201 (160.61.1.201) 72(100) bytes of data.
80 bytes from 160.61.1.201: icmp_seq=1 ttl=64 time=0.790 ms
80 bytes from 160.61.1.201: icmp_seq=2 ttl=64 time=0.134 ms
80 bytes from 160.61.1.201: icmp_seq=3 ttl=64 time=0.102 ms
80 bytes from 160.61.1.201: icmp_seq=4 ttl=64 time=0.107 ms
80 bytes from 160.61.1.201: icmp_seq=5 ttl=64 time=0.117 ms

--- 160.61.1.201 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 0.102/0.250/0.790/0.270 ms, ipg/ewma 1.000/0.510 ms

Host2#ping vrf EvpnHost1 160.61.2.201
PING 160.61.2.201 (160.61.2.201) 72(100) bytes of data.
80 bytes from 160.61.2.201: icmp_seq=1 ttl=64 time=0.884 ms
80 bytes from 160.61.2.201: icmp_seq=2 ttl=64 time=0.105 ms
80 bytes from 160.61.2.201: icmp_seq=3 ttl=64 time=0.106 ms
80 bytes from 160.61.2.201: icmp_seq=4 ttl=64 time=0.097 ms
80 bytes from 160.61.2.201: icmp_seq=5 ttl=64 time=0.096 ms

--- 160.61.2.201 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 0.096/0.257/0.884/0.313 ms, ipg/ewma 1.001/0.559 ms