Saturday, September 5, 2009

EVC : Flexible Service Mapping

After 2 months of intense network re-designing (mixed with a little bit of vacation days) and following my two previous posts about Flexible Frame Matching and Flexible VLAN Tag Rewrite, i finally found some free time to write a post about the third step in 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 connection
connect 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.

18 comments:

  1. One thing I do not understand is the L3 termination at the end. Can you assign the same IP address to different EVC?

    thanks,

    Joy

    ReplyDelete
  2. It's not possible to use ip addresses under service instances. You have to use subifs or SVIs and in both cases you can't have the same ip address on different interfaces.
    Btw, what would be the reason for doing that?

    ReplyDelete
  3. Hi Tassos,

    I'm not sure if you've tried the EVC framework on ASR9K platform. I'll put my question here anyway.

    My question is that: Are there any restrictions on the interfaces to be added in a bridge-domain?

    For example, below is the configuration:

    interface Gi0/1.10001001 l2transport
    encap dot1q 1000 sec 1001
    rewrite ingr tag push dot1q 2000 sec 2002 sym
    !
    interface Gi0/2.30003003 l2transport
    encap dot1q 3000 sec 3003
    rewrite ingress tag pop 2 sym
    !
    l2vpn
    bridge group mytest
    bridge-domain test1
    int Gi0/1.10001001
    int Gi0/2.30003003
    !
    !
    !

    My idea is: On top of the two tags received on the Gi0/1.10001001 interface, two new tags will be imposed on the frame which are 2000 and 2002. On the outgoing (Gi0/2.30003003), another two new tags (3000 and 3003) are added on top of these frames. The result is to get at least 6 tags on the frames going out off Gi0/2. Apparently, this doesn't work.

    My guess is that because the im-balance of configurations, clearer - the vlan-tag operations, between the two member interfaces, the bridge-domain doesn't work at all. But I'm not sure about this.

    Do you have any idea on this? Or do you know how the bridge-domain works? I tried to search but found nothing.

    Thanks,
    Cuong.

    ReplyDelete
  4. To add more information:

    If I change the configuration from bridge-domain to xconnect, it works as expected.

    l2vpn
    xconnect group mytest
    p2p testp2p
    interface Gi0/1.10001001
    interface Gi0/2.30003003
    !
    !

    So, bridge-domain does have restrictions.

    ReplyDelete
  5. Cuong Nguyen,

    Since i got my hands on a ASR9k, i believe your problem might be the mtu (you have to configure the mtu under the bridge-domain).

    ReplyDelete
  6. Thank you for your useful post. Hope you will write new post about bridge-domains as soon as possible.

    ReplyDelete
  7. Hi Tassos,
    You said:
    interface Gi1/1
    service instance 10 ethernet
    encapsulation dot1q 10
    bridge-domain 20

    interface Gi2/1
    switchport access vlan 20
    switchport mode dot1q-tunnel


    I think it must be:
    interface Gi1/1
    service instance 10 ethernet
    encapsulation dot1q 10
    rewrite ingress tag translate 1-to-1 dot1q 20 symmetric
    bridge-domain 20

    Please confirm me this is correct?

    ReplyDelete
  8. Your config will translate vlan tag 10 to 20 and then add vlan tag 20 over it, so it will not work.

    ReplyDelete
  9. Hi Tassos,

    I have two PCs that in turn send packets with two vlans 300|102 and 300|101 to port gi1/1 of router.

    I configure as follow:

    interface Gi1/1
    service instance 100 ethernet
    encapsulation dot1q 300 second-dot1q 102
    rewrite ingress tag pop 2 symmetric
    bridge-domain 300
    !
    service instance 200 ethernet
    encapsulation dot1q 300 second-dot1q 101
    rewrite ingress tag pop 2 symmetric
    bridge-domain 300

    Can I do ping between two PCs?

    Thank you,

    ReplyDelete
  10. ping should work between them.

    ReplyDelete
  11. Hi Tassos,

    In the context of Metro EThernet would it be correct to say that for configuring a service we can either configure an EVC using connect EVC command or simply associate bridge domain with the relevant service instances.

    Thanks,
    Joel

    ReplyDelete
  12. connect EVC is p2p and BD is p2mp

    ReplyDelete
  13. In last port of the section, you have same IP address for two sub interfaces. can you do that?
    By the way, Great post.
    Thanks.

    ReplyDelete
  14. Anonymous #1,

    bridge-domain, although can be used for p2p, is commonly used for p2mp.
    Also bridge-domain needs a global vlan.


    Anonymous #2,

    The example implies that you won't use both subifs at the same time.

    ReplyDelete
  15. Are there any resources that you would recommend to get more familiar with mapping?

    ReplyDelete
  16. Last time i checked, CCO had some examples.
    Also Cisco support forums might contain some extra information.

    ReplyDelete
  17. Hello Tassos! Great Post!
    I only start to study EVC framework. And have a little question.
    I want 3 vlans 300-302 to be in 1 bridge-domain and have L3 terminated.

    I made the following config:

    int Gi0/0/3
    service instance 300 ethernet
    encap dot1q 300
    bridge-domain 1
    !
    service instance 301 ethernet
    encap dot1q 301
    rewrite ingress tag translate 1-to-1 dot1q 300 symmetric
    bridge-domain 1
    !
    service instance 302 ethernet
    encap dot1q 302
    rewrite ingress tag translate 1-to-1 dot1q 300 symmetric
    bridge-domain 1
    !

    int bdi 1
    encap dot1q 300
    ip address 10.10.34.1 255.255.255.0

    It's seems that all is ok - pings between hosts in those vlans are successful.

    I wonder what if I make separate vlan and service instance for bdi
    here is the following config:

    int Gi0/0/3
    no ip address
    service instance 300 ethernet
    encap dot1q 300
    rewrite ingress tag translate 1-to-1 dot1q 303 symmetric
    bridge-domain 1
    !
    service instance 301 ethernet
    encap dot1q 301
    rewrite ingress tag translate 1-to-1 dot1q 303 symmetric
    bridge-domain 1
    !
    service instance 302 ethernet
    encap dot1q 302
    rewrite ingress tag translate 1-to-1 dot1q 303 symmetric
    bridge-domain 1
    !
    service instance 303 ethernet
    encap dot1q 303
    bridge-domain 1
    !
    int bdi 1
    encap dot1q 303
    ip address 10.10.34.1 255.255.255.0

    This config also works. But what is right?

    ReplyDelete
  18. Is the below configuration valid? Can i have the same customer vlan but with 2 different s-vlans mapped to two different service instances?

    interface GigabitEthernet4/19
    description AS4123 - TESTE LACP
    mtu 1600
    no ip address
    load-interval 30
    speed 1000
    service instance 100 ethernet
    description 100
    encapsulation dot1q 110 second-dot1q 100
    rewrite ingress tag pop 1 symmetric
    service-policy input prec5
    service-policy output prec5
    bridge-domain 111
    !
    service instance 600 ethernet
    encapsulation dot1q 600 second-dot1q 100
    rewrite ingress tag pop 1 symmetric
    bridge-domain 600
    !

    ReplyDelete

 
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Greece License.