VXLAN instances in VPLS and R-VPLS can be configured with egress VTEPs. This is referred as static vxlan-instances. The following configuration example shows a VPLS service that supports a static vxlan-instance:
config service vpls 1 name "vpls-1" customer 1 create
sap 1/1/1:1 create
exit
vxlan instance 1 vni 100 create
source-vtep-security
no disable-aging /* default: disable-aging
no disable-learning /* default: disable-learning
no discard-unknown-source
no max-nbr-mac-addr <table-size>
restrict-protected-src discard-frame
egr-vtep 192.0.2.1 create
exit
egr-vtep 192.0.2.2 create
exit
vxlan instance 2 vni 101 create
egr-vtep 192.0.2.3 create
exit
vxlan instance 2 vni 101 create
egr-vtep 192.0.2.3 create
exit
no shutdown
Specifically the following can be stated:
Each VPLS service can have up to two static VXLAN instances. Each instance is an implicit split-horizon-group, and up to 255 static VXLAN binds are supported in total, shared between the two VXLAN instances.
Single VXLAN instance VPLS services with static VXLAN are supported along with SAPs and SDP bindings. Therefore:
VNIs configured in static VXLAN instances are ‟symmetric”, that is, the same ingress and egress VNIs are used for VXLAN packets using that instance. Note that asymmetric VNIs are actually possible in EVPN VXLAN instances.
The addresses can be IPv4 or IPv6 (but not a mix within the same service).
A specified VXLAN instance can be configured with static egress VTEPs, or be associated with BGP EVPN, but the same instance cannot be configured to support both static and BGP-EVPN based VXLAN bindings.
Up to two VXLAN instances are supported per VPLS (up to two).
When two VXLAN instances are configured in the same VPLS service, any combination of static and BGP-EVPN enabled instances are supported. That is, the two VXLAN instances can be static, or BGP-EVPN enabled, or one of each type.
When a service is configured with EVPN and there is a static BGP-EVPN instance in the same service, the user must configure restrict-protected-src discard-frame along with no disable-learning in the static BGP-EVPN instance, service>vpls>vxlan.
MAC addresses are learned also on the VXLAN bindings of the static VXLAN instance. Therefore, they are shown in the FDB commands. Note that disable-learning and disable-aging are by default enabled in static vxlan-instance.
The learned MAC addresses are subject to the remote-age, and not the local-age (only MACs learned on SAPs use the local-age setting).
MAC addresses are learned on a VTEP as long as no disable-learning is configured, and the VXLAN VTEP is present in the base route table. When the VTEP disappears from the route table, the associated MACs are flushed.
The vpls vxlan source-vtep-security command can be configured per VXLAN instance on VPLS services. When enabled, the router performs an IPv4 source-vtep lookup to discover if the VXLAN packet comes from a trusted VTEP. If not, the router discards the frame. If the lookup yields a trusted source VTEP, then the frame is accepted.
A trusted VTEP is an egress VTEP that has been statically configured, or dynamically learned (through EVPN) in any service, Epipe or VPLS
The command show service vxlan shows the list of trusted VTEPs in the router.
The command source-vtep-security works for static VXLAN instances or BGP-EVPN enabled VXLAN instances, but only for IPv4 VTEPs.
The command is mutually exclusive with assisted-replication (replicator or leaf) in the VNI instance. AR can still be configured in a different instance.
Static VXLAN instances can use non-system IPv4/IPv6 termination.