3/30/2018

BGP session by loopback vs combo static route

Topology:



Configuration:

Says, in the above topology, there is 2 eBGP sessions:

Between R0 and R1, eBGP session is by loopback address 10.255.255.1 and 10.255.255.2 respectively. No IGP involved, to make it work, we have the following configurations:

On R0:
ip route 10.255.255.1/32 10.0.1.1 ! 10.0.1.1 = R1's intf ip address
ip route 10.255.255.1/32 10.0.1.3 ! 10.0.1.3 = R1's intf ip address
!
router bgp 65000
   maximum-paths 128
   neighbor 10.255.255.1 remote-as 65001
   neighbor 10.255.255.1 ebgp-multihop 2

And between R0 and R2, there is an eBGP session. Also R2 advertises a prefix of 10.0.1.0/24, which is the supernet of 10.0.1.0/31

BGP sessions are all up w/o any issues. 

R0(s2)(config)#sh ip bgp sum
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State  PfxRcd PfxAcc
  10.0.2.1         4  65002            202       201    0    0 03:11:40 Estab  1      1
  10.255.255.1     4  65001           1867      1887    0    0 01:31:06 Estab  0      0

Issue:

Now, let's disable 1 of 2 back-to-back connections between R0 and R1. And eBGP session between R0 and R1 is down! even the 2nd connection is of no problem. 

R0(s2)(config)#int e6/45
R0(s2)(config-if-Et6/45)#shu
R0(s2)(config-if-Et6/45)#sh ip bgp sum
BGP summary information for VRF default
Router identifier 72.129.223.37, local AS number 65000
Neighbor Status Codes: m - Under maintenance
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State  PfxRcd PfxAcc
  10.0.2.1         4  65002            205       204    0    0 03:14:06 Estab  1      1
  10.255.255.1     4  65001           1914      1933    0    0 00:00:05 Connect

Why? It is because the route to 10.255.255.1 pointing to unexpected interface

R0(s2)(config-if-Et6/45)#sh ip route 10.255.255.1
.......
 S      10.255.255.1/32 [1/0] via 10.0.2.1, Ethernet6/9 ! R0/R2 intf
                              via 10.0.1.3, Ethernet6/46

Remember the static route we created above
ip route 10.255.255.1/32 10.0.1.1 ! 10.0.1.1 = R1's intf ip address

R0(s2)(config-if-Et6/45)#sh ip route 10.0.1.1
 B E    10.0.1.0/24 [200/0] via 10.0.2.1, Ethernet6/9 ! 

Ok, the reason is because, the static route 10.0.1.0/31 is gone after shutting down interface. Then the eBGP route from R2 kicks in and now NH 10.0.1.1 points to R2 after recursive lookup. And it builds an incorrect 2-way ECMP between 10.255.255.1 and 10.255.255.2, which creates a 50% chance of dropping packets. Then BGP is down. 

Workaround/Solution:

To solve this issue, we need to use combo static routes to specify the NH and egress interfaces, like:

R0(s2)(config)#sh run | grep 10.255.255.1
ip route 10.255.255.1/32 Ethernet6/45 10.0.1.1
ip route 10.255.255.1/32 Ethernet6/46 10.0.1.3

R0(s2)(config)#int e6/45
R0(s2)(config-if-Et6/45)#shu
R0(s2)(config-if-Et6/45)#sh ip route 10.255.255.1
 S      10.255.255.1/32 [1/0] via 10.0.1.3, Ethernet6/46

Details of "combo" static route



3/27/2018

Trident Platform: route not hw programmed

If you see some v4 or v6 routes not hw programmed in the output of "show ip route", you may need to try to adjust hardware routing-table partition. 

