We use irb with bridge domains defined. (mx960) Will O'Brien
On Oct 14, 2010, at 2:43 PM, Paul Stewart <p...@paulstewart.org> wrote: > 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:r...@e-gerbil.net] > Sent: Thursday, October 14, 2010 1:41 PM > To: Paul Stewart > Cc: juniper-nsp@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 <r...@e-gerbil.net> http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp