[j-nsp] Flexible Ethernet Services Question

[Paul Stewart]

Thanks Richard...

We'll experiment a little bit... another helpful person offline suggested
using ccc with l2vpn between the ports but I'm thinking this might add
unnecessary overheads.  Today on another box we are using IRB as you
mentioned ... in both of these situations this is an interm as we migrate
from a layer2 connected network over to an MPLS based backbone.....

Thankfully also, both sides are expecting the same VLAN ID's making this
"interm" solution much easier ;)

Cheers,

Paul


-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: Thursday, October 14, 2010 1:41 PM
To: Paul Stewart
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Flexible Ethernet Services Question

On Thu, Oct 14, 2010 at 10:05:26AM -0400, Paul Stewart wrote:
> 
> Using flexible Ethernet services on an interface I understand that I 
> can set the physical interface to vlan-tagging and then on a per 
> logical unit basis set encapsulation?  Today, it's a VLAN trunk that 
> comes in and peels off several VLAN's to their final destinations but 
> also some SVI interfaces that terminate as layer3 interfaces locally.

Correct. Using encapsulation flexible-ethernet-services removes earlier 
restrictions on which vlan-ids could be used for which services. Back in 
the good old days of the original ethernet PICs, if you wanted to mix IP 
and CCC terminations across multiple vlans on the same interface you had 
to configure "encapsulation vlan-ccc", which limited the VLAN ID ranges 
you could use to 1-511 for IP and 512-1023 for CCC. There is basically 
no penalty to doing flexible-ethernet-services on modern hardware, and 
all MX ports support it (not just the expensive ones).

> So on port 4/1/9 there is a VLAN trunked interface and I want to take 
> vlan 55 and vlan 119 and "pass them through" to another trunked port 
> via 5/1/9 out to another device (Juniper EX4200 in this case).  But I 
> also want to take vlan 3 and vlan 10 and have them terminate via 
> layer3 on the MX box itself.
> 
> Is family CCC the correct/best way to do this?  I presume I need to 
> create the VLAN's on the MX itself or does it matter when it's just 
> passing through?

Close, you'd want to use "encapsulation vlan-ccc" on the unit config. 
Then just create the mapping between the two units, like so:

protocols {
    connections {
        interface-switch yournamehere {
            interface ge-4/1/9.55;
            interface ge-5/1/9.55;
        }
        interface-switch yournamehere2 {
            interface ge-4/1/9.119;
            interface ge-5/1/9.119;
        }
    }
}

The advantage to this method is that it works on all Juniper's (well, 
historic Juniper's at any rate, if you want something thats backwards 
compatible with M/T/etc use this, I'm sure it will probably catch your 
SRX on fire if you try it there :P), and is time tested and guaranteed 
not to do anything stupid. The disadvantage is that you can only do a 
point to point link this way. Also, if you end up mismatching vlan IDs 
later on, you'll probably need to manually strip the vlan tags as they 
come in, since the default mode would be to carry the vlan tags into the 
CCC (which obviously wouldn't work if the other side is expecting a 
different vlan id :P). For example (and this is also supported on all MX 
interfaces and most modern hardware, but on older HW it was a quad price 
pic thing):

        unit 55 {
            encapsulation vlan-ccc;
            vlan-id 55;
            input-vlan-map pop;
            output-vlan-map push;
        }

You could also configure bridge-domains, which are a MX specific 
feature, to do multi-point L2 switching between these endpoints. I've 
personally never done this though, as IMHO you have to be clinically 
insane to spend money on a perfectly good MX port and then waste it 
doing L2 switching, but you could always RTFM if you wanna try it. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)