On OcNOS 7.0.1 a VTEP is configured in four committed steps with no reboot. On a running fabric, show bgp l2vpn evpn summary, show nvo vxlan tunnel, show nvo vxlan mac-table and show evpn esi all confirm, in that order, that a MAC address learned on another leaf is programmed locally.
OcNOS 7.0 supports VXLAN-EVPN on service provider routers and data center switches, using the same BGP EVPN control plane as EVPN-MPLS. This post first configures a VTEP on an OcNOS 7.0.1 router, then examines a working three-leaf EVPN-VXLAN fabric and two OcNOS routers exchanging EVPN routes with symmetric IRB. It covers EVPN sessions and route types, tunnels to remote VTEPs, MAC and ARP entry programming, multihoming, and how to trace a MAC address from its EVPN route to the forwarding table.
All commands and output are from the IP Infusion lab: a UfiSpace S9600-56DX router on OcNOS-SP-PLUS 7.0.1 (captured 20 August 2026 and re-run on 2 October 2026), a UfiSpace S8901-54XC leaf on OcNOS-DC-PLUS 7.0.1 (captured 26 August 2026), and a UfiSpace S9600-28DX router on OcNOS-SP-PLUS 7.0.2 (captured 7 October 2026).
In short: configuring a VTEP takes four committed steps and no reboot. On a running fabric, show bgp l2vpn evpn summary, show nvo vxlan tunnel, show nvo vxlan mac-table and show evpn esi all show, in that order, whether a MAC address learned on another leaf is programmed on this one.
Part 1: Configure a VTEP on an OcNOS 7.0 Router
Step 1: Enable the VXLAN Hardware Profile, Then VXLAN
On this platform VXLAN uses a TCAM filter group. From configuration mode (configure terminal), enable the filter group first, then VXLAN, and commit both together. Neither asks for a reload:
hardware-profile filter vxlan enable
nvo vxlan enable
commit
If nvo vxlan enable is committed without the filter group, the commit fails with a message that names the missing step:
%% please enable hardware-profile filter vxlan group first - /vxlan/global/config/enable-vxlan
%% nsm config validation failed
% Failed to commit .. As error(s) encountered during commit operation...
Uncommitted configurations are retained in the current transaction session, check 'show transaction current'.
Correct the reason for the failure and re-issue the commit.
Use 'abort transaction' to terminate current transaction session and discard all uncommitted changes.
Trying this on the free OcNOS demo VM: the VM (OcNOS-SP-PLUS 7.0.0, x86) has no TCAM filter group, so it answers hardware-profile filter vxlan enable with % Invalid input detected at '^' marker. Skip that line and commit nvo vxlan enable on its own. Steps 2 to 4 then work as shown, with a VM data port such as eth1 in place of ce40. We ran them on the demo VM on 7 October 2026.
Step 2: Set the VTEP Address and Create the VNI
The VTEP source is a loopback address. The VNI is created with ingress replication for BUM traffic:
interface loopback2
ip address 172.31.0.211/32
exit
nvo vxlan vtep-ip-global 172.31.0.211
nvo vxlan id 10100 ingress-replication
commit
exit
Step 3: Bind an Access Sub-Interface to the VNI
The attachment circuit is a switchport sub-interface. access-if-evpn becomes available once the encapsulation is set, and inside it the VNI is referenced as the VPN-ID:
interface ce40.3099 switchport
encapsulation dot1q 3099
access-if-evpn
map vpn-id 10100
commit
The resulting running configuration:
!
interface ce40.3099 switchport
encapsulation dot1q 3099
access-if-evpn
map vpn-id 10100
!
Step 4: Verify
Run these from the # prompt after end, or from any configuration mode with do in front, for example do show nvo vxlan.
show nvo vxlan lists the access port (AC) against its VNI:
VXLAN Information
=================
Codes: NW - Network Port
AC - Access Port
(u) - Untagged
VNID VNI-Name VNI-Type Type Interface ESI VLAN DF-Status Src-Addr Dst-Addr Router-Mac
_______________________________________________________________________________________________________________________________________________
10100 ---- -- AC ce40.3099 --- Single Homed Port --- ---- ---- ---- ----
Total number of entries are 1
Note: Refer sub-interface config for VLAN information.
show nvo vxlan access-if brief shows the binding with its admin and link state (port ce40 was down on the lab router, so the link status reads down):
Inner Admin Link
Interface Vlan vlan Ifindex Vnid status status
---------------------------------------------------------------
ce40.3099 --- --- 0x13a88c1b 10100 up down
Total number of entries are 1
show nvo vxlan route-count reports the platform’s VXLAN route capacity:
VXLAN Active route count information
====================================
Max supported route count : 131072
Other verification commands on OcNOS 7.0.1 routers include show nvo vxlan tunnel, show nvo vxlan vni-tunnel, show nvo vxlan mac-table, show evpn l3vni-map and show evpn irb-status.
Part 2: Inside a Working Three-Leaf EVPN-VXLAN Fabric
The output in Part 2 comes from one leaf (Leaf 2) of a three-leaf OcNOS-DC fabric. Each leaf is a VTEP, and Leaf 2 peers in BGP EVPN with the other two. Two VNIs, 10010 and 10020, carry VLANs 10 and 20, and servers attach over multihomed port-channels. Addresses, VNIs, VLANs, interface names and MAC addresses are changed from the lab capture; the structure, counters and timers are as captured.
| Leaf | VTEP address | Ethernet segments it serves |
|---|---|---|
| Leaf 1 | 10.10.100.11 | 10, 20, 30 |
| Leaf 2 (shown) | 10.10.100.12 | 10, 30 |
| Leaf 3 | 10.10.100.13 | 20 |
Are the EVPN sessions up, and which routes do they carry?
show bgp l2vpn evpn summary lists each EVPN neighbor with its state and a count per EVPN route type:
BGP router identifier 10.10.100.12, local AS number 65000
BGP table version is 3
1 BGP AS-PATH entries
0 BGP community entries
Neighbor V AS MsgRcv MsgSen TblVer InQ OutQ Up/Down State/PfxRcd AD MACIP MCAST ESI PREFIX-ROUTE Desc
10.10.100.11 4 65000 1370 1356 1 0 0 09:36:49 21 7 12 2 0 0
10.10.100.13 4 65000 1364 1351 2 0 0 09:36:09 23 7 14 2 0 0
Total number of neighbors 2
Total number of Established sessions 2
Both sessions are established and had been up for more than nine hours. The columns map to the EVPN route types: AD is Ethernet auto-discovery (Type 1), MACIP is MAC and IP advertisement (Type 2), MCAST is inclusive multicast (Type 3, used to build the flooding list for each VNI), ESI is the Ethernet segment route (Type 4) and PREFIX-ROUTE is Type 5. This fabric bridges only, so it carries no Type 5 routes.
Does every VNI have a tunnel to every remote VTEP?
show nvo vxlan vni-tunnel lists the remote VTEPs per VNI, and show nvo vxlan tunnel shows the state of each tunnel:
VNID Tunnel-endpoints
__________________________________________________________
10010 10.10.100.11, 10.10.100.13
10020 10.10.100.11, 10.10.100.13
Total number of entries are 2
VXLAN Network tunnel Entries
Source Destination Status Up/Down Update
========================================================================
10.10.100.12 10.10.100.13 Installed 09:34:55 09:34:55
10.10.100.12 10.10.100.11 Installed 09:35:35 09:35:35
Total number of entries are 2
Each VNI has a tunnel to both remote leaves, and both tunnels are installed. A remote VTEP that is missing from vni-tunnel usually means its Type 3 route did not arrive, so the MCAST count in the BGP summary is the next thing to check.
Are MAC addresses programmed?
show nvo vxlan mac-table lists the MAC addresses in each VNI and what each one points to:
=================================================================================================================================================================
VXLAN MAC Entries
=================================================================================================================================================================
VNID Interface VlanId In-VlanId Mac-Addr VTEP-Ip/ESI Type Status MAC move AccessPortDesc LeafFlag
_________________________________________________________________________________________________________________________________________________________________
10010 ---- ---- ---- 0000.5e00.5301 00:00:00:00:00:00:10:00:00:00 Dynamic Remote ------- 0 ------- ----
10010 ---- ---- ---- 0000.5e00.5302 00:00:00:00:00:00:30:00:00:00 Dynamic Remote ------- 0 ------- ----
10020 ---- ---- ---- 0000.5e00.5301 00:00:00:00:00:00:20:00:00:00 Dynamic Remote ------- 2 ------- ----
10020 ---- ---- ---- 0000.5e00.5302 00:00:00:00:00:00:30:00:00:00 Dynamic Remote ------- 0 ------- ----
Total number of entries are : 4
All four entries were learned remotely through EVPN, rather than on a local port. Each points to an Ethernet segment instead of a single VTEP address because the hosts sit behind multihomed links. The MAC move column counts how often an address has moved; one entry in VNI 10020 shows 2.
The IP to MAC bindings learned through EVPN are shown by show nvo vxlan arp-cache:
VXLAN ARP-CACHE Information
===========================
VNID Ip-Addr Mac-Addr Type Age-Out Retries-Left
_______________________________________________________________________________________
10010 192.0.2.1 0000.5e00.5301 Dynamic Remote ----
10010 192.0.2.2 0000.5e00.5302 Dynamic Remote ----
10010 192.0.2.3 0000.5e00.5302 Dynamic Remote ----
10020 198.51.100.1 0000.5e00.5301 Dynamic Remote ----
10020 198.51.100.2 0000.5e00.5302 Dynamic Remote ----
10020 198.51.100.3 0000.5e00.5302 Dynamic Remote ----
Total number of entries are 6
How does multihoming appear?
Each multihomed port-channel carries an Ethernet segment identifier (ESI). show evpn esi all lists each segment and the leaves serving it. show evpn multi-homing all shows which local interface belongs to each segment:
ESI PE-list
===========================================================
00:00:00:00:00:00:10:00:00:00 10.10.100.11, 10.10.100.12
00:00:00:00:00:00:20:00:00:00 10.10.100.11, 10.10.100.13
00:00:00:00:00:00:30:00:00:00 10.10.100.11, 10.10.100.12
Total number of entries are 3
ESI Access-IF PE-IP-ADDRESS
===========================================================
00:00:00:00:00:00:10:00:00:00 ---- 10.10.100.11
00:00:00:00:00:00:10:00:00:00 po10 10.10.100.12
00:00:00:00:00:00:20:00:00:00 ---- 10.10.100.11
00:00:00:00:00:00:20:00:00:00 ---- 10.10.100.13
00:00:00:00:00:00:30:00:00:00 ---- 10.10.100.11
00:00:00:00:00:00:30:00:00:00 po30 10.10.100.12
Total number of entries are 6
Leaf 2 shares segments 10 and 30 with Leaf 1 on its local port-channels po10 and po30. Segment 20 is served by Leaf 1 and Leaf 3 and has no local interface on Leaf 2. show nvo vxlan brings the pieces together, with the network ports (NW) toward each remote VTEP and the access ports (AC) with their ESI and designated forwarder status:
VXLAN Information
=================
Codes: NW - Network Port
AC - Access Port
(u) - Untagged
VNID VNI-Name VNI-Type Type Interface ESI VLAN DF-Status Src-Addr Dst-Addr Router-Mac
_______________________________________________________________________________________________________________________________________________
10010 ---- L2 NW ---- ---- ---- ---- 10.10.100.12 10.10.100.13 --------------
10010 ---- L2 NW ---- ---- ---- ---- 10.10.100.12 10.10.100.11 --------------
10010 ---- -- AC po10 00:00:00:00:00:00:10:00:00:00 10 NON-DF ---- ----
10010 ---- -- AC po30 00:00:00:00:00:00:30:00:00:00 10 NON-DF ---- ----
10020 ---- L2 NW ---- ---- ---- ---- 10.10.100.12 10.10.100.13 --------------
10020 ---- L2 NW ---- ---- ---- ---- 10.10.100.12 10.10.100.11 --------------
10020 ---- -- AC po10 00:00:00:00:00:00:10:00:00:00 20 NON-DF ---- ----
10020 ---- -- AC po30 00:00:00:00:00:00:30:00:00:00 20 NON-DF ---- ----
Total number of entries are 8
Leaf 2 is NON-DF on both of its local segments. In EVPN, one leaf per segment is elected designated forwarder and sends broadcast, unknown unicast and multicast traffic to the segment, so Leaf 1 holds that role for segments 10 and 30.
Part 3: Two OcNOS Routers Exchanging EVPN Routes
Part 3 shows two OcNOS routers peering over one link. Each router is a VTEP with an IRB gateway in an IP VRF. They use symmetric IRB with L3VNI 20100 and peer in BGP EVPN. The output comes from the near-end router, a UfiSpace S9600-28DX on OcNOS-SP-PLUS 7.0.2 in the IP Infusion lab, captured on 7 October 2026. The far end was a second OcNOS router running a pre-release build, so its output is not shown. The AS numbers, router ID and MAC addresses are changed from the capture.
This part shows the control plane: the EVPN session, the routes it carries, and the MAC and ARP entries those routes program on the router.
The near-end configuration
Each block below was entered from configuration mode and committed on its own, in this order:
interface ce20.3998
encapsulation dot1q 3998
ip address 10.255.98.1/30
commit
interface loopback8
ip address 10.255.0.10/32
commit
ip route 10.255.0.12/32 10.255.98.2
commit
hardware-profile filter vxlan enable
nvo vxlan enable
commit
nvo vxlan vtep-ip-global 10.255.0.10
nvo vxlan irb
commit
mac vrf VXB2
rd 10.255.0.10:100
route-target both 65000:100
commit
ip vrf VXB2L3
rd 10.255.0.10:200
route-target both 65000:200
l3vni 20100
commit
interface irb10100
ip vrf forwarding VXB2L3
ip address 192.0.2.1/24
commit
nvo vxlan id 10100 ingress-replication
vxlan host-reachability-protocol evpn-bgp VXB2
evpn irb10100
commit
router bgp 65010
neighbor 10.255.0.12 remote-as 65012
neighbor 10.255.0.12 update-source loopback8
neighbor 10.255.0.12 ebgp-multihop 5
address-family l2vpn evpn
neighbor 10.255.0.12 activate
exit-address-family
commit
Two rules apply when committing this configuration on the router:
- Binding an IRB to the VNI with
evpn irb10100requires the IRB interface to be in an IP VRF that has an L3VNI. Without that, the commit is refused with%% L3VNID does not exist or ip-vrf not mapped to IRB interface. nvo vxlan irbmust be committed before the IP VRF with itsl3vni. In the other order, the commit is refused with%% EVPN-IRB is not Enabled.
Is the EVPN session up?
BGP router identifier 10.255.0.10, local AS number 65010
BGP table version is 4
2 BGP AS-PATH entries
0 BGP community entries
Neighbor V AS MsgRcv MsgSen TblVer InQ OutQ Up/Down State/PfxRcd AD MACIP MCAST ESI PREFIX-ROUTE Desc
10.255.0.12 4 65012 13 12 4 0 0 00:03:42 3 0 2 1 0 0
Total number of neighbors 1
Total number of Established sessions 1
The session to the far end is established. It carries 2 MAC/IP routes (Type 2), one for the far end’s gateway IPv4 address and one for its IPv6 link-local address, and 1 inclusive multicast route (Type 3) for the VNI.
Is the tunnel installed?
VXLAN Network tunnel Entries
Source Destination Status Up/Down Update
========================================================================
10.255.0.10 10.255.0.12 Installed 00:03:43 00:03:43
Total number of entries are 1
VNID Tunnel-endpoints
__________________________________________________________
10100 10.255.0.12
20100
Total number of entries are 2
L3VNI L2VNI IRB-interface
========================================
20100 10100 irb10100
The tunnel to the far-end VTEP is installed, VNI 10100 lists it as an endpoint, and L3VNI 20100 is mapped to VNI 10100 through irb10100.
Which MAC and ARP entries do the routes program?
=================================================================================================================================================================
VXLAN MAC Entries
=================================================================================================================================================================
VNID Interface VlanId In-VlanId Mac-Addr VTEP-Ip/ESI Type Status MAC move AccessPortDesc LeafFlag
_________________________________________________________________________________________________________________________________________________________________
10100 irb10100 ---- ---- 0000.5e00.5311 10.255.0.10 Static Local ------- 0 ------- ----
10100 ---- ---- ---- 0000.5e00.5312 10.255.0.12 Static Remote ------- 0 ------- ----
Total number of entries are : 2
VXLAN ARP-CACHE Information
===========================
VNID Ip-Addr Mac-Addr Type Age-Out Retries-Left
_______________________________________________________________________________________
10100 192.0.2.1 0000.5e00.5311 Static Local ----
10100 192.0.2.2 0000.5e00.5312 Static Remote ----
Total number of entries are 2
The router’s own gateway MAC is a local entry. The far end’s gateway MAC is programmed as a remote entry behind the far-end VTEP, and its IP to MAC binding is in the ARP cache, both from the EVPN routes. All four entries appear as Static because gateway addresses are advertised by configuration, not learned from traffic. The routes themselves are in show bgp l2vpn evpn mac-ip:
BGP table version is 4, local router ID is 10.255.0.10
Status codes: s suppressed, d damped, h history, a add-path, b back-up, * valid, > best, i - internal,
l - labeled, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Description : Ext-Color - Extended community color
RD[10.255.0.10:100] VRF[VXB2]:
ESI Eth-Tag Mac-Address IP-Address VNID/LABEL L3VNID Nexthop GW-Type Peer Encap
* 0 10100 0000:5e00:5312 192.0.2.2 10100 0 10.255.0.12 -- 10.255.0.12 VXLAN
* 0 10100 0000:5e00:5312 fe80::200:5eff:fe00:5312 10100 0 10.255.0.12 -- 10.255.0.12 VXLAN
*> 0 10100 0000:5e00:5311 192.0.2.1 10100 0 10.255.0.10 -- ---------- VXLAN
*> 0 10100 0000:5e00:5311 fe80::200:5eff:fe00:5311 10100 0 10.255.0.10 -- ---------- VXLAN
RD[10.255.0.12:100]
ESI Eth-Tag Mac-Address IP-Address VNID/LABEL L3VNID Nexthop GW-Type Peer Encap
*> 0 10100 0000:5e00:5312 192.0.2.2 10100 0 10.255.0.12 -- 10.255.0.12 VXLAN
*> 0 10100 0000:5e00:5312 fe80::200:5eff:fe00:5312 10100 0 10.255.0.12 -- 10.255.0.12 VXLAN
How to Check That a MAC Address Is Programmed End to End
When a host behind one leaf cannot reach a host behind another, these commands, run on the leaf that should know the remote address, show where the chain stops:
show bgp l2vpn evpn summary: the session to the remote leaf is established and the MACIP count is above zero.show bgp l2vpn evpn mac-ip: the Type 2 route for the address is present, with the remote leaf as next hop.show nvo vxlan vni-tunnel: the VNI lists the remote leaf as a tunnel endpoint.show nvo vxlan mac-table: the address is installed in the VNI, pointing to the remote VTEP address or to an ESI.show evpn esi all: if the entry points to an ESI, the segment lists the leaves you expect.show nvo vxlan arp-cache: the IP to MAC binding is present for the VNI.
Each check depends on the one before it, so start with the first check that fails. Every command in this list was run on the lab leaf.
Syntax Notes for Engineers Coming from Other Platforms
| Task | OcNOS 7.0.1 router form |
|---|---|
| Bind an access port to a VNI | access-if-evpn, then map vpn-id <vni> |
| Disable VXLAN | nvo vxlan disable |
| Disable the TCAM group | hardware-profile filter vxlan disable |
| Show the L3 VNI map | show evpn l3vni-map |
To remove the service, delete the access sub-interface, the VNI, the VTEP address and the loopback, and add nvo vxlan disable to the same commit. Then commit hardware-profile filter vxlan disable. On the demo VM, leave out the hardware-profile line.
Platform Note
Part 1 is from OcNOS-SP-PLUS 7.0.1 on a UfiSpace S9600-56DX, Part 2 from OcNOS-DC-PLUS 7.0.1 on a UfiSpace S8901-54XC, and Part 3 from OcNOS-SP-PLUS 7.0.2 on a UfiSpace S9600-28DX. Check VXLAN-EVPN support for other platforms and licence tiers in the OcNOS Feature Matrix and the hardware compatibility list. For EVPN route types and multi-homing, see EVPN-VXLAN in OcNOS and EVPN multi-homing.