When the allow-ip-int-binding flag is set on a VPLS service, the following features cannot be enabled. Additionally, the flag cannot be enabled while any of these features are applied to the VPLS service. The following restrictions apply to both network mode and access-uplink mode, unless otherwise noted:
Spoke SDPs and mesh SDPs cannot be configured in an R-VPLS service.
In access-uplink mode, the VPLS service type cannot be MVPLS.
In network mode, the VPLS service type must be R-VPLS; no other VPLS service is allowed.
In access-uplink mode, MVR from an R-VPLS SAP to another SAP is not supported.
In access-uplink mode, default QinQ SAPs are not supported in an R-VPLS service.
In network mode, MVR from an R-VPLS SAP to another R-VPLS SAP is supported. See R-VPLS and IGMPv3 snooping for more information.
The allow-ip-int-binding command cannot be used in a VPLS service that is acting as the G.8032 control instance.
IP (IPv4 and IPv6) filters (ingress and egress) can be used with R-VPLS SAPs. Additionally, IP ingress override filters are supported, which affects the behavior of the IP filters attached to the R-VPLS SAPs.
MAC filters (ingress and egress) are supported with R-VPLS SAPs only on the 7210 SAS-Mxp.
In access-uplink mode, a VPLS IP interface is not allowed in an R-VPLS service, and an R-VPLS service/SAP cannot be configured with a VPLS IP interface.
In access-uplink mode, the VPLS service can be configured with either access SAPs or access-uplink SAPs. In network mode, the VPLS service can be configured only with access SAPs or with SAPs on hybrid ports.
In access-uplink mode, the VPLS service can use the following svc-sap-type values: any, dot1q-preserve, and null-star. Only specific SAP combinations are allowed for a specific svc-sap-type. Allowed SAP combinations are similar to those for plain VPLS service, except that default QinQ SAPs are not supported.
In network mode, the VPLS service can use the following svc-sap-type values: any, null-star, and dot1q-preserve.
G.8032 or MVPLS/STP based protection mechanisms can be used with an R-VPLS service. A separate G.8032 control instance or a separate MVPLS/STP instance must be used and the R-VPLS SAPs must be associated with these control instances such that the R-VPLS SAP forwarding state is driven by the control instance protocols.
IP multicast is not supported in an R-VPLS service.
IGMP snooping is supported in an R-VPLS service for 7210 SAS-T (network mode), 7210 SAS-Mxp, 7210 SAS-S, and 7210 SAS-Sx.
In access-uplink mode, DHCP snooping is not supported for the SAPs configured in an R-VPLS service. Instead, DHCP relay can be enabled on the IES service associated with the R-VPLS service.
In network mode, only on 7210 SAS-Mxp, DHCP IPv6 relay can be enabled on the IES service and VPRN service associated with the R-VPLS service. DHCPv6 snooping is not supported.
In network mode, DHCP snooping is not supported for the SAPs configured in an R-VPLS service. Instead, DHCP relay (IPv4) can be enabled on the IES service associated with the R-VPLS service.
In network mode, R-VPLS SAPs are allowed on access ports and hybrid ports.
In network mode, an R-VPLS SAP drops packets received with extra tags. That is, if a packet is received on an R-VPLS SAP, with the number of tags greater than the SAP tags to which it is mapped, then it is dropped. This is true for all supported encapsulations (that is, null, dot1q, and QinQ encapsulations) of the port. For example, double-tagged packets received on a Dot1q SAP configured in an R-VPLS service is dropped on ingress.
In the saved configuration file, for the R-VPLS service, the R-VPLS service instance appears twice, once for service creation and once with all the other configuration parameters. This is required to resolve references to the R-VPLS service and to execute the configuration without any errors.