Sunday 8 August 2021

LISP - OMP - BGP EVPN Interoperability - Part VII: End-to-End Data-Plane Operation

 

Introduction

 

This chapter introduces Data-Plane operation and explains how the data packets from EP3 (IP 172.16.30.3) in Datacenter Fabric are forwarded via SD-WAN to EP1 (IP 172.16.100.10) in Campus Fabric. (1) EndPoint3 sends the ICMP Request packet to its gateway switch Leaf-11. Leaf-11 makes routing decisions based on the VRF NWKT routing table. Before forwarding the packet, Leaf-11 adds a VXLAN header where it uses L3VNI 10077. It also sets the outer IP header where it uses the Border-Leaf-13 tunnel interface’s IP address 192.168.50.13 as a destination. Spine-1 routes the packet to Border-Leaf-13 based on the outer IP address. Border-Leaf-13 notices that the destination IP address of the received IP packet belongs to its’s NVE1 tunnel interface. It removes the outer IP header and based UDP destination port it notices that this is VXLAN encapsulated packet. It knows that L3VNI 10077 belongs to VRF NWKT. It strips off the VXLAN header and routes the packet to vEdge-2. The ingress interface towards DC in vEdge-2 belongs to VPN 10. vEdge-2 consults its routing table. Based on it, vEdge-2 constructs tunnel headers and sends ICMP Request to vEdge-1 via Public-Internet using MPLS Label 1003 as a VPN identifier. Routers in Internet routes packet based on the outer destination IP address. When vEdge-1 receives the packet, it notices that the destination IP address is its’ Public IP address. It first removes the outer IP header. Then it checks the tunnel header. Based on the Label value 1003, it knows that packet belongs to VPN 10. It consults the VPN 10 RIB and routes the packet to Border-PxTR-13. The ingress interface on Border-PxTR-13 belongs to VRF 100_NWKT that belongs to LISP Instance 100. It checks the Instance 100 specific LISP mapping in order to know how it should route the packet. The LISP mapping Database does not contain the information because this is the first packet to destination 172.16.100.10. Border-PxTR-13 sends a LISP Map-Request message to MapSrv-22, which replies with a LISP Map-Reply message, where it describes the RLOC of Edge-xTR-11 that has registered the IP address 172.16.100.10. I have excluded the Map-Request/Reply processes from figure 6-1 to keep the figure simple. Border-Leaf-13 encapsulates the ICMP Request packet with a tunnel header. It sets the Instance-Id 100 on the VXLAN header and adds the outer IP header where it uses the Edge-xTR-11’s IP address 192.168.0.13 as a destination address. Core-1 routes the packet to Edge-xTR-11 based on the outer IP header destination address. Edge-xTR-11 processes the ingress IP packet because the destination IP address belongs to it. Based on the destination UDP port 4789, it knows that the following header is a VXLAN header. Edge-xTR-11 knows that the LISP Instance-Id 100 is bind to BD 100. Because Edge-xTR-11 has an L3 interface in BD 100, it resolves the MAC address for the IP address 172.16.100.10 from the ARP table and the egress interface for the MAC from the MAC address table. EP1 processes the ICMP Request packet and sends the ICMP Reply to EP3.


Figure 6-1: End-to-End Data-Plane Operation.

 

Next sections explain the processes in greater detail.

 

DC Fabric Internal Data-Plane: VXLAN

 

EP3 starts pinging EP1. Because the destination IP address is not within its subnet 172.16.30.0/24, EP3 sends ICMP Request messages to its’ gateway device Leaf-11. The source IP address belongs to VRF NWKT so Leaf-11 does routing lookup from the VRF NWKT’s RIB. Example 6-2 shows that the next-hop IP address is 172.16.50.13. It also shows that the encapsulation is VXLAN and the VNI is 10077. Leaf-11 has received this information from the Border-Leaf-13 via Spine-1 as a BGP EVPN Route-Type 5 advertisement (IP Prefix Route). In order to route the packet to the destination IP address 172.16.50.13, Leaf-11 does recursive route lookup from the global RIB to resolve a real next-hop and sends ICMP request packets to Spine-1 that makes its routing decision based on the outer IP header destination address.



 Figure 6-2: Leaf-11 Data-Plane Processes.

 

EP3> ping 172.16.100.10

 

84 bytes from 172.16.100.10 icmp_seq=1 ttl=57 time=41.347 ms

84 bytes from 172.16.100.10 icmp_seq=2 ttl=57 time=18.682 ms

