Wednesday, 4 August 2021

LISP - OMP - BGP EVPN Interoperability - Part V: BGP EVPN MAC Advertisement Route (Type 2).

 

Introduction

 

We have seen in previous chapters how the IP address 172.16.100.10 assigned to EP1 is advertised within the LISP domain and advertised as an aggregate route all the way down to Leaf-11 in the BGP EVPN domain. This chapter first explains how the EP3 ‘s IP address 172.16.30.3 is first advertised by Leaf-11 as BGP EVPN MAC Advertisement Route (Route-Type 2) via Spine-1 to Border-Leaf-13. Next, you will learn how Border-Leaf-13 advertises the aggregate route 172.16.30.0/24 to SD-WAN edge device vEdge-2. The last section briefly shows how the routing information is propagated over the SD-WAN. The BGP EVPN NLRI MAC Advertisement Route carries to MPLS Labels which identifies L2VN (10000) and L3VN (10077). In our example, VLAN 10 is part of the VRF NWKT and it is attached to L2VN 10000. L3VNI for VRF NWKT is 10077. 





Figure 4-1: Overall Control-Plane Operation: BGP EVPN to OMP to LISP.


Local Leaf Processes: MAC Address


When EP3 comes up, it verifies that no one else is using its IP address 172.16.30.3. It does this by sending a GARP message by using the Broadcast MAC address as a destination. Leaf-11 learns both MAC and IP addresses from the ingress GARP message. It stores the MAC address into the VLAN 10 specific MAC table (A1). Besides, Leaf-11 installs the IP address into the ARP Cache (A2). The MAC address information is programmed from the MAC table to EVPN Instance 10000 L2RIB (B1). Also, the IP information is exported from the ARP table into the L2RIB as MAC-IP entry (B2). The reason why we have these two L2 tables is simple, we can’t export information straight from either MAC or ARP tables into the BGP process. Next, Leaf-11 installs MAC and IP information into BGP Loc-RIB as two separate entries, one for the MAC (C1) and the other for the MAC-IP (C2) binding information. Leaf-11 builds Spine-1 specific Adj-RIB-Out entries with a Next-Hop Path-Attribute and then sends the BGP Update message to Spine-1. Spine-1 is unaware of any customer EVPN Instances, meaning it doesn’t have any Route-Target import/export policy, so it just forwards the BGP Update message without installing the information into its local tables. It, however, adds BGP Originator-Id and Cluster-Id Path-Attributes to the BGP Update message.



Figure 4-2: Local Leaf Leaf-11 Processes.


Phase A1: MAC Address Table

Example 4-1 shows that Leaf-11 has installed the MAC address 0050.7966.6814 (EP3) into the VLAN 10 MAC table with port E1/2.

 

Leaf-11# show mac address-table vlan 10

