Configuring service instances using the EVC framework : Flexible Service Mapping.
Probably the biggest advantage of the EVC framework is the ability to support multiple services per physical port. This means that under a single physical port you can have any of the following mixed together :
- 802.1q trunk
- 802.1q tunnel
- Local connect
- Scalable EoMPLS (EoMPLS xconnect)
- Multipoint Bridging (L2 bridging)
- Multipoint Bridging (VPLS, SVI-based EoMPLS)
- L3 termination
Besides all of the above, by using the EVC framework you can combine multiple different services from different physical ports, i.e. when using multipoint bridging (aka bridge-domains), in order to put them into the same virtual circuit.
Local connect is a L2 point-to-point service between two service instances on the same system. The service instances can by under the same port (hair-pinning) or under different ports. In contrast with the traditional L2 bridging, this one doesn't use any MAC learning and it's solely between 2 points. Also Local Connect doesn't require any global VLAN resource.
In order to have the following two service instances connect to each other by a L2 point-to-point service, you need first to remove their difference, which is the outer tag (you can also remove both tags).
interface Gi1/1 service instance 10 ethernet encapsulation dot1q 10 second-dot1q 100 rewrite ingress tag pop 1 symmetric interface Gi1/2 service instance 20 ethernet encapsulation dot1q 20 second-dot1q 100 rewrite ingress tag pop 1 symmetric ! EVC-LC-10-20 is just a name for this point-to-point connectionconnect EVC-LC-10-20 Gi1/1 10 Gi1/2 20
Note : You can use the same service instance number under different physical ports.
In order to have the following two service instances be connected by Local Connect, you don't need any VLAN tag rewrite, because they both have the same vlans.
interface Gi1/1
service instance 10 ethernet
encapsulation dot1q 10-20
interface Gi1/2
service instance 20 ethernet
encapsulation dot1q 10-20
connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20
In order to have the following two service instances be connected by Local Connect, you can either translate the vlan on one of them, or remove the tags on both of them.
interface Gi1/1
service instance 10 ethernet
encapsulation dot1q 10
rewrite ingress tag translate 1-to-1 dot1q 20 symmetric
interface Gi1/2
service instance 20 ethernet
encapsulation dot1q 20
connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20
Scalable EoMPLS or EoMPLS xconnect is a L2 point-to-point service between two service instances on different systems. Like Local Connect it doesn't use any MAC learning and it's solely between 2 points. It also doesn't require any global VLAN resource (this applies to scalable EoMPLS only; for SVI-based EoMPLS check VPLS below).
You can have any VLAN tag rewrite configuration under the service instances, as long as you keep in mind the following :
a) If both sides are EVC based, then you need to have common VLAN tag rewrite configurations on both sides
b) If one side is not EVC based, then depending on whether it's a physical interface or a subinterface, you'll probably need to remove one tag from the EVC side (subinterfaces remove tags by default)
Note : By default, VC type 5 is used for EoMPLS. In case VC type 4 is negotiated and used, an additional tag will be added after the VLAN tag rewrite configuration and before the data gets EoMPLS encapsulated.
7600-1
interface Gi1/1
service instance 10 ethernet
encapsulation dot1q 10
xconnect 1.1.1.2 10 encapsulation mpls
7600-2
interface Gi1/1
service instance 10 ethernet
encapsulation dot1q 10
xconnect 1.1.1.1 10 encapsulation mpls
Note : Have a look at Scalable EoMPLS for additional information.
Multipoint Bridging uses the concept of bridge-domains. Bridge-domain (BD) is like a traditional L2 broadcast domain where MAC-based forwarding is used for communication between participants (i'll try to write a new post with more details about bridge-domains). Bridge-domains use global VLAN resources.
In the following example, three service instances are put into the same bridge-domain by translating the tags where necessary.
interface Gi1/1 service instance 10 ethernet encapsulation dot1q 10 rewrite ingress tag translate 1-to-1 dot1q 20 symmetric bridge-domain 20 interface Gi1/2 service instance 20 ethernet encapsulation dot1q 20 bridge-domain 20 interface Gi1/3 service instance 30 ethernet encapsulation dot1q 30 rewrite ingress tag translate 1-to-1 dot1q 20 symmetric bridge-domain 20
The bridge-domain ID represents the global VLAN used in the system. Extra care needs to taken in case of L2 trunk/tunnel ports participating in a bridge-domain :
a) L2 trunk ports remove automatically the tag on ingress and add it automatically on egress. Equivalent EVC ports need that to be done manually by using the appropriate rewrite actions.
b) L2 tunnel ports add a new tag on ingress and remove it on egress. Equivalent EVC ports do not need any similar rewrite actions, because by default bridge-domains add a new tag on top of the already existing one.
In the following example two ports (a L2 trunk port and an EVC port) are put into the same bridge-domain (Vlan 20). Tag 10 needs to be removed from the EVC port before it joins bridge-domain 20.
interface Gi1/1 service instance 10 ethernet encapsulation dot1q 10 rewrite ingress tag pop 1 symmetric bridge-domain 20 interface Gi2/1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 20 switchport mode trunk
In the following example two ports (a L2 tunnel port and an EVC port) are put into the same bridge-domain (Vlan 20). On the EVC port, tag 20 is added on top of tag 10 in order to have the incoming frames join bridge-domain 20.
interface Gi1/1 service instance 10 ethernet encapsulation dot1q 10 bridge-domain 20 interface Gi2/1 switchport access vlan 20 switchport mode dot1q-tunnel
VPLS or SVI-based EoMPLS can be accomplished by configuring xconnect under a SVI. This SVI is the same as the one defined by the bridge-domain ID.
interface Gi1/1 service instance 10 ethernet encapsulation dot1q 10-20 bridge-domain 30 interface Gi1/2 service instance 10 ethernet encapsulation dot1q 10-20 bridge-domain 30 interface Vlan 30 xconnect 1.1.1.2 10 encapsulation mpls
By adding "split-horizon" after the bridge-domain ID in both service instances, there can be no L2 communication between them.
interface Gi1/1 service instance 10 ethernet encapsulation dot1q 10-20 bridge-domain 30 split-horizon interface Gi1/2 service instance 10 ethernet encapsulation dot1q 10-20 bridge-domain 30 split-horizon interface Vlan 30 xconnect 1.1.1.2 10 encapsulation mpls
By adding an additional tag through a rewrite action in both service instances, you can differentiate them, while they are being transfered through the same VC.
interface Gi1/1 service instance 10 ethernet encapsulation dot1q 10-20 rewrite ingress tag push dot1q 21 symmetric bridge-domain 30 split-horizon interface Gi1/2 service instance 10 ethernet encapsulation dot1q 10-20 rewrite ingress tag push dot1q 22 symmetric bridge-domain 30 split-horizon interface Vlan 30 xconnect 1.1.1.2 10 encapsulation mpls
SVI-based EoMPLS can be considered like a VPLS, where there is only one VC pointing to one neighbor.
Note : Have a look at SVI-based EoMPLS for additional information.
For L3 termination you have the usual two options : use subinterfaces or use bridge-domains (just like switchports) and SVIs. ES/ES+ and SIP-400 cards support termination of double-tagged traffic too.
Keep in mind the following :
a) you must remove all tags before terminating L3 traffic
b) you must use matching rules based on unique single or double tags (no vlan ranges are supported, although they might be accepted)
This is an example using a bridge-domain and the equivalent SVI:
interface Gi1/1 service instance 10 ethernet encapsulation dot1q 10 rewrite ingress tag pop 1 symmetric bridge-domain 40 interface Gi1/2 service instance 10 ethernet encapsulation dot1q 20 second-dot1q 30 rewrite ingress tag pop 2 symmetric bridge-domain 40 interface Vlan 40 ip address 1.1.1.1 255.255.255.0
This is an example using subinterfaces:
interface Gi1/1.10 encapsulation dot1q 10 ip address 1.1.1.1 255.255.255.0 interface Gi1/1.20 encapsulation dot1q 20 second-dot1q 30 ip address 1.1.1.1 255.255.255.0
Note : ES cards have a major limitation : single-tagged vlans configured under a subinterface are global significant. On the other hand, double-tagged vlans are local significant. On the ES+ and SIP-400 cards, both single-tagged and double-tagged vlans are local significant.
No comments:
Post a Comment