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