Legend:

        * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC

        age - seconds since last seen,+ - primary entry using vPC Peer-Link,

        (T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan

   VLAN     MAC Address      Type      age     Secure NTFY Ports

---------+-----------------+--------+---------+------+----+------------------

*   10     0050.7966.6814   dynamic  0         F      F    Eth1/2

G   10     5010.0000.1b08   static   -         F      F    sup-eth1(R)

Example 4-1: Leaf-11 VLAN 10 MAC Address Table.

 

I have added example 4-2 just to show that MAC tables can also be viewed per L2VNI.

 

Leaf-11# show mac address-table vni 10000

Legend:

        * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC

        age - seconds since last seen,+ - primary entry using vPC Peer-Link,

        (T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan

   VLAN     MAC Address      Type      age     Secure NTFY Ports

---------+-----------------+--------+---------+------+----+---------------

*   10     0050.7966.6814   dynamic  0         F      F    Eth1/2

Example 4-2: Leaf-11 VNI 10000 MAC Address Table.

 

Phase A2: ARP Table

Example 4-3 shows the VRF NWKTs ARP table where we have an IP address 172.16.30.3 bind to MAC address 0050.7966.6814.

Leaf-11# show ip arp vrf NWKT

 

Flags: * - Adjacencies learnt on non-active FHRP router

       + - Adjacencies synced via CFSoE

       # - Adjacencies Throttled for Glean

       CP - Added via L2RIB, Control plane Adjacencies

       PS - Added via L2RIB, Peer Sync

       RO - Re-Originated Peer Sync Entry

       D - Static Adjacencies attached to down interface

 

IP ARP Table for context NWKT

Total number of entries: 1

Address         Age       MAC Address     Interface       Flags

172.16.30.3     00:16:49  0050.7966.6814  Vlan10

Example 4-3: Leaf-11 ARP Table.

 

Phase B1: L2RIB MAC

 

Example 4-4 illustrates the L2RIB concerning MAC entry. Topology 10 points to L2VN 10000, and the L-Flag indicates that this is a local route. The Next-Hop is interface E1/2.

 

Leaf-11# show l2route evpn mac evi 10

 

Flags -(Rmac):Router MAC (Stt):Static (L):Local (R):Remote (V):vPC link

(Dup):Duplicate (Spl):Split (Rcv):Recv (AD):Auto-Delete (D):Del Pending

(S):Stale (C):Clear, (Ps):Peer Sync (O):Re-Originated (Nho):NH-Override

(Pf):Permanently-Frozen, (Orp): Orphan

 

Topology    Mac Address    Prod   Flags         Seq No     Next-Hops

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

10          0050.7966.6814 Local  L,            0          Eth1/2

Example 4-4: Leaf-11 L2RIB MAC.

 

Phase B2: L2RIB MAC-IP

 

Example 4-5 shows the MAC-IP entry in L2RIB. It is installed into the L2RIB by the Host Mobility Manager (HMM).

 

Leaf-11# show l2route mac-ip topology 10

Flags -(Rmac):Router MAC (Stt):Static (L):Local (R):Remote (V):vPC link

(Dup):Duplicate (Spl):Split (Rcv):Recv(D):Del Pending (S):Stale (C):Clear

(Ps):Peer Sync (Ro):Re-Originated (Orp):Orphan

Topology    Mac Address    Host IP      Prod   Flags  Seq No   Next-Hops

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

10          0050.7966.6814 172.16.30.3   HMM    L,    0        Local

Example 4-5: Leaf-11 L2RIB MAC-IP.

 

Phase C1-2, D1-2: BGP Table

 

Example 4-6 shows BGP L2VPN EVPN entries about MAC and MAC-IP in Leaf-11’s BGP table. The Route-Distinguisher (RD) is a part of the address, and it makes it possible to use overlapping MAC and IP addresses within VRF/Tenant. The IP address part (192.168.100.11) in BGP Loc-RIB is the BGP RID of the local device. The latter part comes from the base value 32676 plus VLAN Id 10. The Next-Hop is the IP attached to Loopback 50 that, in turn, is bind to NVE Interface (tunnel interface). The address [2]:[0]:[0]:[48]:[0050.7966.6814]:[0]:[0.0.0.0]/216 tells that this MAC Advertisement Route (Route Type [2]), following [0]:[0] means that we are not using ESI Multihoming and that there is no Ethernet Tag-Id. the [48] is the length of the following MAC address [0050.7966.6814]. The last part [0]:[0.0.0.0] means that this is MAC-Only. The /216 is the address bit count.

The Extended Community Received Label 10000 is used in Data-Plane as L2VN Identifier, which means that all Intra-VN (switched) traffic within VLAN 10 carries this label. The Route-Target Extended Community 65030:10000 is auto-generated from BGP ASN and L2VNI. The Encapsulation value eight means VXLAN encapsulation will be used in Data-Plane.

 

The second entry [2]:[0]:[0]:[48]:[0050.7966.6814]:[32]:[172.16.30.3]/272 describes the MAC-IP binding information. It is identical to the first entry with three additional Extended Communities. The first one, is an additional Label 10077 used in Data-Plane for Inter-VN (routed) traffic between different VNs. The second one, the additional Route-Target 65030:10077 that is used for importing routes into BGP EVPN L3VNI. It is needed in order to do routing between subnets/VNs. The last one is the Route MAC address that is needed because VXLAN is MAC-in-IP/UDP tunneling mechanism, and the inner destination MAC address in routed traffic uses Router MAC address (host MAC addresses are not available in routed traffic). I will go through the Inter-VN routing process later in the Data-Plane chapter.

 

Leaf-11# show bgp l2vpn evpn 0050.7966.6814

BGP routing table information for VRF default, address family L2VPN EVPN

Route Distinguisher: 192.168.100.11:32777    (L2VNI 10000)

BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6814]:[0]:[0.0.0.0]/216, version 7

Paths: (1 available, best #1)

Flags: (0x000102) (high32 00000000) on xmit-list, is not in l2rib/evpn

 

  Advertised path-id 1

  Path type: local, path is valid, is best path, no labeled nexthop

  AS-Path: NONE, path locally originated

    192.168.50.11 (metric 0) from 0.0.0.0 (192.168.100.11)

      Origin IGP, MED not set, localpref 100, weight 32768

      Received label 10000

      Extcommunity: RT:65030:10000 ENCAP:8

 

  Path-id 1 advertised to peers:

    192.168.100.1

BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6814]:[32]:[172.16.30.3]/272, version 6

Paths: (1 available, best #1)

Flags: (0x000102) (high32 00000000) on xmit-list, is not in l2rib/evpn

 

  Advertised path-id 1

  Path type: local, path is valid, is best path, no labeled nexthop

  AS-Path: NONE, path locally originated

    192.168.50.11 (metric 0) from 0.0.0.0 (192.168.100.11)

      Origin IGP, MED not set, localpref 100, weight 32768

      Received label 10000 10077

      Extcommunity: RT:65030:10000 RT:65030:10077 ENCAP:8 Router MAC:5010.0000.1b08

 

  Path-id 1 advertised to peers:

    192.168.100.1

Example 4-6: Leaf-11 BGP Tables.

  

Capture 4-1 shows how Leaf-11 encodes information into the BGP Update message. Note that the L2VN Identifier is encoded into MPLS 1 field and the L3VN Identifier is encoded into the MPLS 2 field. In order to get the VNI from the MPLS fields, we need to convert Binary to HEX and HEX to Decimal. So, the Binary number 0010 0111 0001 0000 (last four digits not shown in capture) in HEX representation is 2710, which is 10 000 converted to Decimal. The Decimal value 625 for MPLS Label 1 comes from the Binary value 0010 0111 0001 (last four digits excluded) that in HEX format is 0271 (=Decimal format 625). The same conversion process also applies to MPLS Label 2. The last Extended Community with an Unknown subtype is the Router MAC address.

 

Internet Protocol Version 4, Src: 192.168.100.11, Dst: 192.168.100.1

Transmission Control Protocol, Src Port: 40654, Dst Port: 179, Seq: 20, Ack: 20, Len: 127

Border Gateway Protocol - UPDATE Message

    Marker: ffffffffffffffffffffffffffffffff

    Length: 127

    Type: UPDATE Message (2)

    Withdrawn Routes Length: 0

    Total Path Attribute Length: 104

    Path attributes

        Path Attribute - MP_REACH_NLRI

            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete

            Type Code: MP_REACH_NLRI (14)

            Length: 51

            Address family identifier (AFI): Layer-2 VPN (25)

            Subsequent address family identifier (SAFI): EVPN (70)

            Next hop network address (4 bytes)

            Number of Subnetwork points of attachment (SNPA): 0

            Network layer reachability information (42 bytes)

                EVPN NLRI: MAC Advertisement Route

                    Route Type: MAC Advertisement Route (2)

                    Length: 40

                    Route Distinguisher: 0001c0a8640b8009 (192.168.100.11:32777)

                    ESI: 00:00:00:00:00:00:00:00:00:00

                    Ethernet Tag ID: 0

                    MAC Address Length: 48

                    MAC Address: Private_66:68:14 (00:50:79:66:68:14)

                    IP Address Length: 32

                    IPv4 address: 172.16.30.3

                    0000 0000 0010 0111 0001 .... = MPLS Label 1: 625

                    0000 0000 0010 0111 0101 .... = MPLS Label 2: 629

        Path Attribute - ORIGIN: IGP

        Path Attribute - AS_PATH: empty

        Path Attribute - LOCAL_PREF: 100

        Path Attribute - EXTENDED_COMMUNITIES

            Flags: 0xc0, Optional, Transitive, Complete

            Type Code: EXTENDED_COMMUNITIES (16)

            Length: 32

            Carried extended communities: (4 communities)

                Route Target: 65030:10000 [Transitive 2-Octet AS-Specific]

                Route Target: 65030:10077 [Transitive 2-Octet AS-Specific]

                Encapsulation: VXLAN Encapsulation [Transitive Opaque]

                Unknown subtype 0x03: 0x5010 0x0000 0x1b08 [Transitive EVPN]

Capture 4-1: Leaf-11 BGP Update to Spine-1.


 

Remote Leaf Processes: MAC Address

 

Border-Leaf-13 receives the BGP update carrying both MAC and MAC-IP EVPN NLRI from Spine-1. It installs the received information into the BGP Adj-RIB-In, and from there it imports L2VNI 10000 information (MAC and MAC-IP address) into Loc-RIB based on RT 65030:10000. It also imports L3VNI information (IP) based on the RT 65030:10077 into Loc-RIB. The MAC address information is installed first into L2RIB and from there to VLAN 10 MAC address table. The MAC address information is used for Intra-VN switching. In addition, Border-Leaf-13 installs IP/MAC binding into local ARP Cache from the L2VNI 10000 MAC-IP entry. Based on L3VNI RT 65030:10077, Border-Leaf-13 imports routing information also into L3RIB as a host route. From there, the route is exported to vEdge-2 specific Adj-RIB-Out. The Route-Target is taken from the VRF NWKT configuration. Then Border-Leaf-13 builds the BGP update message and sends it to vEdge-2. Note that we are using route aggregation in Border-Leaf-13, so the NLRI is subnet 172.16.30.0/24.



Figure 4-3: Remote Leaf Border-Leaf-13 Processes.


 

Phase E1-2, F1-2: BGP Table

 

Example 4-7 shows the Border-Leaf-13’s BGP table EVPN entries about IP address 172.16. 30.3. Note, by using the IP address instead of the MAC address in the show command, we get only L2VN MAC-IP entries, and MAC-only entries are excluded from the output. The first entry describes unmodified EVPN NLRI in BGP Adj-RIB-In. It has the original RD 192.168.100.11:32777 set by Leaf-11. The second entry shows the L2VNI 10000 specific BGP Loc-RIB information. The import policy is based on Route-Target 65030:10000. This information is later installed into L2RIB from where it is programmed into the VLAN 10 MAC address table. The RD is changed from 192.18.100.11:32777 to 192.168.100.13:32777 during the import process. In addition, MAC-IP binding information is exported to the local ARP Cache. The third highlighted entry shows how the information is installed into BGP Loc-RIB as the L3VNI entry. The Import is based on the RT 65030:10077 and the information is also used when the route is installed into the VRF NWKT RIB.

 

Border-leaf-13# show bgp l2vpn evpn 172.16.30.3

BGP routing table information for VRF default, address family L2VPN EVPN

Route Distinguisher: 192.168.100.11:32777

BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6814]:[32]:[172.16.30.3]/272, version 5

Paths: (1 available, best #1)

Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW

 

  Advertised path-id 1

  Path type: internal, path is valid, is best path, no labeled nexthop

             Imported to 3 destination(s)

             Imported paths list: NWKT L3-10077 L2-10000

  AS-Path: NONE, path sourced internal to AS

    192.168.50.11 (metric 81) from 192.168.100.1 (192.168.100.1)

      Origin IGP, MED not set, localpref 100, weight 0

      Received label 10000 10077

      Extcommunity: RT:65030:10000 RT:65030:10077 ENCAP:8 Router MAC:5010.0000.1b08

      Originator: 192.168.100.11 Cluster list: 192.168.100.1

 

  Path-id 1 not advertised to any peer

 

Route Distinguisher: 192.168.100.13:32777    (L2VNI 10000)

BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6814]:[32]:[172.16.30.3]/272, version 6

Paths: (1 available, best #1)

Flags: (0x000212) (high32 00000000) on xmit-list, is in l2rib/evpn, is not in HW

 

  Advertised path-id 1

  Path type: internal, path is valid, is best path, no labeled nexthop, in rib

             Imported from 192.168.100.11:32777:[2]:[0]:[0]:[48]:[0050.7966.6814]:[32]:[172.16.30.3]/272

  AS-Path: NONE, path sourced internal to AS

    192.168.50.11 (metric 81) from 192.168.100.1 (192.168.100.1)

      Origin IGP, MED not set, localpref 100, weight 0

      Received label 10000 10077

      Extcommunity: RT:65030:10000 RT:65030:10077 ENCAP:8 Router MAC:5010.0000.1b08

      Originator: 192.168.100.11 Cluster list: 192.168.100.1

 

  Path-id 1 not advertised to any peer

 

Route Distinguisher: 192.168.100.13:3    (L3VNI 10077)

BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6814]:[32]:[172.16.30.3]/272, version 7

Paths: (1 available, best #1)

Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW

 

  Advertised path-id 1

  Path type: internal, path is valid, is best path, no labeled nexthop

             Imported from 192.168.100.11:32777:[2]:[0]:[0]:[48]:[0050.7966.6814]:[32]:[172.16.30.3]/272

  AS-Path: NONE, path sourced internal to AS

    192.168.50.11 (metric 81) from 192.168.100.1 (192.168.100.1)

      Origin IGP, MED not set, localpref 100, weight 0

      Received label 10000 10077

      Extcommunity: RT:65030:10000 RT:65030:10077 ENCAP:8 Router MAC:5010.0000.1b08

      Originator: 192.168.100.11 Cluster list: 192.168.100.1

 

  Path-id 1 not advertised to any peer

Example 4-7: Border-Leaf-13 BGP Tables.

 

Phase I: L3RIB

 

Example 4-8 verifies that route is exported from the BGP Loc-RIB into the VRF NWKT’s RIB.

 

Border-leaf-13# show ip route 172.16.30.3 vrf NWKT

IP Route Table for VRF "NWKT"

<snipped>

 

172.16.30.3/32, ubest/mbest: 1/0

    *via 192.168.50.11%default, [200/0], 01:32:33, bgp-65030, internal, tag 65030, segid: 10077 tunnelid: 0xc0a8320b encap: VXLAN

Example 4-8: Border-Leaf-13 RIB.

 

Phase G1: L2RIB

 

Example 4-9 shows that route is exported from the BGP Loc-RIB into L2RIB. Topology Id points to VLAN 10 that is attached to VN10000. Information is produced by BGP and the next-hop is the tunnel interface NVE1 of Leaf-11.

 

Border-leaf-13# show l2route evpn mac evi 10

 

Flags -(Rmac):Router MAC (Stt):Static (L):Local (R):Remote (V):vPC link

(Dup):Duplicate (Spl):Split (Rcv):Recv (AD):Auto-Delete (D):Del Pending

(S):Stale (C):Clear, (Ps):Peer Sync (O):Re-Originated (Nho):NH-Override

(Pf):Permanently-Frozen, (Orp): Orphan

 

Topology    Mac Address    Prod   Flags    Seq No  Next-Hops

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

10          0050.7966.6814 BGP    SplRcv   0       192.168.50.11 (Label: 10000)

Example 4-9: Border-Leaf-13 L2RIB.


 

Phase H1: MAC Address Table

 

Example 4-10 shows that the MAC address 0050.7966.6814 is exported from the L2RIB into the MAC address table. The Port describes the next-hop address and that the frames switched to the network will be sent via the NVE1 tunnel interface.

 

Border-leaf-13# show mac address-table vlan 10

Legend:

        * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC

        age - seconds since last seen,+ - primary entry using vPC Peer-Link,

        (T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan

   VLAN     MAC Address      Type      age     Secure NTFY Ports

---------+-----------------+--------+---------+------+----+--------------

C   10     0050.7966.6814   dynamic  0         F      F    nve1(192.168.50.11)

G   10     5012.0000.1b08   static   -         F      F    sup-eth1(R)

Example 4-10: Border-Leaf-13 MAC address table.

 

In order to Border-Leaf -13 be able to switch frames to destination MAC address, it has to know what tunnel encapsulation is used with the next-hop device 192.168.50.11 (Leaf-11). This information is stored in the Recursive Next-Hop Database (RNH DB). Example 4-11 shows that the encapsulation type is VLAN and the VN for egress frames is 10000. The Peer-MAC is not used when switching frames because the inner header (payload) has sender and receiver MAC addresses. Anyway, MAC address information is needed in the case where one of the locally connected hosts wants to send data to a remote host in the same L2 domain and that is not our case because Border-Leaf-13 doesn’t have any local hosts.

 

Border-leaf-13# show nve internal bgp rnh database vni 10000

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

Total peer-vni msgs recvd from bgp: 1

Peer add requests: 2

Peer update requests: 0

Peer delete requests: 0

Peer add/update requests: 2

Peer add ignored (peer exists): 0

Peer update ignored (invalid opc): 0

Peer delete ignored (invalid opc): 0

Peer add/update ignored (malloc error): 0

Peer add/update ignored (vni not cp): 0

Peer delete ignored (vni not cp): 0

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

Showing BGP RNH Database, size : 2 vni 10000

 

Flag codes: 0 - ISSU Done/ISSU N/A        1 - ADD_ISSU_PENDING

            2 - DEL_ISSU_PENDING          3 - UPD_ISSU_PENDING

 

 

VNI     Peer-IP        Peer-MAC        Tunnel-ID  Encap  (A /S ) Flags PT  Egress VNI

10000   192.168.50.11  0000.0000.0000  0x0        vxlan  (1 /0 ) 0     FAB 10000

Example 4-11: Border-Leaf-13 Recursive Next-Hop Database for VNI 10000.

 

Capture 4-2 shows the BGP Update message, which Border-Leaf-13 sent to the local SD-WAN edge device vEdge-2. Instead of advertising individual host IP address 172.16.30.3/32, we are using an aggregate route 172.16.30.0/24.

 

Internet Protocol Version 4, Src: 172.16.20.13, Dst: 172.16.20.1

Transmission Control Protocol, Src Port: 37301, Dst Port: 179, Seq: 1, Ack: 1, Len: 61

Border Gateway Protocol - UPDATE Message

    Marker: ffffffffffffffffffffffffffffffff

    Length: 61

    Type: UPDATE Message (2)

    Withdrawn Routes Length: 0

    Total Path Attribute Length: 34

    Path attributes

        Path Attribute - ORIGIN: IGP

        Path Attribute - AS_PATH: 65030

        Path Attribute - NEXT_HOP: 172.16.20.13

        Path Attribute - AGGREGATOR: AS: 65030 origin: 172.16.30.1

        Path Attribute - ATOMIC_AGGREGATE

    Network Layer Reachability Information (NLRI)

        172.16.30.0/24

            NLRI prefix length: 24

            NLRI prefix: 172.16.30.0

Capture 4-2: Border-Leaf-13 BGP Update to vEdge.

 

 

SD-WAN OMP Processes

 

This section briefly recaps the OMP operation. You can go back to chapter two (SD-WAN Control-Plane: OMP) to the check details. The local SD-WAN device vEdge-2 installs the information received from the BGP Update in its BGP Table and from there into the RIB. Then it exports the route to the OMP process and sends the routing update to the centralized SD-WAN Control-Plane node vSmart over the DTLS tunnel. vSmart forwards an unmodified update to vEdge-1. 



Figure 4-4: SD-WAN Processes.

 

Example 4-12 shows the routes that vEdge-2 has learned from BGP routing updates. The next-hop is Border-Leaf-13.

 

vEdge2# show ip routes bgp detail

<snipped>

 

""--------------------------------------------

 VPN 10      PREFIX 172.16.30.0/24

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

 proto           bgp

 proto-sub-type  e

 distance        20

 metric          0

 uptime          0:00:45:18

 nexthop-ifname  ge0/2

 nexthop-addr    172.16.20.13

 status          F,S

Example 4-12: vEdge-2’s RIB.

 

Example 4-13 shows the OMP route to 172.16.30.0/24 (VPN 10). Packets sent over SD-WAN are using Label 1003 as VN-Id. The tloc attribute (Transport Locator) describes the vEdge-2’s System-Id (10.100.100.2), transport network (public-internet), and tunnel encapsulation (GRE). vEdge-2 sends this information to vSmart (10.100.100.13).

 

vEdge2# show omp routes received detail | exclude not\ set | nomore

 

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

omp route entries for vpn 10 route 172.16.30.0/24

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

            RECEIVED FROM:

peer            0.0.0.0

path-id         37

label           1003

status          C,Red,R

    Attributes:

     originator       10.100.100.102

     type             installed

     tloc             10.100.100.102, public-internet, gre

     overlay-id        1

     site-id          20

     origin-proto     eBGP

     origin-metric    0

            ADVERTISED TO:

peer    10.100.100.13

    Attributes:

     originator       10.100.100.102

     label            1003

     path-id          37

     tloc             10.100.100.102, public-internet, gre

     site-id          20

     overlay-id        1

     origin-proto     eBGP

     origin-metric    0

Example 4-13: vEdge-2’s OMP Table.

 

Example 4-14 verifies that the remote SD-WAN device vEdge-1 has received the OMP update from vSmart.

 

vEdge-1# show omp routes received detail | exclude not\ set | nomore

 

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

omp route entries for vpn 10 route 172.16.30.0/24

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

            RECEIVED FROM:

peer            10.100.100.13

path-id         4

label           1003

status          C,I,R

    Attributes:

     originator       10.100.100.102

     type             installed

     tloc             10.100.100.102, public-internet, gre

     overlay-id        1

     site-id          20

     origin-proto     eBGP

     origin-metric    0

Example 4-14: vEdge-1’s OMP Table.

 

Example 4-15 shows that the remote SD-WAN device vEdge-1 has installed the routing information from the OMP table into the RIB.

  

vEdge-1# show ip routes vpn 10 172.16.30.0/24 detail

Codes Proto-sub-type:

  IA -> ospf-intra-area, IE -> ospf-inter-area,

  E1 -> ospf-external1, E2 -> ospf-external2,

  N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,

  e -> bgp-external, i -> bgp-internal

Codes Status flags:

  F -> fib, S -> selected, I -> inactive,

  B -> blackhole, R -> recursive, L -> import

 

""--------------------------------------------

 VPN 10      PREFIX 172.16.30.0/24

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

 proto           omp

 distance        250

 metric          0

 uptime          0:00:52:57

 tloc-ip         10.100.100.102

 tloc-color      public-internet

 tloc-encap      gre

 nexthop-label   1003

 status          F,S

Example 4-15: vEdge-1’s OMP Table.

 

Example 4-16 shows the TLOC Database, which vEdge-1 uses for resolving the tunnel destination IP address for packets to network 172.16.30.0/24 over the Public-Internet transport network.

 

vEdge1# show omp tlocs | exclude not | nomore

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

tloc entries for 10.100.100.102

                 public-internet

                 gre

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

            RECEIVED FROM:

peer            10.100.100.13

status          C,I,R

    Attributes:

     attribute-type    installed

     encap-key         0

     public-ip         10.100.0.102

     public-port       0

     private-ip        10.100.0.102

     private-port      0

     <snipped>

     bfd-status        up

     site-id           10

     <snipped>

     restrict          1

     <snipped>

Example 4-16: vEdge-1’s TLOC Table.

 

This chapter explained how the routing information originated by Leaf-11 is advertised from the BGP EVPN domain to local SD-WAN. It also briefly recaps how the information is advertised over the SD-WAN to the remote device vEdge-1. In the next chapter, I will explain the Control-Plane processes of how the information is advertised to LISP domain Control-Plane node MapSrv-22. 


10 comments:

  1. the routing information originated by Leaf-11 is advertised from the BGP EVPN domain to local SD-WAN. It also briefly recaps how the information is advertised over the SD-WAN to the remote device vEdge-1 network

    ReplyDelete
  2. above information is very helpfull for me also we can learn new courses CCIE Security Training in Bangalore. CCIE Data Center.

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Amazon Web Services offers the AWS certification. This is a professional computer science certification and is often used in the computer programming industry to demonstrate a person’s specialist knowledge of cloud computing. Some vendors even use this type of certification as a hiring criterion as they are looking for skilled technical talent with cloud infrastructure skills. The cost of obtaining this qualification is covered by many online course providers, so there's no need to worry about the financial burden on your future self when you decide to get certified.

    ReplyDelete
  5. This comment has been removed by the author.

    ReplyDelete
  6. Every company's basis depends on how robust its network is. Hubris Technologies provide the best Networking Solutions by enabling real-time relationships between many parties. We deliver refined business solutions with new standard technology that helps industries to accelerate and increase their efficiency.

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. The information which you have provided in this blog is really useful to everyone. Thanks for sharing.

    Network Maintenance Support
    Networking Consultancy

    ReplyDelete
  9. It's especially useful jl261a when the information is presented in a clear and concise way.

    ReplyDelete