MX80 VPLS/CCC with no vlan negotiation

[sherv]

I'm setting up our new MPLS/IP network based on MX80 routers, and have a question.

Currently we have some customers with point-to-point QinQ service over our L2 network. I'm looking for a way to replicate this based on MPLS.

Issue is, I have configured(and know of) only VPLS/CCC on vlan-tagged/untagged interfaces. So if I have negotiated a vlan-id(or it's absence) with a customer - there's no problem.

But this not only means that I have to negotiate a vlan-id, but I also have to create a separate CCC/VPLS instance per vlan, which is not that convenient.

However, in QinQ I don't have to negotiate transit vlan-id's with customers - they can switch whatever vlans they want, even point-to-multipoint. How can I achieve same functionality over MPLS? Link to appropriate documentation would be nice.

[sherv]

Ok, I think I almost have an answer for myself. This is called One VPLS Instance for Several VLANs. I can specify vlan-id-range 1-4094, and customers will be able to transfer any vlan they want.

It doesn't answer to the question "what to do with untagged packets?" though.

[SapphireNET]

I have done something similar with L2VPN, simply because at the time the issue of having to specify the inner vlans ( CVLANs ) was a pain in the butt.

So now I simply check the SVLAN vlaue and in we go:

ge-0/0/8 {
    description "QinQ Device";
    flexible-vlan-tagging;
    native-vlan-id 300;
    mtu 9192;
    encapsulation extended-vlan-ccc;
    unit 0 {
        vlan-id 300;
        family ccc;
    }
}

QinQ-Trunk {
    instance-type l2vpn;
    interface ge-0/0/8.0;
    route-distinguisher 10.1.1.1:2000;
    vrf-target target:65354:2000;
    protocols {
        l2vpn {
            encapsulation-type ethernet-vlan;
            site CE-1 {
                site-identifier 1;
                interface ge-0/0/8.0;
            }
        }
    }
}

this passes the QinQ through the circuit, note the SVLAN is already set by the CE switch

[sherv]

Thanks for advise, SapphireNET, but I think I found my own answer.

I've made a following simple lab  ([CE]---[PE])---([PE]---[CE]), where () is a single MX80 with two looped ports. I was able to configure a single LDP VPLS instance with BGP autodiscovery and native-vlan-id statement. It passes any vlans, and untagged frames are considered as a part of native vlan.

Here's a configuration example:

> show configuration protocols ldp
interface ge-1/1/3.300;
interface lo0.0;

> show configuration protocols mpls
interface ge-1/1/3.300;
interface ge-1/1/1.0;

> show configuration interfaces lo0
unit 0 {
    family inet {
        address 192.168.110.40/32;
    }
}

> show configuration interfaces ge-1/1/3
vlan-tagging;
mtu 9192;
encapsulation flexible-ethernet-services;
unit 300 {
    vlan-id 300;
    family inet {
        address 10.5.192.9/30;
    }
    family mpls;
}

> show configuration interfaces ge-1/1/1
description LOOP_TO_ge-1/1/2;
flexible-vlan-tagging;
native-vlan-id 1;
encapsulation flexible-ethernet-services;
unit 0 {
    encapsulation vlan-vpls;
    vlan-id-range 1-4094;
}

> show configuration protocols ospf
traffic-engineering;
export IPV4_OSPF_EXPORT;
area 0.0.0.0 {
    interface ge-1/1/3.300 {
        bfd-liveness-detection {
            minimum-interval 300;
            multiplier 4;
            full-neighbors-only;
        }
    }
}

> show configuration policy-options policy-statement IPV4_OSPF_EXPORT
term DIRECT {
    from protocol direct;
    then accept;
}
term ELSE {
    then reject;
}

> show configuration protocols bgp
local-as 65000;
group IBGP {
    type internal;
    multihop;
    neighbor 192.168.110.41 {
        local-address 192.168.110.40;
        family l2vpn {
            auto-discovery-only;
        }
        peer-as 65000;
    }
}

> show configuration routing-instances VPLS100
instance-type vpls;
vlan-id all;
interface ge-1/1/1.0;
route-distinguisher 192.168.110.40:100;
l2vpn-id l2vpn-id:65000:100;
vrf-target target:65000:100;
protocols {
    vpls {
        no-tunnel-services;
    }
}

Interface ge-1/1/2 is in another routing instance to simulate a customer.

It's pretty much the same on the other PE.

I suppose that this can pass any customer's ethernet traffic, including tagged/untagged/QinQ in a point-to-multipoint way.

I'm planning to deploy this solution in a week or so - I'll make a mention here if I face any difficulties or unexpected behavior.

[SapphireNET]

and your BPDUs are flowing as expected?

[sherv]

This one I coulnd't test yet - my only VPLS customer so far does not use STP. I suppose it would require configuring layer2-control. But, for example, I still have no idea how to get LLDP tunneled throught VPLS - there's no mention about it in layer2-control configuration.

This is what i'm planning to research in a nearest future.

CCCs work fine though - every L2 packet passes through - including STP.