Introduction
Though inter-subnet communication in a BGP
EVPN-based network between hosts happens through the anycast default gateway of
the subnet, it can use two different forwarding models: Asymmetric and
Symmetric Integrated Routing and Bridging (IRB). The basic difference between
these two IRB models is how the packet is forwarded between the ingress and
egress VTEPs.
When an ingress VTEP receives a frame whose
destination is in a different subnet from the source, the initial forwarding
operations are common to both IRB models. The VTEP performs a MAC lookup in the
local VLAN's MAC address table and resolves the anycast gateway (AGW) MAC
address. The packet is then routed toward the tenant IP-VRF, where an IP lookup
determines the route toward the destination IP address. The routing information
identifies the remote VTEP as the overlay next hop. The remote VTEP's underlay
IP address is then resolved for use as the outer VXLAN destination IP address.
This resolution can involve recursive lookup through the underlay routing
table.
The forwarding paths diverge after the
ingress VTEP performs the IP lookup. In asymmetric IRB, the ingress VTEP
performs an additional MAC lookup in the bridge table associated with the
destination subnet. The resulting forwarding information identifies the remote
VTEP and the L2VNI associated with the destination VLAN. The packet is
encapsulated with this L2VNI and sent to the egress VTEP. Because the
destination MAC lookup is performed on the ingress VTEP, all VLANs
participating in the tenant IP-VRF must be configured on every VTEP
participating in asymmetric IRB, even if a particular VTEP has no local hosts
in that VLAN.
After
decapsulation, the egress VTEP uses the VNI-to-VLAN mapping to identify the
destination VLAN and its associated bridge table. It then performs a MAC lookup
in the destination VLAN's MAC address table to forward the frame to the
destination host.
Thus, in asymmetric IRB, the inter-subnet
forwarding between the VTEPs is performed between their associated
MAC-VRFs/bridge tables. The forwarding process is therefore asymmetric between
the two VTEPs: the ingress VTEP performs MAC + IP + MAC lookups, while the
egress VTEP performs only a MAC lookup. The first MAC lookup resolves the local
VLAN's anycast gateway MAC address, the IP lookup determines the destination IP
subnet, and the second MAC lookup resolves the destination MAC address in the
destination VLAN's MAC address table.
In symmetric IRB, inter-subnet forwarding
between the ingress and egress VTEPs is performed through their associated
IP-VRFs. In the VXLAN implementation used here, each tenant IP-VRF is
associated with an L3VNI, which identifies the IP-VRF in the VXLAN data plane.
The L3VNI is obtained from the IP-VRF-to-VNI mapping and is independent of the
destination IP address.
After the ingress VTEP performs the IP
lookup, it does not perform a MAC lookup in the destination VLAN's bridge
table. Instead, the packet is encapsulated in VXLAN using the L3VNI associated
with the tenant IP-VRF. The L3VNI identifies the IP-VRF in the VXLAN data plane
on the egress VTEP.
The receiving VTEP receives the VXLAN packet
because its VTEP IP address matches the outer destination IP address. It
removes the VXLAN encapsulation and uses the L3VNI to identify the
corresponding tenant IP-VRF. The VTEP then performs an IP lookup for the
destination IP address in the IP-VRF routing table. The routing lookup
identifies the destination VLAN, after which the VTEP resolves the destination
MAC address and performs a MAC lookup in the destination VLAN's bridge table
before forwarding the frame to the destination host.
The forwarding process is therefore symmetric
between the two VTEPs: the ingress VTEP performs a MAC lookup followed by an IP
lookup, while the egress VTEP performs an IP lookup followed by a MAC lookup.
One benefit of symmetric IRB is that each VTEP only needs MAC-VRFs/bridge
tables for locally configured VLANs and ARP/NDP entries for locally connected
hosts.
The focus of this chapter is on symmetric
IRB, which is the forwarding model examined in the SONiC configuration and
database analysis that follows. Asymmetric IRB is introduced in this section
only to explain the conceptual difference between the two IRB models.
Configuration
Figure 8-1 illustrates the example setup with
two extended VLANs spanning Leaf-101 and Leaf-102. VLAN 10 (10.0.10.0/24) is
mapped to L2VNI 10010, and VLAN 20 (10.0.20.0/24) is mapped to L2VNI 10020. Our
intent is to create an inter-subnet communication path between Host-1 (IP:
10.0.10.101, MAC: 00:50:79:66:68:00), connected to Leaf-101 in VLAN 10, and
Host-4 (IP: 10.0.20.102, MAC: 00:50:79:66:68:02). Because our datacenter is
multitenant, we first create a Virtual Routing and Forwarding (VRF) instance and
then add the routing interfaces for both VLANs to that VRF. In the previous
chapter, we already mapped VLAN 10 to VNI 10010, so we only need to map VLAN 20
to VNI 10020 under the VXLAN interfaces vtep_l-101 on Leaf-101 and vtep_l-102
on Leaf-102. This provides the basic configuration required for inter-subnet
routing using Integrated Routing and Bridging (IRB).
Figure 8-1 also depicts the forwarding model
and data path between Host-1 and Host-4. With the configuration completed so
far, we have established an asymmetric communication path, or asymmetric IRB,
between the two hosts. The following lookups and forwarding operations take
place when Host-1 sends an ICMP Request message to Host-4.
The destination IP address belongs to a
different subnet, so Host-1 sends the packet to the VLAN 10 Anycast Gateway
(1). After an IP route lookup in the routing context associated with VLAN 10
(1a), the packet is routed through the VLAN 20 Anycast Gateway (1b). The packet
is then handled in the VLAN 20 bridge domain, where a MAC address lookup is
performed in the VLAN 20 MAC address table (2a). The lookup identifies the
destination MAC address behind the remote VTEP, Leaf-102, and the packet is
forwarded toward the VXLAN tunnel (2b).
Before leaving Leaf-101, the packet is
encapsulated with VXLAN. The VNI is set according to the VLAN-to-VNI mapping
(3a) configured under the VTEP interface, resulting in VNI 10020. Leaf-102, the
remote VTEP, receives the packet and removes the VXLAN encapsulation. Based on
the carried VNI 10020, Leaf-102 identifies the associated VLAN 20 bridge domain
(3b). It then performs a MAC address lookup in the VLAN 20 MAC address table
(4a) to determine the local forwarding destination (4b) and forwards the ICMP
Request message to Host-4.
The same type of forwarding operation is
performed in the reverse direction when Host-4 sends the ICMP Reply message to
Host-1. At this stage, the forwarding model is therefore asymmetric IRB: the
packet is routed into the destination L2VNI before being VXLAN-encapsulated,
resulting in the forwarding sequence Route → L2 bridge
→ L2 bridge.
Figure 8-1: Asymmetric
IRB.
The asymmetric IRB forwarding model can also
be observed directly in the VXLAN traffic captured on the underlay link between
the switches. Example 8-1 shows a tcpdump capture from Spine-102 while Host-1
sends an ICMP Echo Request to Host-4.
The first VXLAN packet is sent from Leaf-101
(1.1.101.101) to Leaf-102 (1.1.102.102) with VNI 10020:
1.1.101.101 > 1.1.102.102: VXLAN, vni 10020
10.0.10.101
> 10.0.20.102: ICMP echo request
The inner packet still contains the original source and destination
IP addresses, 10.0.10.101 and 10.0.20.102, but the VXLAN VNI is already 10020.
This shows that Leaf-101 has performed the IP routing decision before VXLAN
encapsulation and placed the packet into the destination VLAN 20 bridge domain.
The subsequent MAC lookup in VLAN 20 determines the remote VTEP and forwarding
path. Leaf-101 therefore encapsulates the packet using the L2VNI associated
with the destination subnet, VNI 10020.
The return traffic provides an even clearer indication of the
asymmetric forwarding model. Before sending the ICMP Echo Reply, Host-4 sends
an ARP request for its VLAN 20 Anycast Gateway (`10.0.20.1`). The ARP request
is carried from Leaf-102 to Leaf-101 using VNI 10020. Leaf-101 responds with
the gateway MAC address, and the ARP reply is also carried in VNI 10020.
The ICMP Echo Reply itself is then sent from Leaf-102 to Leaf-101
using VNI 10010:
1.1.102.102 > 1.1.101.101: VXLAN, vni 10010
10.0.20.102
> 10.0.10.101: ICMP echo reply
Thus, the two directions use different L2VNIs. The request from
Host-1 to Host-4 is routed from VLAN 10 into VLAN 20 and then transported using
VNI 10020. The reply from Host-4 to Host-1 is routed from VLAN 20 into VLAN 10
and transported using VNI 10010:
Host-1 → VLAN 10 → Route → VLAN 20 → VNI 10020 → Leaf-102
→ Host-4
Host-4 → VLAN 20 → Route → VLAN 10 → VNI 10010 → Leaf-101
→ Host-1
This behavior is characteristic of asymmetric IRB: the packet is
routed locally into the destination L2 bridge domain before VXLAN
encapsulation. Consequently, each direction uses the L2VNI corresponding to its
destination subnet.
admin@Spine-11:~$
sudo tcpdump -i Ethernet0 -nn -s0 -vvv -t -c 10 'udp port 4789'
tcpdump:
listening on Ethernet0, link-type EN10MB (Ethernet), snapshot length 262144
bytes
IP (tos 0x0, ttl
64, id 9860, offset 0, flags [none], proto UDP (17), length 134)
1.1.101.101.46420 > 1.1.102.102.4789:
[udp sum ok] VXLAN, flags [I] (0x08), vni 10020
IP (tos 0x0, ttl
63, id 51764, offset 0, flags [none], proto ICMP (1), length 84)
10.0.10.101 > 10.0.20.102: ICMP echo
request, id 13514, seq 1, length 64
IP (tos 0x0, ttl
63, id 31474, offset 0, flags [none], proto UDP (17), length 100)
1.1.102.102.54813 > 1.1.101.101.4789:
[udp sum ok] VXLAN, flags [I] (0x08), vni 10020
ARP, Ethernet
(len 6), IPv4 (len 4), Request who-has 10.0.20.1 (ff:ff:ff:ff:ff:ff) tell
10.0.20.102, length 50
IP (tos 0x0, ttl
64, id 9864, offset 0, flags [none], proto UDP (17), length 78)
1.1.101.101.57635 > 1.1.102.102.4789:
[udp sum ok] VXLAN, flags [I] (0x08), vni 10020
ARP, Ethernet
(len 6), IPv4 (len 4), Reply 10.0.20.1 is-at aa:bb:cc:11:22:33, length 28
IP (tos 0x0, ttl
63, id 31475, offset 0, flags [none], proto UDP (17), length 134)
1.1.102.102.38995 > 1.1.101.101.4789:
[udp sum ok] VXLAN, flags [I] (0x08), vni 10010
IP (tos 0x0, ttl
63, id 51764, offset 0, flags [none], proto ICMP (1), length 84)
10.0.20.102 > 10.0.10.101: ICMP echo
reply, id 13514, seq 1, length 64
IP (tos 0x0, ttl
64, id 9916, offset 0, flags [none], proto UDP (17), length 134)
1.1.101.101.46420 > 1.1.102.102.4789:
[udp sum ok] VXLAN, flags [I] (0x08), vni 10020
IP (tos 0x0, ttl
63, id 51765, offset 0, flags [none], proto ICMP (1), length 84)
10.0.10.101 > 10.0.20.102: ICMP echo
request, id 13770, seq 2, length 64
IP (tos 0x0, ttl
63, id 31573, offset 0, flags [none], proto UDP (17), length 134)
1.1.102.102.38995 > 1.1.101.101.4789:
[udp sum ok] VXLAN, flags [I] (0x08), vni 10010
IP (tos 0x0, ttl
63, id 51765, offset 0, flags [none], proto ICMP (1), length 84)
10.0.20.102 > 10.0.10.101: ICMP echo
reply, id 13770, seq 2, length 64
Example 8-1:
ICMP Request/Reply Between Host-1 to Host .
Figure 8-2 illustrates our example setup with
all required building blocks for symmetric IRB. First, we configure VLAN 77
using the Linux config command sudo config vlan add 77.Next, using sonic-cli, we create a routing interface for VLAN 77 and
attach it to Vrf-NWKT-1. As the final two configuration steps, we map VNI 28158
with VLAN 77 and VRF Vrf-NWKT-1 under the VXLAN interfaces vtep_l-101 and
vtep_l-102. With these configuration steps, the L3VNI provides the VXLAN
overlay used for symmetric IRB forwarding between the VTEPs. The following
sections analyze the resulting control-plane and data-plane operations using
show command output collected from the devices.
Figure 8-2: Symmetric
IRB.
Example 8-2 shows the L3VNI 28158 information
from both VTEP switches. The VNI type is L3, and it is associated with the
tenant VRF Vrf-NWKT-1. The SVI associated with the L3VNI is Vlan77, and the
System MAC and Router MAC are identical on each VTEP. However, the MAC address
is locally derived and therefore differs between Leaf-101 (0c:cb:81:19:00:0a)
and Leaf-102 (0c:e8:78:22:00:0a).
The L2 VNIs entry shows that L2VNIs 10010 and
10020 are associated with L3VNI 28158, providing the L3 forwarding context for
inter-subnet communication between the two L2VNIs.
|
Leaf-101# show
evpn vni 28158 VNI: 28158 Type: L3 Tenant VRF: Vrf-NWKT-1 Local Vtep Ip: 1.1.101.101 Local External Vtep Ip: 0.0.0.0 Vxlan-Intf: vtep_l-101-77 SVI-If: Vlan77 State: Up Client State: Up VNI Filter: none System MAC: 0c:cb:81:19:00:0a Router MAC: 0c:cb:81:19:00:0a L2 VNIs: 10010 10020 Leaf-101# |
Leaf-102# show
evpn vni 28158 VNI: 28158 Type: L3 Tenant VRF: Vrf-NWKT-1 Local Vtep Ip: 1.1.102.102 Local External Vtep Ip: 0.0.0.0 Vxlan-Intf: vtep_l-102-77 SVI-If: Vlan77 State: Up Client State: Up VNI Filter: none System MAC: 0c:e8:78:22:00:0a Router MAC: 0c:e8:78:22:00:0a L2 VNIs: 10010 10020 Leaf-102# |
Example 8-2:
L3VNI 28158 Information.
Control Plane Verification
Example 8-3 shows the BGP EVPN MAC/IP
Advertisement route for Host-4 as received by Leaf-101. The route is an EVPN
Route Type 2 and contains both the MAC address and IP address of Host-4. The
route is advertised by Leaf-102, with VTEP address 1.1.102.102.
The VNI 10020/28158 field identifies both the
L2VNI associated with Host-4's VLAN and the L3VNI associated with the tenant
VRF. VNI 10020 identifies VLAN 20 as the host's L2 bridge domain, while VNI
28158 identifies the L3 forwarding context provided by Vrf-NWKT-1.
The Extended Community field contains two
Route Targets: RT:65102:10020 and RT:65102:28158. The first identifies the
L2VNI-related EVPN route, while the second identifies the L3VNI/VRF context.
These Route Targets allow the corresponding EVPN information to be imported
into the appropriate local forwarding contexts.
The route also contains the Router MAC (Rmac)
of Leaf-102: 0c:e8:78:22:00:0a. The Router MAC is required for symmetric IRB
because VXLAN transports an Ethernet frame even when the packet is being
carried between IP routing contexts. The inner Ethernet frame therefore has
source and destination MAC addresses, with the remote VTEP's Router MAC
identifying the remote routing endpoint.
Leaf-101#
show bgp l2vpn
evpn route rd 1.1.1.102:20 mac 00:50:79:66:68:02 ip 10.0.20.102
BGP routing table
entry for 1.1.1.102:20:[2]:[0]:[48]:[00:50:79:66:68:02]:[32]:[10.0.20.102]
Paths: (1
available, best #1)
Advertised to non peer-group peers:
Ethernet0
Route
[2]:[0]:[48]:[00:50:79:66:68:02]:[32]:[10.0.20.102] VNI 10020/28158
65011 65102
1.1.102.102 from Ethernet0 (1.1.1.11)
Origin IGP, valid, external, best (First
path received)
Extended Community: RT:65102:10020
RT:65102:28158 ET:8 Rmac:0c:e8:78:22:00:0a
SubType: 0 Last update: Mon Sep 21
06:24:31 2026
Displayed 1 paths
for requested prefix
Leaf-101#
Example 8-3:
BGP EVPN Route Verification.
Example 8-4 verifies that the MAC address of
Host-4 has been installed in the VLAN 20 MAC address table on Leaf-101. The MAC
address 00:50:79:66:68:02 is marked as dynamic and its VXLAN destination VTEP
is 1.1.102.102.
The entry shows how the EVPN information
received from Leaf-102 has been translated into a local L2 forwarding entry.
VLAN 20 identifies the local bridge domain, while VXLAN destination VTEP
identifies where the remote MAC address can be reached. The associated L2VNI is
VNI 10020, which provides the overlay representation of VLAN 20.
Leaf-101# show
mac address-table Vlan 20
-----------------------------------------------------------
VLAN MAC-ADDRESS TYPE INTERFACE
-----------------------------------------------------------
20
00:50:79:66:68:02 DYNAMIC VxLAN DIP: 1.1.102.102
20 00:50:79:66:68:03 DYNAMIC
Ethernet3
Leaf-101#
Example 8-4:
VLAN 20 MAC Table.
Example 8-5 provides a more focused view of
the remote MAC forwarding information. The output shows the remote MAC
addresses learned through VXLAN together with their destination VTEPs and
associated VNIs.
For Host-4, MAC address 00:50:79:66:68:02 is
associated with VLAN 20, remote VTEP 1.1.102.102, and VNI 10020. This confirms
the forwarding information required to transport a frame destined for Host-4
across the VXLAN overlay.
Leaf-101# show
vxlan remote mac
Vlan Mac Type Tunnel/Intf/NH Group
VNI
==== === ==== =========== =====
===
Vlan10
00:50:79:66:68:01 dynamic 1.1.102.102 internal
10010
Vlan20
00:50:79:66:68:02 dynamic 1.1.102.102 internal
10020
Total count
: 2
Leaf-101#
Example 8-5:
Remote MAC Verification.
Example 8-6 shows the EVPN ARP cache on
Leaf-101. The cache contains both local and remote IP-to-MAC mappings for the
hosts associated with L2VNIs 10010 and 10020.
For Host-4, the entry identifies 10.0.20.102
as a remote address with MAC 00:50:79:66:68:02. The entry also identifies VLAN
20 as the local interface, remote VTEP 1.1.102.102, and remote VNI 10020. The
Mac-only flag indicates that the information is associated with the remote
MAC/IP advertisement.
This EVPN IP-to-MAC information can be used
for ARP suppression. When ARP suppression is enabled, Leaf-101 can use the
information already learned through EVPN to respond to an ARP request locally
instead of forwarding the request as a broadcast across the VXLAN overlay to
the remote VTEP.
Leaf-101# show
evpn arp-cache vni all detail
VNI 10010 #ARP
(IPv4 and IPv6, local and remote) 2
IP: 10.0.10.102
Type: remote
State: active
Uptime: 00:01:00
MAC: 00:50:79:66:68:01
Interface: Vlan10
Sync-info: -
Remote VTEP: 1.1.102.102
Remote VNI: 10010
Flags: Mac-only
Local Seq: 0 Remote Seq: 0
IP: 10.0.10.101
Type: local
State: active
Uptime: 00:24:27
MAC: 00:50:79:66:68:00
Interface: Vlan10
Sync-info: -
Flags: Adv-PIP
Local Seq: 0 Remote Seq: 0
VNI 10020 #ARP (IPv4 and IPv6, local and remote) 2
IP: 10.0.20.102
Type: remote
State: active
Uptime: 00:02:59
MAC: 00:50:79:66:68:02
Interface: Vlan20
Sync-info: -
Remote VTEP: 1.1.102.102
Remote VNI: 10020
Flags: Mac-only
Local Seq: 0 Remote Seq: 0
IP: 10.0.20.101
Type: local
State: active
Uptime: 00:11:48
MAC: 00:50:79:66:68:03
Interface: Vlan20
Sync-info: -
Flags: Adv-PIP
Local Seq: 0 Remote Seq: 0
Leaf-101#
Example 8-6:
EVPN ARP Cache.
Example 8-7 shows the IP routing table of
Vrf-NWKT-1 on Leaf-101. The table contains the connected routes for VLAN 10 and
VLAN 20, as well as host-specific /32 BGP routes learned through EVPN.
For Host-4, the connected route 10.0.20.0/24
exists through Vlan20. However, the more specific BGP route 10.0.20.102/32 is
installed with Leaf-102's VTEP address 1.1.102.102 as the next hop and Vlan77
as the outgoing interface:
B>*
10.0.20.102/32 via 1.1.102.102 Vlan77
Because the /32 route is more specific than
the connected /24 route, traffic destined for Host-4 uses the host-specific
route. The use of Vlan77 as the outgoing interface reflects the L3VNI/VRF
forwarding context rather than the destination host's L2 bridge domain. VNI
28158 provides the VXLAN representation of this L3 forwarding context, while
Vlan20 remains the destination L2 bridge domain associated with Host-4.
This distinction is central to symmetric IRB:
the packet is routed in the tenant VRF and transported between VTEPs using the
L3VNI before the remote VTEP performs the final routing and L2 forwarding
toward the destination VLAN..
Leaf-101# show
ip route vrf Vrf-NWKT-1
Codes: K - kernel route, C - connected, S - static,
B - BGP, O - OSPF
> - selected route, * - FIB route, q
- queued route, r - rejected route
Destination Gateway Dist/Metric Last Update
--------------------------------------------------------------------------------
C>*
10.0.10.0/24 Direct Vlan10 0/0
00:29:10 ago
B>*
10.0.10.102/32 via
1.1.102.102 Vlan77 20/0
00:05:31 ago
C>*
10.0.20.0/24 Direct Vlan20 0/0
00:29:10 ago
B>* 10.0.20.102/32 via 1.1.102.102 Vlan77
20/0 00:07:30 ago
Example 8-7:
VRF IP Route Verification.
The control-plane verification shows how the
L2 and L3 components are connected to form the symmetric IRB forwarding
context. The roles of the main identifiers can be summarized as follows:
VLAN 20: L2 bridge domain for Host-4
VNI 10020: VXLAN representation of VLAN
20
VLAN 77: SVI associated with the
L3/VRF forwarding context
VNI 28158: L3VNI representing
the VRF across the VXLAN overlay
VLAN 20 and VNI 10020 provide the L2 connectivity for Host-4, while
VLAN 77 and VNI 28158 provide the L3/VRF forwarding context used by symmetric
IRB. Together, these components allow the VTEPs to route traffic between L2VNIs
while maintaining the tenant VRF across the VXLAN overlay.
Data Plane Verification
The symmetric IRB forwarding model
can be verified from the VXLAN traffic captured on the underlay link between
the VTEPs. The capture in Example 8-8 was taken on Spine-11 while Host-1 sent ICMP
Echo Requests to Host-4.
The first VXLAN packet is sent from
Leaf-101 (1.1.101.101) to Leaf-102 (1.1.102.102) using VNI 28158:
1.1.101.101 > 1.1.102.102: VXLAN, vni 28158
10.0.10.101
> 10.0.20.102: ICMP echo request
The inner IP packet contains the
original source and destination addresses, while the VXLAN header carries L3VNI
28158. This shows that the packet is transported between the VTEPs using the L3
forwarding context associated with Vrf-NWKT-1, rather than using the
destination L2VNI 10020.
The ICMP Echo Reply follows the same
L3VNI:
1.1.102.102 > 1.1.101.101: VXLAN, vni 28158
10.0.20.102
> 10.0.10.101: ICMP echo reply
Unlike the asymmetric IRB capture,
where the request used VNI 10020 and the reply used VNI 10010, both directions
in this capture use VNI 28158. The L2VNIs therefore no longer determine the VNI
used for inter-VTEP routed transport. Instead, VNI 28158 represents the tenant
VRF across the VXLAN overlay.
The packet capture therefore
provides a direct data-plane verification of symmetric IRB. The forwarding path
can be summarized as:
Host-1 → L3 routing → L3VNI 28158
→ Leaf-102 → L3 routing/L2 forwarding → Host-4
Host-4 → L3 routing → L3VNI 28158
→ Leaf-101 → L3 routing/L2 forwarding → Host-1
The capture confirms the change in
forwarding model introduced by the L3VNI configuration: the same L3VNI is used
in both directions for inter-VTEP traffic, while L2VNIs 10010 and 10020 remain
responsible for the respective VLAN bridge domains at the edges of the overlay.
admin@Spine-11:~$ sudo tcpdump -i Ethernet0 -nn -s0 -vvv -t -c 10 'udp
port 4789'
tcpdump: listening on Ethernet0, link-type EN10MB (Ethernet), snapshot
length 262144 bytes
IP (tos 0x0, ttl 64, id 44027, offset 0, flags [none], proto UDP (17),
length 134)
1.1.101.101.43968 >
1.1.102.102.4789: [udp sum ok] VXLAN, flags [I] (0x08), vni 28158
IP (tos 0x0, ttl 63, id 26365, offset 0, flags [none], proto ICMP (1),
length 84)
10.0.10.101 >
10.0.20.102: ICMP echo request, id 64870, seq 1, length 64
IP (tos 0x0, ttl 63, id 64737, offset 0, flags [none], proto UDP (17),
length 134)
1.1.102.102.60348 >
1.1.101.101.4789: [udp sum ok] VXLAN, flags [I] (0x08), vni 28158
IP (tos 0x0, ttl 63, id 26365, offset 0, flags [none], proto ICMP (1),
length 84)
10.0.20.102 >
10.0.10.101: ICMP echo reply, id 64870, seq 1, length 64
IP (tos 0x0, ttl 64, id 44206, offset 0, flags [none], proto UDP (17),
length 134)
1.1.101.101.43968 >
1.1.102.102.4789: [udp sum ok] VXLAN, flags [I] (0x08), vni 28158
IP (tos 0x0, ttl 63, id 26366, offset 0, flags [none], proto ICMP (1),
length 84)
10.0.10.101 >
10.0.20.102: ICMP echo request, id 65126, seq 2, length 64
IP (tos 0x0, ttl 63, id 64814, offset 0, flags [none], proto UDP (17),
length 134)
1.1.102.102.60348 >
1.1.101.101.4789: [udp sum ok] VXLAN, flags [I] (0x08), vni 28158
IP (tos 0x0, ttl 63, id 26366, offset 0, flags [none], proto ICMP (1),
length 84)
10.0.20.102 >
10.0.10.101: ICMP echo reply, id 65126, seq 2, length 64
Example 8-8:
TCPDUMP from Spine-11.
Figure 8-3 illustrates the data path when Host-1 communicates with
Host-4 using symmetric IRB. Leaf-101 performs an IP route lookup in the
Vrf-NWKT-1 VRF and determines that the destination is reachable through
Leaf-102. The packet is then encapsulated in VXLAN using L3VNI 28158, which
represents the tenant's L3 forwarding context across the VXLAN overlay.
Leaf-102 receives the VXLAN packet, performs the corresponding L3 forwarding
operation, and forwards the packet toward Host-4.
The packet header details shown in the figure illustrate the
separation between the underlay transport and the inner tenant packet. The
outer Ethernet header is used for Layer-2 forwarding across the underlay. Its
source MAC is the Link-Layer Address of the egress interface on Leaf-101, while
its destination MAC is the Link-Layer Address of the next-hop device, Spine-11
in this example. The outer IP header uses the VTEP IP addresses 1.1.101.101 and
1.1.102.102 as source and destination, identifying the VXLAN tunnel endpoints.
UDP destination port 4789 identifies VXLAN, and the VXLAN header carries L3VNI
28158.
The inner Ethernet header belongs to the L3 forwarding context
carried across the VXLAN tunnel. Its source and destination MAC addresses are
the Router MACs of Leaf-101 and Leaf-102, respectively. The inner IP header
retains the original host addresses: source 10.0.10.101 and destination
10.0.20.102. Thus, the outer Ethernet and IP headers provide transport across
the underlay, while the inner Ethernet and IP headers represent the tenant
traffic being forwarded between the VTEPs.
The figure also highlights the key characteristic of symmetric IRB:
the inter-VTEP traffic uses L3VNI 28158 rather than the destination L2VNI
10020. The L2VNIs remain associated with their respective VLAN bridge domains
at the network edges, while L3VNI 28158 provides the L3/VRF forwarding context
between the VTEPs.
Figure 8-3: Symmetric
IRB Data Path.
Database Updates
CONFIG_DB and APPL_DB Updates for L3VNI
Figure 8-4 shows how the L3VNI configuration for symmetric IRB is
represented in CONFIG_DB and subsequently propagated to APPL_DB. Unlike the
VXLAN tunnel and VTEP configuration described in Chapter 7, which is already in
place, the configuration here adds the L3 forwarding context for Vrf-NWKT-1.
The first command, sudo config vlan add 77, creates VLAN 77. This creates the VLAN|Vlan77 entry in CONFIG_DB with vlanid 77. The vlanmgrd daemon consumes the
VLAN configuration and creates the corresponding VLAN_TABLE:Vlan77 entry in APPL_DB. The APPL_DB entry also contains a mac field. This
is the MAC address assigned to the VLAN/bridge-domain object, derived from the
switch's base MAC stored in DEVICE_METADATA|localhost in CONFIG_DB. It is part of the VLAN object's database
representation and is not specific to the L3VNI; it does not represent an IP
address or imply that Vlan77 has an L3 interface. The association of Vlan77
with Vrf-NWKT-1 is represented separately in INTF_TABLE.
The ip vrf Vrf-NWKT-1 command creates the VRF|Vrf-NWKT-1
entry in CONFIG_DB. Its vni field associates L3VNI 28158 with the VRF. The
vrfmgrd daemon consumes the VRF configuration and creates the corresponding VRF_TABLE:Vrf-NWKT-1 entry in APPL_DB, which carries the same VNI association.
The interface Vlan77
configuration creates the VLAN_INTERFACE|Vlan77 entry with vrf_name field set to Vrf-NWKT-1. The intfmgrd daemon
consumes this configuration and creates the corresponding INTF_TABLE:Vlan77 entry in APPL_DB, which carries the same VRF association. This
associates VLAN 77 with the tenant VRF as the local VLAN interface for the L3
forwarding context.
The two VXLAN mapping commands create the L3VNI mappings in
CONFIG_DB. The map vni 28158 vlan 77
command creates the VXLAN_TUNNEL_MAP|vtep_l-101|map_28158_Vlan77 entry, which associates VNI 28158 with Vlan77. VxlanMgr consumes
this configuration and produces the corresponding VXLAN_TUNNEL_MAP_TABLE entry in APPL_DB.
The map vni 28158 vrf Vrf-NWKT-1
command creates the VRF-to-VNI association. VxlanMgr consumes this
configuration and creates the corresponding VXLAN_VRF_TABLE:vtep_l-101:evpn_map_28158_Vrf-NWKT-1
entry in APPL_DB, which associates VNI 28158 with
Vrf-NWKT-1.
Figure 8-4: L3VNI
configuration propagated from CONFIG_DB to APPL_DB.
Figure 8-5 illustrates how the BGP EVPN
MAC/IP Advertisement route for Host-4, shown in Example 8-9, results in
forwarding information being populated in APPL_DB on Leaf-101. Leaf-101
receives the EVPN Type-2 route from Leaf-102 and installs the selected route in
the local BGP table.
BGP
routing table entry for
1.1.1.102:20:[2]:[0]:[48]:[00:50:79:66:68:02]:[32]:[10.0.20.102]
Paths:
(1 available, best #1)
Advertised to non peer-group peers:
Ethernet0
Route
[2]:[0]:[48]:[00:50:79:66:68:02]:[32]:[10.0.20.102] VNI 10020/28158
65011 65102
1.1.102.102 from Ethernet0 (1.1.1.11)
Origin IGP, valid, external, best (First
path received)
Extended Community: RT:65102:10020
RT:65102:28158 ET:8
Rmac:0c:e8:78:22:00:0a
SubType: 0 Last update: Mon Sep 21
06:24:31 2026
Displayed
1 paths for requested prefix
Example 8-9:
BGP Table for Host-4 on Leaf-101.
The route identifies Host-4 by both its MAC address and IP address.
The VNI 10020/28158 information identifies the L2VNI used for Host-4's VLAN and
the L3VNI associated with the tenant VRF. The extended communities contain the
corresponding route targets, while the Rmac field identifies the Router MAC
advertised by Leaf-102.
After BGP best-path selection, Zebra installs the selected routing
information into the Linux networking stack. SONiC synchronization daemons then
reflect the relevant state into APPL_DB. For the remote MAC information,
fdbsyncd populates VXLAN_FDB_TABLE, which is consumed by FdbOrch. For the
remote MAC/IP information, neighsyncd populates NEIGH_TABLE, which is consumed
by NeighOrch. Routing information is synchronized to APPL_DB by fpmsyncd,
providing the route and next-hop information used by the forwarding pipeline.
The VXLAN_FDB_TABLE:Vlan20:00:50:79:66:68:02 entry describes
Host-4's remote Layer-2 reachability:
remote_vtep:
1.1.102.102
type: dynamic
vni: 10020
The entry associates Host-4's MAC address with the remote VTEP and
L2VNI 10020. FdbOrch consumes this entry and uses it to program the remote MAC
forwarding information. The L2VNI is therefore used for forwarding traffic
within the VLAN 20 bridge domain, while L3VNI 28158 is used when the packet is
routed between VXLAN segments.
The NEIGH_TABLE:Vlan77:1.1.102.102 entry provides the Layer-2
adjacency information for the remote VTEP:
neigh: 0c:e8:78:22:00:0a
remote:
1
Here, 1.1.102.102 identifies the remote VTEP, while
0c:e8:78:22:00:0a is the Router MAC advertised by Leaf-102. The neighsyncd
daemon populates this entry from the remote MAC/IP information installed by
Zebra in the Linux neighbor table. The entry therefore provides the neighbor
resolution required to reach the remote VTEP through the Vlan77/L3VNI
forwarding context.
The ROUTE_TABLE:Vrf-NWKT-1:10.0.20.102/32 entry represents the host
route within the tenant VRF:
genid: 0
nexthop_group: 22
router_mac:
vni_label:
The route identifies 10.0.20.102/32 as a destination in the
Vrf-NWKT-1 VRF. Its nexthop_group attribute points to NEXT_HOP_GROUP_TABLE
entry 22. This reference connects the destination IP route to the overlay
next-hop information required to reach Host-4. The route itself does not
contain the remote VTEP, Router MAC, or L3VNI; those attributes are provided by
the referenced next-hop group.
The NEXT_HOP_GROUP_TABLE:22 entry combines the information required
for the overlay next hop:
ifname: Vlan77
nexthop: 1.1.102.102
rmac: 0c:e8:78:22:00:0a
vni_label: 28158
The entry identifies Vlan77 as the local forwarding interface,
1.1.102.102 as the remote VTEP, and 0c:e8:78:22:00:0a as the remote Router MAC.
The vni_label field identifies L3VNI 28158. Together, these values describe the
overlay next hop used for routed traffic.
The route for Host-4 therefore resolves to an overlay next hop that
specifies the remote VTEP, the remote Router MAC, and the L3VNI used for
symmetric IRB forwarding.
Figure 8-5 brings these database entries together to show the
forwarding information created from the received EVPN route. The
VXLAN_FDB_TABLE entry provides Host-4's remote Layer-2 reachability through
L2VNI 10020. The NEIGH_TABLE entry provides the Router MAC associated with the
remote VTEP, while the ROUTE_TABLE and NEXT_HOP_GROUP_TABLE entries connect the
destination IP address to the overlay next hop using Vlan77, remote VTEP
1.1.102.102, Router MAC 0c:e8:78:22:00:0a, and L3VNI 28158.
The APPL_DB entries shown in Figure 8-5 represent the forwarding
information derived from the received EVPN route. The next step is to translate
this information into the SAI objects required by the hardware forwarding
pipeline. The following section examines how FdbOrch, NeighOrch, and RouteOrch
consume these APPL_DB entries and create the corresponding FDB, neighbor,
next-hop, and route objects in ASIC_DB.
Figure 8-5: VPN
route information propagated from BGP to APPL_DB.
ASIC_DB
In this section, we examine the ASIC_DB objects
related to the reachability of Host-4 at IP address 10.0.20.102. The section is
divided into three parts, each centered around the ROUTE_ENTRY and NEXT_HOP
objects associated with destination 10.0.20.102. The complete ASIC_DB objects
are included in each part.
First, we examine how the ROUTE_ENTRY object is
associated with the VRF Vrf-NWKT-1 and the VLAN 77 router interface, which
provides the L3 interface for inter-subnet routing within the VRF.
The virtual_router (VR) attribute of the ROUTE_ENTRY
associates the route with the virtual router for Vrf-NWKT-1 (1). Its
NEXT_HOP_ID attribute points to the NEXT_HOP object that defines how the
destination is reached (2). The NEXT_HOP object references a VLAN-type
ROUTER_INTERFACE through its TUNNEL_ROUTER_INTERFACE_ID attribute (3). This
ROUTER_INTERFACE is associated with the same virtual router through its
VIRTUAL_ROUTER_ID attribute and with VLAN 77 through its VLAN_ID attribute (4).
The VLAN object then identifies the VLAN as VLAN 77 (5).
The SRC_MAC_ADDRESS attribute of the ROUTER_INTERFACE
identifies Leaf-101's router/system MAC (RMAC), 0C:CB:81:19:00:0A (6). This is
the same router MAC carried in EVPN BGP UPDATE messages in the Router's MAC
extended community and used as the inner Ethernet destination MAC when an
inter-VNI VXLAN packet is sent toward Leaf-101. Thus, these ASIC_DB objects
connect the destination route to Vrf-NWKT-1, VLAN 77, and the local router MAC
used by the VXLAN routing pipeline.
Examples 8-10, 8-11, 8-12, and 8-13 show the complete
ROUTE_ENTRY, NEXT_HOP, ROUTER_INTERFACE, and VLAN objects, respectively.
Figure 8-6: ASIC_DB:
Remote Host-4 10.0.20.102 Reachability - Part 1.
ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY:
{\"dest\":\"10.0.20.102/32\",\"switch_id\":\"oid:0x21000000000000\",\"vr\":\"oid:0x3000000000a4f\"}":
{
"expireat":
1789972391.8942273,
"ttl": -0.001,
"type":
"hash",
"value": {
"SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID":
"oid:0x4000000000aa9"
Example 8-10: ASIC_DB: ROUTE_ENTRY.
"ASIC_STATE:SAI_OBJECT_TYPE_NEXT_HOP:oid:0x4000000000aa9":
{
"expireat":
1789972391.8986993,
"ttl": -0.001,
"type":
"hash",
"value": {
"SAI_NEXT_HOP_ATTR_IP": "1.1.102.102",
"SAI_NEXT_HOP_ATTR_TUNNEL_ID":
"oid:0x2a000000000a5c",
"SAI_NEXT_HOP_ATTR_TUNNEL_MAC": "0C:E8:78:22:00:0A",
"SAI_NEXT_HOP_ATTR_TUNNEL_ROUTER_INTERFACE_ID":
"oid:0x6000000000a9e",
"SAI_NEXT_HOP_ATTR_TUNNEL_VNI": "28158",
"SAI_NEXT_HOP_ATTR_TYPE":
"SAI_NEXT_HOP_TYPE_TUNNEL_ENCAP"
Example 8-11: ASIC_DB: NEXT_HOP.
"ASIC_STATE:SAI_OBJECT_TYPE_ROUTER_INTERFACE:oid:0x6000000000a9e":
{
"expireat":
1789972391.8881423,
"ttl": -0.001,
"type":
"hash",
"value": {
"SAI_ROUTER_INTERFACE_ATTR_MTU": "9100",
"SAI_ROUTER_INTERFACE_ATTR_NAT_ZONE_ID": "0",
"SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS":
"0C:CB:81:19:00:0A",
"SAI_ROUTER_INTERFACE_ATTR_TYPE":
"SAI_ROUTER_INTERFACE_TYPE_VLAN",
"SAI_ROUTER_INTERFACE_ATTR_V4_MCAST_ENABLE":
"false",
"SAI_ROUTER_INTERFACE_ATTR_VIRTUAL_ROUTER_ID":
"oid:0x3000000000a4f",
"SAI_ROUTER_INTERFACE_ATTR_VLAN_ID":
"oid:0x26000000000a4a"
Example 8-12: ASIC_DB: ROUTER_INTERFACE (VLAN INTERFACE).
"ASIC_STATE:SAI_OBJECT_TYPE_VLAN:oid:0x26000000000a4a":
{
"expireat":
1789972391.8985667,
"ttl": -0.001,
"type":
"hash",
"value": {
"SAI_VLAN_ATTR_VLAN_ID": "77"
Example 8-13: ASIC_DB: VLAN.
The NEXT_HOP object for destination 10.0.20.102/32 contains the
remote VTEP IP address 1.1.102.102 (1), identifying Leaf-102 as the VXLAN
tunnel endpoint for the destination. To forward the VXLAN packet toward this
VTEP, Leaf-101 must resolve 1.1.102.102 through the underlay network.
The ROUTE_ENTRY object for 1.1.102.102/32 is associated with the
default VRF virtual router (2), which is used for underlay network forwarding.
Its NEXT_HOP_ID attribute points to a NEXT_HOP object (3). This NEXT_HOP object
contains the IPv6 link-local address fe80::e22:34ff:feb6:a (4), which
identifies the directly connected underlay next hop toward Spine-11. Its
ROUTER_INTERFACE_ID attribute references the ROUTER_INTERFACE object (5), whose
PORT_ID attribute points to the PORT object (6). The PORT object contains the
administrative state and physical interface parameters, including MTU, speed,
and port VLAN ID. The PORT object is also referenced by the HOSTIF object
through its OBJ_ID attribute (7), which identifies the operational interface as
Ethernet0 (8).
The SRC_MAC_ADDRESS attribute of the ROUTER_INTERFACE object
identifies the MAC address used on the Ethernet0 inter-switch link to Spine-11
(9). This MAC address is used as the source MAC address in the outer Ethernet
header of VXLAN packets sent from Leaf-101 toward the underlay. The
ROUTER_INTERFACE object's VIRTUAL_ROUTER_ID attribute (10) references the same
default VRF virtual router as the ROUTE_ENTRY object for 1.1.102.102/32.
The ASIC_DB objects therefore provide the forwarding information
required to resolve the remote VTEP 1.1.102.102 through the underlay: the VXLAN
packet is sent toward VTEP 1.1.102.102 through the underlay next hop
fe80::e22:34ff:feb6:a, using Leaf-101's Ethernet0 interface and its associated
source MAC address.
Figure 8-7: ASIC_DB:
Remote Host-4 10.0.20.102 Reachability - Part 2.
"ASIC_STATE:SAI_OBJECT_TYPE_NEXT_HOP:oid:0x4000000000aa9":
{
"expireat":
1789972391.8986993,
"ttl": -0.001,
"type":
"hash",
"value": {
"SAI_NEXT_HOP_ATTR_IP": "1.1.102.102",
"SAI_NEXT_HOP_ATTR_TUNNEL_ID":
"oid:0x2a000000000a5c",
"SAI_NEXT_HOP_ATTR_TUNNEL_MAC": "0C:E8:78:22:00:0A",
"SAI_NEXT_HOP_ATTR_TUNNEL_ROUTER_INTERFACE_ID":
"oid:0x6000000000a9e",
"SAI_NEXT_HOP_ATTR_TUNNEL_VNI": "28158",
"SAI_NEXT_HOP_ATTR_TYPE":
"SAI_NEXT_HOP_TYPE_TUNNEL_ENCAP"
Example 8-14: ASIC_DB: NEXT_HOP.
"ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY:{
\"dest\":\"1.1.102.102/32\",
\"switch_id\":\"oid:0x21000000000000\",
\"vr\":\"oid:0x300000000003a\"}":
{
"value": {
"SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID": " oid:0x4000000000a7b",
Example 8-15: ASIC_DB: ROUTE_ENTRY.
"ASIC_STATE:SAI_OBJECT_TYPE_NEXT_HOP:oid:0x4000000000a7b":
{
"expireat":
1789972391.8988996,
"ttl": -0.001,
"type":
"hash",
"value": {
"SAI_NEXT_HOP_ATTR_IP": "fe80::e22:34ff:feb6:a",
"SAI_NEXT_HOP_ATTR_ROUTER_INTERFACE_ID":
"oid:0x6000000000a50",
"SAI_NEXT_HOP_ATTR_TYPE": "SAI_NEXT_HOP_TYPE_IP"
Example 8-16: ASIC_DB: NEXT_HOP.
"ASIC_STATE:SAI_OBJECT_TYPE_ROUTER_INTERFACE:oid:0x6000000000a50":
{
"expireat": 1789972391.8909495,
"ttl": -0.001,
"type": "hash",
"value": {
"SAI_ROUTER_INTERFACE_ATTR_MTU": "9100",
"SAI_ROUTER_INTERFACE_ATTR_NAT_ZONE_ID": "0",
"SAI_ROUTER_INTERFACE_ATTR_PORT_ID":
"oid:0x1000000000002",
"SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS":
"0C:CB:81:19:00:0A",
"SAI_ROUTER_INTERFACE_ATTR_TYPE":
"SAI_ROUTER_INTERFACE_TYPE_PORT",
"SAI_ROUTER_INTERFACE_ATTR_V4_MCAST_ENABLE":
"false",
"SAI_ROUTER_INTERFACE_ATTR_VIRTUAL_ROUTER_ID":
"oid:0x300000000003a"
Example 8-17: ASIC_DB: ROUTER_INTERFACE.
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000002":
{
"expireat": 1789972391.886979,
"ttl": -0.001,
"type": "hash",
"value": {
"NULL": "NULL",
"SAI_PORT_ATTR_ADMIN_STATE":
"true",
"SAI_PORT_ATTR_MTU":
"9122",
"SAI_PORT_ATTR_PORT_VLAN_ID":
"4095", (Comment: Routed - Unnumbered LLA)
"SAI_PORT_ATTR_SPEED":
"25000"
Example 8-18: ASIC_DB: PORT.
"ASIC_STATE:SAI_OBJECT_TYPE_HOSTIF:oid:0xd0000000009ea":
{
"expireat": 1789972391.88833,
"ttl": -0.001,
"type": "hash",
"value": {
"SAI_HOSTIF_ATTR_NAME": "Ethernet0",
"SAI_HOSTIF_ATTR_OBJ_ID": "oid:0x1000000000002",
"SAI_HOSTIF_ATTR_OPER_STATUS": "true",
Example 8-19: ASIC_DB: HOSTIF.
The TUNNEL_MAC attribute (1) in the NEXT_HOP
object contains the router MAC (Rmac) of Leaf-102. This MAC address was learned
through the EVPN BGP UPDATE message for 10.0.20.102/32, where it is carried in
the Router's MAC extended community. Leaf-101 uses this MAC address as the
destination MAC address of the inner Ethernet header when sending the
VXLAN-encapsulated packet toward Leaf-102. The TUNNEL_VNI attribute identifies
the L3VNI, 28158, carried in the VXLAN header for inter-subnet communication.
The TUNNEL_ID attribute (3) references the
TUNNEL object. The TUNNEL object's ENCAP_MAPPERS attribute references to the
TUNNEL_MAP objects used for the VLAN-to-VNI and VNI-to-VRF mappings required by
the VXLAN tunnel (4, 5). The corresponding TUNNEL_MAP objects identify the
VLAN-to-VNI and VNI-to-VRF mappings used for VXLAN encapsulation.
The ENCAP_SRC_IP attribute (6) of the TUNNEL
object specifies 1.1.101.101 as the VXLAN tunnel source IP address. This is the
VTEP IP address configured on Leaf-101's VXLAN interface. The TUNNEL object's
UNDERLAY_INTERFACE attribute references a LOOPBACK ROUTER_INTERFACE object,
whose VIRTUAL_ROUTER_ID associates it with the default VRF.
Together, these ASIC_DB objects define the
VXLAN encapsulation information required for destination 10.0.20.102/32: the
remote router MAC for the inner Ethernet destination, the L3VNI carried in the
VXLAN header, the tunnel source VTEP address, and the tunnel mapping
information used for VXLAN encapsulation.
Combined with the objects examined in the
previous two sections, they form the ASIC_DB forwarding information for
destination 10.0.20.102/32 on Leaf-101. The forwarding information identifies
the source and destination MAC addresses of the outer and inner Ethernet
headers, the source and destination VTEP IP addresses of the VXLAN outer IP
header, and the underlay next hop used to reach the remote VTEP. The inner IP
header retains the original source and destination host addresses, while the
outer IP header carries the VTEP addresses used for VXLAN transport. The remote
VTEP address is recursively resolved through the underlay routing table to the
directly connected next hop toward Spine-11.
Figure 8-8: ASIC_DB:
Remote Host-4 10.0.20.102 Reachability - Part 3.
"ASIC_STATE:SAI_OBJECT_TYPE_NEXT_HOP:oid:0x4000000000aa9":
{
"expireat":
1789972391.8986993,
"ttl": -0.001,
"type":
"hash",
"value": {
"SAI_NEXT_HOP_ATTR_IP": "1.1.102.102",
"SAI_NEXT_HOP_ATTR_TUNNEL_ID":
"oid:0x2a000000000a5c",
"SAI_NEXT_HOP_ATTR_TUNNEL_MAC": "0C:E8:78:22:00:0A",
"SAI_NEXT_HOP_ATTR_TUNNEL_ROUTER_INTERFACE_ID":
"oid:0x6000000000a9e",
"SAI_NEXT_HOP_ATTR_TUNNEL_VNI": "28158",
"SAI_NEXT_HOP_ATTR_TYPE":
"SAI_NEXT_HOP_TYPE_TUNNEL_ENCAP"
Example 8-20: ASIC_DB: NEXT_HOP.
"ASIC_STATE:SAI_OBJECT_TYPE_TUNNEL:oid:0x2a000000000a5c":
{
"expireat": 1789972391.8919196,
"ttl": -0.001,
"type": "hash",
"value": {
"SAI_TUNNEL_ATTR_DECAP_DSCP_MODE":
"SAI_TUNNEL_DSCP_MODE_PIPE_MODEL",
"SAI_TUNNEL_ATTR_DECAP_MAPPERS":
"2:oid:0x29000000000a58,oid:0x29000000000a5a",
"SAI_TUNNEL_ATTR_ENCAP_DSCP_MODE":
"SAI_TUNNEL_DSCP_MODE_PIPE_MODEL",
"SAI_TUNNEL_ATTR_ENCAP_DSCP_VAL": "0",
"SAI_TUNNEL_ATTR_ENCAP_MAPPERS":
"2:oid:0x29000000000a59,oid:0x29000000000a5b",
"SAI_TUNNEL_ATTR_ENCAP_SRC_IP":
"1.1.101.101",
"SAI_TUNNEL_ATTR_ENCAP_TTL_MODE":
"SAI_TUNNEL_TTL_MODE_PIPE_MODEL",
"SAI_TUNNEL_ATTR_ENCAP_TTL_VAL": "255",
"SAI_TUNNEL_ATTR_PEER_MODE":
"SAI_TUNNEL_PEER_MODE_P2MP",
"SAI_TUNNEL_ATTR_TYPE":
"SAI_TUNNEL_TYPE_VXLAN",
"SAI_TUNNEL_ATTR_UNDERLAY_INTERFACE":
"oid:0x60000000009c7"
Example 8-21: ASIC_DB: TUNNEL.
"ASIC_STATE:SAI_OBJECT_TYPE_TUNNEL_MAP:oid:0x29000000000a59":
{
"expireat": 1789972391.8899891,
"ttl": -0.001,
"type": "hash",
"value": {
"SAI_TUNNEL_MAP_ATTR_TYPE":
"SAI_TUNNEL_MAP_TYPE_VLAN_ID_TO_VNI"
Example 8-22: ASIC_DB: TUNNEL_MAP (oid: 0x29000000000a59).
"ASIC_STATE:SAI_OBJECT_TYPE_TUNNEL_MAP:oid:0x29000000000a5b":
{
"expireat": 1789972391.8866813,
"ttl": -0.001,
"type": "hash",
"value": {
"SAI_TUNNEL_MAP_ATTR_TYPE":
"SAI_TUNNEL_MAP_TYPE_VIRTUAL_ROUTER_ID_TO_VNI"
Example 8-23: ASIC_DB: TUNNEL_MAP (oid:0x29000000000a5a).
"ASIC_STATE:SAI_OBJECT_TYPE_ROUTER_INTERFACE:oid:0x60000000009c7":
{
"expireat": 1789972391.9131432,
"ttl": -0.001,
"type": "hash",
"value": {
"SAI_ROUTER_INTERFACE_ATTR_MTU": "9100",
"SAI_ROUTER_INTERFACE_ATTR_TYPE":
"SAI_ROUTER_INTERFACE_TYPE_LOOPBACK",
"SAI_ROUTER_INTERFACE_ATTR_VIRTUAL_ROUTER_ID":
"oid:0x300000000003a"
Example 8-24: ASIC_DB: ROUTER_INTERFACE (UNDERLAY_INTERFACE).