84 bytes from 172.16.100.10 icmp_seq=3 ttl=57 time=20.703 ms

84 bytes from 172.16.100.10 icmp_seq=4 ttl=57 time=24.209 ms

84 bytes from 172.16.100.10 icmp_seq=5 ttl=57 time=19.733 ms

Example 6-1: Ping from EP3 to EP1.

 

Leaf-11# sh ip route 172.16.100.0 vrf NWKT

IP Route Table for VRF "NWKT"

'*' denotes best ucast next-hop

'**' denotes best mcast next-hop

'[x/y]' denotes [preference/metric]

'%<string>' in via output denotes VRF <string>

 

172.16.100.0/24, ubest/mbest: 1/0

  *via 192.168.50.13%default, [200/1000], 00:45:06, bgp-65030, internal, tag 65100, segid: 10077 tunnelid: 0xc0a8320d encap: VXLAN

Example 6-2: VRF NWKT’s RIB on Leaf-11.

 

Leaf-11# sh ip route 192.168.50.13

IP Route Table for VRF "default"

'*' denotes best ucast next-hop

'**' denotes best mcast next-hop

'[x/y]' denotes [preference/metric]

'%<string>' in via output denotes VRF <string>

 

192.168.50.13/32, ubest/mbest: 1/0

    *via 192.168.0.1, Eth1/1, [110/81], 03:04:41, ospf-UNDERLAY-NET, intra

Example 6-3: Global RIB on Leaf-11.

 

Capture 6-1 shows the packet that Leaf-11 has sent towards Border-Leaf-13. Note that the destination MAC address in the inner MAC header is the Router MAC of Border-Leaf-13 address. The capture 3-1 in chapter 3 shows that Border-Leaf-13 includes its MAC address into BGP Update as Extended Community Path Attribute and that is how Leaf-11 learns the Router MAC. As I mentioned before, the inner MAC is required because VXLAN is MAC-in-UDP/IP encapsulation method.

 

Ethernet II, Src: 50:11:00:00:1b:08, Dst: 50:10:00:00:1b:08

Internet Protocol Version 4, Src: 192.168.50.13, Dst: 192.168.50.11

User Datagram Protocol, Src Port: 65370, Dst Port: 4789

Virtual eXtensible Local Area Network

    Flags: 0x0800, VXLAN Network ID (VNI)

        0... .... .... .... = GBP Extension: Not defined

        .... .... .0.. .... = Don't Learn: False

        .... 1... .... .... = VXLAN Network ID (VNI): True

        .... .... .... 0... = Policy Applied: False

        .000 .000 0.00 .000 = Reserved(R): 0x0000

    Group Policy ID: 0

    VXLAN Network Identifier (VNI): 10077

    Reserved: 0

Ethernet II, Src: 50:12:00:00:1b:08, Dst: 50:10:00:00:1b:08

Internet Protocol Version 4, Src: 172.16.100.10, Dst: 172.16.30.3

Internet Control Message Protocol

Capture 6-1: Packet Sent by Leaf-11 to Border-Leaf-13.

 

DC Fabric to SD-WAN Data-Plane: IP

 

When Border-leaf-13 receives the encapsulated ICMP request from Spine-1, it removes the outer IP header and UDP header. It knows that the following header is the VXLAN header based on the UDP destination port number. The VNI-Id 10077 identifies L3VNI for VRF NWKT 100 and Border-Leaf-13 routes packet on based VRF NWKT’s RIB.



Figure 6-3: Border-Leaf-13 Data-Plane Processes.


Example 6-4 shows the VRF NWKT’s RIB on Border-Leaf-13 concerning the destination network 172.16.100.0/24. The next-hop IP address is the vEdge-2’s DC-link address. Border-leaf-13 has learned this information from the BGP Update message that vEdge-2 has sent to it.

 

Border-leaf-13# sh ip route 172.16.100.0 vrf NWKT

IP Route Table for VRF "NWKT"

'*' denotes best ucast next-hop

'**' denotes best mcast next-hop

'[x/y]' denotes [preference/metric]

'%<string>' in via output denotes VRF <string>

 

172.16.100.0/24, ubest/mbest: 1/0

    *via 172.16.20.1, [20/1000], 00:47:53, bgp-65030, external, tag 65100

Example 6-4: VRF NWKT’s RIB on Border-Leaf-13.

 

Capture 6-2 shows the packet that Border-Leaf-13 has sent towards SD-WAN edge device vEdge-2.

 

Ethernet II, Src: 50:12:00:00:1b:08 (50:12:00:00:1b:08), Dst: 50:00:00:0b:00:03 (50:00:00:0b:00:03)

Internet Protocol Version 4, Src: 172.16.30.3, Dst: 172.16.100.10

Internet Control Message Protocol

    Type: 8 (Echo (ping) request)

    Code: 0

    Checksum: 0x006f [correct]

    [Checksum Status: Good]

    Identifier (BE): 8091 (0x1f9b)

    Identifier (LE): 39711 (0x9b1f)

    Sequence number (BE): 2 (0x0002)

    Sequence number (LE): 512 (0x0200)

    [Response frame: 10]

    Data (56 bytes)

Capture 6-2: Packet Sent by Border-Leaf-13 to vEdge-2.


 

SD-WAN Internal Data-Plane: GRE

 

The Datacentre SD-WAN edge device vEdge-2 receives the ICMP request from Border-Leaf-13. The ingress interface belongs to VPN 10. VPN 10 RIB (example 6-5) shows that the destination TLOC IP address is 10.100.100.101 (vEdge-1’s System-id), the transport network is Public-Internet, and the VPN label is 1003. The RIB entry also shows that the route is learned as an OMP Service route update. However, the RIB entry does describe the destination IP address for the outer IP header used in Data-Plane. To resolve it, vEdge-2 has to consult its OMP TLOC table (example 6-6).


Figure 6-4: vEdge-2 Data-Plane Processes.

 

Edge2# show ip routes vpn 10 172.16.100.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.100.0/24

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

 proto           omp

 distance        250

 metric          0

 uptime          0:00:52:18

 tloc-ip         10.100.100.101

 tloc-color      public-internet

 tloc-encap      gre

 nexthop-label   1003

 status          F,S

Example 6-5: The RIB (OMP Service Routes) of VPN 10 on vEdge-2.

The partial OMP TLOC database output in example 6-6 shows the Public IP address by which vEdge-1 is connected to the Public-Internet. vEdge-2 uses this IP address in the outer IP header as a destination address when sending packets via Public-Internet transport network towards destination subnet 172.16.100.0/24. vEdge-2 has received OMP TLOC routing information from the SD-WAN Control-Plane node vSmart.

 

vEdge2# show omp tlocs ip 10.100.100.101 color public-internet | exclude not | nomore

 

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

tloc entries for 10.100.100.101

                 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.101

     public-port       0

     private-ip        10.100.0.101

     private-port      0

     <snipped>

     bfd-status        up

     site-id           10

     preference        0

     weight            1

     version           3

    gen-id             0x80000039

     carrier           default

     restrict          1

     on-demand          0

     groups            [ 0 ]

     bandwidth         0

     qos-group         default-group

vEdge2#

Example 6-6: OMP TLOC Information on vEdge-2.

 

Capture 6-3 shows that vEdge-2 uses MPLS Label 1003 as VPN identifier when sending a GRE encapsulated packet via Public-Internet to vEdge-1.

 

Ethernet II, Src: 50:00:00:0b:00:01 (50:00:00:0b:00:01), Dst: 50:00:00:02:00:01 (50:00:00:02:00:01)

Internet Protocol Version 4, Src: 10.100.0.102, Dst: 10.100.0.101

Generic Routing Encapsulation (MPLS label switched packet)

    Flags and Version: 0x0000

    Protocol Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header, Label: 1003, Exp: 0, S: 1, TTL: 62

Internet Protocol Version 4, Src: 172.16.30.3, Dst: 172.16.100.10

Internet Control Message Protocol

    Type: 8 (Echo (ping) request)

Capture 6-3: Packet Sent by vEdge-2 to vEdge-1.

 

 

SD-WAN to Campus Fabric Data-Plane: IP

 

vEdge-1 receives the encapsulated ICMP Request from the Public-Internet. The destination IP address is its Public IP address, so it processes the packet. It first removes the outer IP header. Then it checks the MPLS Label value to resolve to which VPN this packet belongs. MPLS Label 1003 defines the VPN 10 on vEdge-1. It does a routing lookup from the VPN 10 RIB. Example 6-7 shows that the next-hop is 172.16.10.13 and that the egress interface is ge0/2. vEdge-2 has learned this information from BGP Update that Border-PxTR-13 has previously sent to it.



Figure 6-5: vEdge-1 Data-Plane Processes.

 

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

<snipped>

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

 VPN 10      PREFIX 172.16.100.0/24

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

 proto           bgp

 proto-sub-type  e

 distance        20

 metric          0

 uptime          0:00:54:42

 nexthop-ifname  ge0/2

 nexthop-addr    172.16.10.13

 status          F,S

Example 6-7: The RIB of VPN 10 on vEdge-1.

 

Capture 6-4 shows the packet that vEdge-1 has sent to Border-PxTR-13.

Ethernet II, Src: 50:00:00:02:00:03, Dst: 50:00:00:0a:00:00

Internet Protocol Version 4, Src: 172.16.30.3, Dst: 172.16.100.10

Internet Control Message Protocol

    Type: 8 (Echo (ping) request)

Capture 6-4: Packet Sent by vEdge-1 to Border-PxTR-13.


Campus Fabric Internal Data-Plane: VXLAN

 

Border-PxTR-13 receives the ICMP Request message from vEdge-1. The ingress interface belongs to VRF 100_NWKT, which in turn is mapped to LISP Instance 100. Example 6-8 shows the VRF 100_NWKT RIB where the next-hop for packets towards network 172.16.100.0/24 is 192.168.0.1 (MapSrv-22). Example 6-9, in turn, shows that this information is also programmed to Forwarding Information Base (FIB). However, this is an aggregate route that MapSrv-22 has sent to Border-Leaf-13. When Border-PxTR-13 receives the first packet, it routes it to MapSrv-22, which doesn’t have routing information in its RIB even though the mapping information is stored in its EID-to-RLOC mapping database. As a result, MapSrv-22 drops the packet. However, the ingress packet triggers the LISP process on Border-Leaf-13. It checks the local Map-Cache to find out EID-to-RLOC mapping information. The result is a miss. It then sends a Map-Request message to MapSrv-22 where it asks what is the RLOC IP address that it should use when sending packets to 172.16.100.10. MapSrv-22 has the information because Edge-xTR-11 has already registered the mapping information. MapSrv-22 sends a Map-Reply message to Border-PxTR-13 where it tells that Edge-xTR-11 (192.168.0.11) is the Egress Tunnel Router (ETR). Border-PxTR-13 installs the information to FIB (example 6-11). At this phase, it has one FIB entry for 172.16.100.0/24 and the other one for 172.16.100.10/32. When the second ICMP Request message arrives, Border-Leaf-13 forwards it correctly to Edge-xTR-11. Border-PxTR-13 adds an outer IP header on top of the packet where it uses the Edge-xTR-11 IP address as a destination. It also adds a UDP header with the destination port 4789. It uses the LISP Instance-Id 100 as a VPN identifier in the VXLAN header. Then it sends the encapsulated packet to Core-1 that routes the packet based on the outer destination IP address.

 


Figure 6-6: Border-PxTR-13 Data-Plane Processes.

Example 6-8 shows the routing information to network 172.16.100.0/24 that Border-PxTR-13 has learned from MapSrv-22 via BGP Update message. We can see that the next is MapSrv-22.

 

Border-PxTR-13#sh ip route vrf 100_NWKT 172.16.100.10

 

Routing Table: 100_NWKT

Routing entry for 172.16.100.0/24

  Known via "bgp 65010", distance 200, metric 0, type internal

  Redistributing via lisp

  Last update from 192.168.0.22 00:57:00 ago

  Routing Descriptor Blocks:

  * 192.168.0.22 (default), from 192.168.0.22, 00:57:00 ago

      Route metric is 0, traffic share count is 1

      AS Hops 0

      MPLS label: 17

      MPLS Flags: MPLS Required

Example 6-8: VRF 100_NWKT’s RIB on Border-PxTR-13.

 

Border-PxTR-13 has also installed the information to FIB.

 

Border-PxTR-13#sh ip cef vrf 100_NWKT 172.16.100.0 detail

172.16.100.0/24, epoch 2, flags [cover dependents, subtree context, rib defined all labels]

  SC owned,sourced: LISP local EID -

  LISP EID attributes: localEID Yes, c-dynEID No, d-dynEID No

  SC owned,sourced: LISP generalised SMR - [disabled, not inheriting, 0x7F38D0EFFDA8 locks: 1]

  Covered dependent prefixes: 1

    notify cover updated: 1

  2 IPL sources [no flags]

  recursive via 192.168.0.22 label 17

    nexthop 192.168.0.1 GigabitEthernet2 unusable: no label

Example 6-9: FIB Entry about Network 172.16.100.0/24 on Bordr-PxTR-13.

 

Example 6-10 shows the EID-to-RLOC Mapping-Cache of Border-PxTR-13 after MapSrv-22 is replied to it. Note that Border-PxTR-13 verifies that the RLOC is reachable by sending probes to it.

 

Border-PxTR-13#show lisp eid-table vrf 100_NWKT ipv4 map-cache 172.16.100.10

LISP IPv4 Mapping Cache for EID-table vrf 100_NWKT (IID 100), 2 entries

 

172.16.100.10/32, uptime: 01:00:44, expires: 22:59:15, via map-reply, self, complete

  Sources: map-reply

  State: complete, last modified: 01:00:44, map-source: 192.168.0.11

  Idle, Packets out: 10(980 bytes) (~ 00:57:55 ago)

  Configured as EID address space

  Locator       Uptime    State      Pri/Wgt     Encap-IID

  192.168.0.11  01:00:44  up           1/1         -

    Last up-down state change:         01:00:44, state change count: 1

    Last route reachability change:    01:00:44, state change count: 1

    Last priority / weight change:     never/never

    RLOC-probing loc-status algorithm:

      Last RLOC-probe sent:            01:00:44 (rtt 3ms)

Example 6-10: EID-to-RLOC Mapping-Cache on Border-PxTR-13.

 

Example 6-11 shows that Border-PxTR-13 has installed the host entry to its FIB.

 

Border-PxTR-13#sh ip cef vrf 100_NWKT 172.16.100.10 detail

172.16.100.10/32, epoch 2, flags [subtree context, check lisp eligibility]

  SC inherited: LISP local EID -

  SC owned,sourced: LISP remote EID - locator status bits 0x00000001

  LISP remote EID: 10 packets 980 bytes fwd action encap, cfg as EID space

  LISP EID attributes: localEID Yes, c-dynEID No, d-dynEID No

  SC owned,sourced: LISP generalised SMR - [enabled, not inheriting, 0x7F38D0EFFD90 locks: 1]

  LISP source path list

    nexthop 192.168.0.11 LISP0.100

  3 IPL sources [no flags]

  nexthop 192.168.0.11 LISP0.100

Example 6-11: FIB Entry about Host IP Address 172.16.100.10/32 on Bordr-PxTR-13.

  

Capture 6-5 shows that Border-PxTR-13 has sent the second ICMP Request message to Edge-xTR-11. It verifies that Border-PxTR-13 has used the LISP Instance-Id 100 as VXLAN Network Identifier.

 

Ethernet II, Src: 50:00:00:0e:00:00 (50:00:00:0e:00:00), Dst: Broadcast (ff:ff:ff:ff:ff:ff)

Internet Protocol Version 4, Src: 192.168.0.13, Dst: 192.168.0.11

User Datagram Protocol, Src Port: 32521, Dst Port: 4789

Virtual eXtensible Local Area Network

    Flags: 0x0840, Don't Learn, VXLAN Network ID (VNI)

        0... .... .... .... = GBP Extension: Not defined

        .... .... .1.. .... = Don't Learn: True

        .... 1... .... .... = VXLAN Network ID (VNI): True

        .... .... .... 0... = Policy Applied: False

        .000 .000 0.00 .000 = Reserved(R): 0x0000

    Group Policy ID: 0

    VXLAN Network Identifier (VNI): 100

    Reserved: 0

Ethernet II, Src: 50:00:00:0a:00:01 (50:00:00:0a:00:01), Dst: ba:25:cd:f4:ad:38 (ba:25:cd:f4:ad:38)

Internet Protocol Version 4, Src: 172.16.30.3, Dst: 172.16.100.10

Internet Control Message Protocol

    Type: 8 (Echo (ping) request)

    Code: 0

    Checksum: 0xfe6c [correct]

    [Checksum Status: Good]

    Identifier (BE): 8603 (0x219b)

    Identifier (LE): 39713 (0x9b21)

    Sequence number (BE): 4 (0x0004)

    Sequence number (LE): 1024 (0x0400)

    [Response frame: 60]

    Data (56 bytes)

Capture 6-5: Packet Sent by Border-Leaf-13 to Edge-xTR-11.

 

Example 6-12 shows the EID-to-RLOC Mapping database on MapSrv-22. Border-Leaf-13 has registered subnets 172.16.30.0/24 and 172.16.100.0/24 to MapSrv-22. Edge-xTR-11, in turn, has registered the host-specific entry.

  

MapSrv-22#show lisp site name Network-Times instance-id 100

Site name: Network-Times

Allowed configured locators: any

Allowed EID-prefixes:

 

  EID-prefix: 172.16.30.0/24 instance-id 100

    First registered:     00:03:21

    Last registered:      00:03:19

    Routing table tag:    0

    Origin:               Configuration, accepting more specifics

    Merge active:         No

    Proxy reply:          Yes

    TTL:                  1d00h

    State:                complete

    Registration errors:

      Authentication failures:   0

      Allowed locators mismatch: 0

    ETR 192.168.0.13, last registered 00:03:19, proxy-reply, map-notify

                      TTL 1d00h, no merge, hash-function sha1, nonce 0x54FAEC88-0x22E5BC8B

                      state complete, no security-capability

                      xTR-ID 0xEFD8CACE-0x5906016A-0xD7C49F5F-0x5CC352DB

                      site-ID unspecified

                      sourced by reliable transport

      Locator       Local  State      Pri/Wgt  Scope

      192.168.0.13  yes    up           1/1    IPv4 none

 

  EID-prefix: 172.16.100.0/24 instance-id 100

    First registered:     00:01:54

    Last registered:      00:01:54

    Routing table tag:    0

    Origin:               Configuration, accepting more specifics

    Merge active:         No

    Proxy reply:          Yes

    TTL:                  1d00h

    State:                complete

    Registration errors:

      Authentication failures:   0

      Allowed locators mismatch: 0

    ETR 192.168.0.13, last registered 00:01:54, proxy-reply, map-notify

                      TTL 1d00h, no merge, hash-function sha1, nonce 0x54FAEC88-0x22E5BC8B

                      state complete, no security-capability

                      xTR-ID 0xEFD8CACE-0x5906016A-0xD7C49F5F-0x5CC352DB

                      site-ID unspecified

                      sourced by reliable transport

      Locator       Local  State      Pri/Wgt  Scope

      192.168.0.13  yes    up           1/1    IPv4 none

 

  EID-prefix: 172.16.100.10/32 instance-id 100

    First registered:     00:01:54

    Last registered:      00:01:49

    Routing table tag:    0

    Origin:               Dynamic, more specific of 172.16.100.0/24

    Merge active:         No

    Proxy reply:          Yes

    TTL:                  1d00h

    State:                complete

    Registration errors:

      Authentication failures:   0

      Allowed locators mismatch: 0

    ETR 192.168.0.11, last registered 00:01:49, proxy-reply, map-notify

                      TTL 1d00h, no merge, hash-function sha1, nonce 0x2A38F7C7-0x79599A97

                      state complete, no security-capability

                      xTR-ID 0xB29EE3E2-0x6BDDF328-0x6524BF4B-0x9769F92A

                      site-ID unspecified

                      sourced by reliable transport

      Locator       Local  State      Pri/Wgt  Scope

      192.168.0.11  yes    up           1/1    IPv4 none

Example 6-13: EID-to-RLOC Mapping Table on MapSrv-22.

 

 

Campus Fabric Internal Data-Plane (Edge-11): Switched

 

When Edge-xTR-11 receives the encapsulated ICMP Request from Spine-1, it notices that the destination IP address belongs to it. It removes the outer IP header and based on the destination UDP port, it knows that the next header is the VXLAN header. It knows that the packet belongs to the VRF 100_NWKT based on the LISP Instance-Id 100 encoded to the VXLAN header. It does ARP lookup to find the IP/MAC address mapping information and then checks from the MAC address table to find out the egress interface where EP1 is connected.

 

 

Edge-xTR-11#show bridge-domain 100

Bridge-domain 100 (2 ports in all)

State: UP                    Mac learning: Enabled

Aging-Timer: 300 second(s)

    BDI100  (up)

    GigabitEthernet2 service instance 100

   AED MAC address    Policy  Tag       Age  Pseudoport

   -   0001.0001.0001 to_bdi  static    0    BDI100

   0   0050.7966.680D forward dynamic   265  GigabitEthernet2.EFP100

Example 6-15: MAC Address Table of Bridge Domain 100.

 

Now we have seen the Control-Plane processes how devices using different Control-Plane protocols advertises routing information between themself. We have also seen how devices forward packets across domains that don't use the same encapsulation methods. The next chapter discusses the similarities of Control-Plane operation between Campus Fabric with LISP, SD-WAN with OMP, and Datacenter Fabric with BGP EVPN.


No comments:

Post a Comment

Note: only a member of this blog may post a comment.