ck494.17:37:15.(config)#platform trident routing-table partition ?
  1  16K IPv4, 6K IPv6 ( prefix len up to /64 ), 1K IPv6 ( any prefix length )
  2  16K IPv4, 4K IPv6 ( prefix len up to /64 ), 2K IPv6 ( any prefix length )
  3  16K IPv4, 2K IPv6 ( prefix len up to /64 ), 3K IPv6 ( any prefix length )
  4  16K IPv4, 0K IPv6 ( prefix len up to /64 ), 4K IPv6 ( any prefix length )

3/21/2018

How many ACLs can fit into Arista 7508E? (1)

About this post:
In this blog, I will discuss and sample number of ACLs can be programmed on an Arista Arad-based DCS-7508E system. 

System/Interface:
7508E(s1)(config-if-Et3/1/1)#show module
Module  Ports Card Type                       Model         Serial No.
------- ----- ------------------------------- ------------- -----------
1       3     DCS-7500E-SUP Supervisor Module DCS-7500E-SUP JPE13493743
2       3     DCS-7500E-SUP Supervisor Module DCS-7500E-SUP JPE15498473
3       144   36 port 40GbE QSFP+ Linecard    7500E-36Q-LC  JPE13874943
4       144   36 port 40GbE QSFP+ Linecard    7500E-36Q-LC  JPE13493196

List of contents:
1) Overview of Arista LC/Arad/TCAM banks
2) System starts with zero configuration. 
3) I will configure v4/v6 ACL on eth3/13/1 ~ 3/18/4, which are under Arad3/2
4) And check output of "show platform arad..." to monitor the TCAM usage

1. Overview of Arista LC/Arad/TCAM banks

Arista 7500E series is an Arad based switch. Each Arista 7500E-36Q-LC has 6 Arad ASICs, so each chip stands behind 6 QSFP or 24 ethernet interfaces. For example, Arad3/2 maps to eth ports, Et3/13/1 - 3/18/4

7508E(s1)#show platform arad Arad3/2 mapping
Arad3/2 (FapId: 2  BaseSystemCoreId: 2)
            Port                SysPhyPort   Voq Core FapPort OtmPort QPairs Xlge NifPort Qsgmii  Serdes
------------------------------------------------------------------------------------------------------------------
.....
            Ethernet3/13/1             140  4064    0       2       0      8    5      20      -  (20)
            Ethernet3/13/2             141  4072    0       3       8      8    -      21      -  (21)
.....
            Ethernet3/18/4             163  4248    0      25     184      8    -      11      -  (11)

And each Arad has 14 TCAM banks, 12 (#0-11) full-size 1K (160-bit entries), 2  (#12, 13) smaller (256x160-bit entries) for system-use only

7508E(s1)(config)#show platform arad Arad3/2 tcam summary
           Tcam Allocation (Arad3/2)
   Bank                   Used By    Reserved By
---------- ------------------------- -----------
      0                   dbPdpIp              -
      0               dbPdpTunnel              -
      0                dbPdpNonIp              -
      0                  dbPdpIp6              -
      0                 dbPdpMpls              -
      1         dbIp6UcastRouting              -
      2         dbIp6UcastRouting              -
      3                    dbVTT0              -
      4          dbIpMcastRouting              -
     12                 dbSystem6              -
     12              dbMplsSystem              -
     12                  dbSystem              -
     12       dbTunnelTermination              -
     13            dbEgressSystem              -

Each bank can hold 1024 TCAM lines. So per Arad can hold total ~12K ACL rule lines in theory. BUT....from above output of "tcam summary", 5 banks (0 ~ 4) are used by Pdp, ipv6 routing, VTT (vlan translation t?) and ipv4 multicast. 

In the Bank 0, there is some pdp** rules enabled, which are the default port-base CoPP policy map. And the bank usage is exclusive, so 2 types of TCAM applications can't share bank. Even the PDP is quite small, we can't squeeze other ACLs into this bank.  

7508E(s1)#show platform arad Arad3/2 acl tcam summary
The total number of TCAM lines per Arad bank is 1024
========================================================
Arad3/2:
========================================================
   Bank   Used           Used %          Used By
      0     74                7 Pdp IP, Pdp Tunnel, Pdp NonIp, Pdp IPv6, Pdp Mpls
Total Number of TCAM lines used is: 74

After all of these, there is slightly less than 7K lines left. But there is several questions need to be addressed before answering the question in the subject line. 
1) Are these ACL rule lines be shared by multiple ports? ethernet or port-ch?
2) How many TCAM lines are consume for v4, v6, MAC, L4 rule?
3) How about the ACL under VLAN(SVI) interfaces?

I will figure them out in later parts. 

Step 1: configure ipv4 ACL with 1 rule on 1 eth/routed port

7508E(s1)(config)#ip access-list v4-Acl-1-rule
7508E(s1)(config-acl-v4-Acl-1-rule)#permit ip 192.168.1.0/24 any
7508E(s1)(config-acl-v4-Acl-1-rule)#int et3/13/1
7508E(s1)(config-if-Et3/13/1)#ip access-group v4-Acl-1-rule in

The new ipv4 ACL is programmed into TCAM bank 5. (bank 0 - 4 are already used)

7508E(s1)#sh platform arad Arad3/2 tcam summary
           Tcam Allocation (Arad3/2)
   Bank                   Used By    Reserved By
---------- ------------------------- -----------
      0                   dbPdpIp              -
....
      3                    dbVTT0              -
      4          dbIpMcastRouting              -
      5                  dbIpPacl              -
....

And it takes 2 entries. Why 2 entries? It is because there is 1 default deny any any at the end. 

7508E(s1)#sh platform arad Arad3/2 acl tcam summary
Arad3/2:
   Bank   Used           Used %          Used By
      5      2                0         IP PACLs
      0     74                7 Pdp IP, Pdp Tunnel, Pdp NonIp, Pdp IPv6, Pdp Mpls
Total Number of TCAM lines used is: 76

Similar contents from the o/p of "show plat arad <id> acl tcam detail"

7508E(s1)#sh platform arad Arad3/2 acl tcam detail | more
ip access-list v4-Acl-1-rule (PACL, 1 rules, 2 entries, direction in, state success)
  Fap: Arad3/2, Shared: true, Interfaces: Et3/13/1
  Bank Offset Entries
     5      0       2

Step 2: add one more line to same ipv4 ACL 

7508E(s1)(config)#ip access-list v4-Acl-1-rule
7508E(s1)(config-acl-v4-Acl-1-rule)#perm ip 10.0.0.0/8 any
7508E(s1)(config-acl-v4-Acl-1-rule)#end
7508E(s1)#sh platform arad Arad3/2 acl tcam summary
Arad3/2:
   Bank   Used           Used %          Used By
      5      3                0         IP PACLs
      0     74                7 Pdp IP, Pdp Tunnel, Pdp NonIp, Pdp IPv6, Pdp Mpls
Total Number of TCAM lines used is: 77

7508E(s1)#sh ip access-lists v4-Acl-1-rule
IP Access List v4-Acl-1-rule
        10 permit ip 192.168.1.0/24 any
        20 permit ip 10.0.0.0/8 any

So, for the ipv4 ACL, it takes rule + 1 TCAM lines

Step 3: apply same ipv4 ACL to another eth port under same ASIC

7508E(s1)#sh ip access-lists v4-Acl-1-rule summary
IPV4 ACL v4-Acl-1-rule
        Total rules configured: 2
        Configured on Ingress: Et3/13/1
        Active on     Ingress: Et3/13/1
7508E(s1)(config)#int et3/13/2

7508E(s1)(config-if-Et3/13/2)#ip access-group v4-Acl-1-rule in

7508E(s1)#sh ip access-lists v4-Acl-1-rule summary
IPV4 ACL v4-Acl-1-rule
        Total rules configured: 2
        Configured on Ingress: Et3/13/1-2
        Active on     Ingress: Et3/13/1-2

7508E(s1)#sh platform arad Arad3/2 acl tcam detail | more
ip access-list v4-Acl-1-rule (PACL, 2 rules, 3 entries, direction in, state success)
  Fap: Arad3/2, Shared: true, Interfaces: Et3/13/1, Et3/13/2
  Bank Offset Entries

     5      0       3

From the above output, we can see if the same ACL applied to other eth ports under same Asic, the rule entries are shared. 

Step 4: configure a 1-line ipv6 ACL 

7508E(s1)(config)#ipv6 access-list v6-Acl-1
7508E(s1)(config-ipv6-acl-v6-Acl-1)#perm ipv6 2000::192:168:1/120 any
7508E(s1)(config-ipv6-acl-v6-Acl-1)#int e3/13/1
7508E(s1)(config-if-Et3/13/1)#ipv6 en
7508E(s1)(config-if-Et3/13/1)#ipv6 address 2000::192:168:1:1/120
7508E(s1)(config-if-Et3/13/1)#ipv6 access-group v6-Acl-1 in
7508E(s1)(config-if-Et3/13/1)#sh ipv6 access-lists v6-Acl-1 summary
IPV6 ACL v6-Acl-1
        Total rules configured: 1
        Configured on Ingress: Et3/13/1
        Active on     Ingress: Et3/13/1

7508E(s1)(config-if-Et3/13/1)#sh platform arad Arad3/2 tcam summary
           Tcam Allocation (Arad3/2)
   Bank                   Used By    Reserved By
---------- ------------------------- -----------
....
      5                  dbIpPacl              -
      6                 dbIp6Pacl              -
      7                 dbIp6Pacl              -
....

7508E(s1)(config-if-Et3/13/1)#sh platform arad Arad3/2 acl tcam summary
Arad3/2:
   Bank   Used           Used %          Used By
      5      3                0         IP PACLs
   6, 7      6                0       IPv6 PACLs
      0     74                7 Pdp IP, Pdp Tunnel, Pdp NonIp, Pdp IPv6, Pdp Mpls

Total Number of TCAM lines used is: 89

Now, we know v6 ACL take more TCAM resources than v4:
1) Occupies 2 banks instead of 1 since the length of address;
2) Uses 6 lines for 1-line v6 ACL, because it needs 4 lines of ICMPv6 for neighbor discovery, plus 1 line of default deny all

Step 5: add 1 more line to v6 ACL

7508E(s1)(config)#ipv6 access-list v6-Acl-1
7508E(s1)(config-ipv6-acl-v6-Acl-1)#perm ipv6 2000::10:0:0/120 any
7508E(s1)(config-ipv6-acl-v6-Acl-1)#end
7508E(s1)#sh platform arad Arad3/2 acl tcam summary
Arad3/2:
   Bank   Used           Used %          Used By
      5      3                0         IP PACLs
   6, 7      7                0       IPv6 PACLs
      0     74                7 Pdp IP, Pdp Tunnel, Pdp NonIp, Pdp IPv6, Pdp Mpls
Total Number of TCAM lines used is: 91

Ok, IPv6 ACLs 
1) take 2 continuous banks
2) consume 1 line per rule; plus 5 rules for default rules

Step 6: apply same ACL to another ethernet

7508E(s1)(config)#interface Ethernet3/13/2
7508E(s1)(config-if-Et3/13/2)#ipv en
7508E(s1)(config-if-Et3/13/2)#ipv6 address 2000::192:168:2:1/120
7508E(s1)(config-if-Et3/13/2)#   ipv6 access-group v6-Acl-1 in

7508E(s1)#sh ipv6 access-lists summary
....
IPV6 ACL v6-Acl-1
        Total rules configured: 2
        Configured on Ingress: Et3/13/1-2
        Active on     Ingress: Et3/13/1-2

7508E(s1)#sh platform arad Arad3/2 acl tcam detail | more
......
ipv6 access-list v6-Acl-1 (PACL, 2 rules, 7 entries, direction in, state success)
  Fap: Arad3/2, Shared: true, Interfaces: Et3/13/1, Et3/13/2
  Bank Offset Entries
  6, 7      0       7

7508E(s1)#sh platform arad Arad3/2 acl tcam sum
Arad3/2:
      5      3                0         IP PACLs
   6, 7      7                0       IPv6 PACLs
      0     74                7 Pdp IP, Pdp Tunnel, Pdp NonIp, Pdp IPv6, Pdp Mpls

Summary
1. ACL limitation is by Arad Chip
2. Each Arad chip is equipped with 12 TCAM banks and each holds 1K lines;
3. v4 ACL takes 1 bank and v6 uses 2
4. 1 ACL rule = 1 TCAM line
5. Same ACL applied on different ports can share TCAM lines

3/09/2018

Arista EOS - BGP, update wait-for-convergence

Feature Name: 
BGP Update Wait-for-convergence

Purpose: 
"basically prevents BGP from programming routes into hardware and from advertising routes until a convergence event is resolved". The benefit of this feature is to reduce CPU/hw programming churn during convergence event

Reference:
http://aspiringnetworker.blogspot.com/2015/08/bgp-in-arista-data-center_90.html

Use case: 
For example on the spine routers, they have 128-way ECMP and multiple BGP sessions to neighbor routers. During convergence event, it could receive routing information piece by piece depending on how fast and the order of underlying physical interfaces become up. So this feature is to hold BGP prefix programming until the control plane is converged. 

What's the convergence event:
  • Router reload, bgp first time to start
  • BGP clear
  • Rib agent restart, etc
How does it work?
  • When BGP enters to converge, it will exit in 1 of 3 conditions
    • ALL BGP peers converge
    • Convergence timeout - default 5 min
    • Slow peer timeout - default 1 min 30 sec
  • ALL BGP peers are converged if 
    • Neighbor established, and
    • Receive a End-of-Rib or BGP KA if GR not enabled, 
    • The following cases will slow or stop the convergence process, so need 2 timers
      • If 1 neighbor has big tables to convey 
      • If there is a dead neighbor, configured but never up
      • If dynamic peer is configured
  • Slow peer timeout
    • default 1:30 after the first bgp neighbor up
  • BGP convergence timer out:
    • Default is 5 min
    • Can be changed by "bgp convergence time xxx (sec)"
R2.15:01:44(config-router-bgp)#sh bgp convergence
BGP Convergence information for VRF: default
Configured convergence timeout: 00:05:00
Configured convergence slow peer timeout: 00:01:30
Convergence based update synchronization is enabled
Last Bgp convergence event 00:01:41 ago
Bgp convergence state : Timeout reached
   Time taken to converge 00:01:30
   First peer came up 00:01:41 ago
   Pending Peers:          1
       Total Peers:        3
       Established Peers:  2
       Disabled Peers:     0
   Peers that did not converge before local bgp convergence:
       IPv4 peers:
           24.24.24.4            (Session : Active)
       IPv6 peers:
           None


Limitation:
While this feature makes a big sense on spine, but DO NOT enable it on TOR/Leaf or First Hop switches. 

For example:
       [ebgp]
       /     \(uplink)
 [mlagA]=====[mlagB]
       \     /
     [server pool]


Say in above a common mlag setup. 
  1. mlagB reboots, then all uplink, downlink and peerlink all down 
  2. The peerlink between mlagA and mlagB is up (fast before mlag reload delay). 
  3. iBGP between mlagA and B is up, B receives routes from A
  4. But at this time, the ebgp via uplink still down, so these iBGP prefixes will be hold!!
  5. the downlink(mlag port-ch) are up, servers start to forward traffic, then all the traffic are dropped at floor. 
Sample configuration:
router bgp 65500
   update wait-for-convergence
   update wait-install

Sample Topology:

[R1] <----1.1.1.0/24 prefix
 |
 | (ebgp)
 |
[R2]--(ibgp)--- [R4] <--- dead neighbor
 |
 | (ebgp)
 |
[R3]

1) we shut down the ebgp session between R2 and R4, which simulate a "dead" neighbor

! bgp prefix 1.1.1.0/24 in and best path is selected
R2.15:25:34(config-router-bgp)#sh ip bgp 1.1.1.0
BGP routing table information for VRF default
Router identifier 110.255.255.1, local AS number 2
BGP routing table entry for 1.1.1.0/24
 Paths: 1 available
  1
    12.12.12.1 from 12.12.12.1 (130.255.255.100)
      Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:01:55 ago, valid, external, best
      Rx SAFI: Unicast

! 1.1.1.0/24 in RIB
R2.15:25:49(config-router-bgp)#sh ip route 1.1.1.0
 B E    1.1.1.0/24 [200/0] via 12.12.12.1, Ethernet3/36/1

2) Now do a hard clear on R2

R2.15:26:58(config-router-bgp)#clear ip bgp *
! Clearing all IPv4 and IPv6 peering sessions

! bgp sessions up except the dead neigh - 24.24.24.4
R2.15:27:06(config-router-bgp)#bas
BGP summary information for VRF default
Router identifier 110.255.255.1, local AS number 2
Neighbor Status Codes: m - Under maintenance
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State  PfxRcd PfxAcc
  12.12.12.1       4  1                 82        84    0    0 00:00:09 Estab  1      1
  23.23.23.3       4  3                 73        91    0    0 00:00:09 Estab  0      0
  24.24.24.4       4  2                 69        72    0    0 00:26:52 Active

! bgp best path here
R2.15:27:20(config-router-bgp)#sh ip bgp 1.1.1.0
BGP routing table entry for 1.1.1.0/24
 Paths: 1 available
  1
    12.12.12.1 from 12.12.12.1 (130.255.255.100)
      Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:00:23 ago, valid, external, best
      Rx SAFI: Unicast

! but route NOT in RIB
R2.15:27:34(config-router-bgp)#sh ip route 1.1.1.0
Gateway of last resort is not set

3) After slow peer timeout, the prefix shows up in RIB

R2.15:31:32(config-router-bgp)#sh ip route 1.1.1.0
Gateway of last resort is not set

R2.15:31:34(config-router-bgp)#show bgp conv
BGP Convergence information for VRF: default
Configured convergence timeout: 00:05:00
Configured convergence slow peer timeout: 00:01:30
Convergence based update synchronization is enabled
Last Bgp convergence event 00:01:29 ago
Bgp convergence state : Pending (Waiting for EORs/Keepalives from peer(s) and IGP convergence)
   Convergence timer running, will expire in 00:03:31
   Convergence timeout in use: 00:05:00
   Convergence slow peer timeout in use: 00:01:30
   First peer came up 00:01:29 ago
   All the expected peers are up: no
   All IGP protocols have converged: yes
   Outstanding EORs: 0, Outstanding Keepalives: 0
   Pending Peers:          1
       Total Peers:        3
       Established Peers:  2
       Disabled Peers:     0
   Peers that have not converged yet:
       IPv4 peers:
           24.24.24.4            (Session : Active)
       IPv6 peers:
           None

R2.15:31:35(config-router-bgp)#sh ip route 1.1.1.0
 B E    1.1.1.0/24 [200/0] via 12.12.12.1, Ethernet3/36/1

R2.15:31:37(config-router-bgp)#show bgp conv
BGP Convergence information for VRF: default
Configured convergence timeout: 00:05:00
Configured convergence slow peer timeout: 00:01:30
Convergence based update synchronization is enabled
Last Bgp convergence event 00:01:34 ago
Bgp convergence state : Timeout reached
   Time taken to converge 00:01:30
   First peer came up 00:01:34 ago
   Pending Peers:          1
       Total Peers:        3
       Established Peers:  2
       Disabled Peers:     0
   Peers that did not converge before local bgp convergence:
       IPv4 peers:
           24.24.24.4            (Session : Active)
       IPv6 peers:
           None