EVPN & MPLS

VXLAN-EVPN on OcNOS 7.0: Configure a VTEP and Trace MAC Learning

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 irb10100 requires 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 irb must be committed before the IP VRF with its l3vni. 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:

  1. show bgp l2vpn evpn summary: the session to the remote leaf is established and the MACIP count is above zero.
  2. show bgp l2vpn evpn mac-ip: the Type 2 route for the address is present, with the remote leaf as next hop.
  3. show nvo vxlan vni-tunnel: the VNI lists the remote leaf as a tunnel endpoint.
  4. show nvo vxlan mac-table: the address is installed in the VNI, pointing to the remote VTEP address or to an ESI.
  5. show evpn esi all: if the entry points to an ESI, the segment lists the leaves you expect.
  6. 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.

Share

Frequently asked questions

Does enabling VXLAN on an OcNOS router require a reboot?
No. On OcNOS 7.0.1 the VXLAN TCAM group and VXLAN itself both take effect on commit, with no reload.
Why does nvo vxlan enable fail to commit?
The VXLAN hardware filter group is not enabled. Add hardware-profile filter vxlan enable in the same transaction and commit again.
How is a VNI attached to a customer port on OcNOS?
On a switchport sub-interface with an encapsulation set, enter access-if-evpn and use map vpn-id followed by the VNI.
How do you check that a remote MAC address is programmed on OcNOS?
Check the EVPN session and its MACIP count with show bgp l2vpn evpn summary, the tunnel with show nvo vxlan vni-tunnel, then the entry with show nvo vxlan mac-table, which shows the remote VTEP or Ethernet segment the address points to.
What does NON-DF mean in show nvo vxlan?
The leaf is not the designated forwarder for that Ethernet segment. Another leaf in the segment sends broadcast, unknown unicast and multicast traffic to it.
Why does OcNOS refuse evpn irb under nvo vxlan id?
On OcNOS 7.0.2 routers, an IRB bound to a VNI must be in an IP VRF that has an L3VNI, and nvo vxlan irb must be committed before that VRF. Otherwise the commit is refused with L3VNID does not exist or ip-vrf not mapped to IRB interface, or with EVPN-IRB is not Enabled.