<div dir="ltr">I find myself using Option #1 frequently.<div><div style="font-size:12.7272720336914px">1 - When the link comes in, put the subinterface into a VPLS with any vlan tag, then create a VE interface tied to that VPLS. The VE and vlan tags don't need to match. You will of course need an MPLS license for this. We used XMR so had no issue here.</div></div><div><br></div><div>And I use this really ugly one too!</div><div><span style="font-size:12.7272720336914px">c) Use a loopback cable, local-vll, rewrite vlan features.</span><br style="font-size:12.7272720336914px"></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, 2014 at 12:37 PM, Darren O'Connor <span dir="ltr"><<a href="mailto:darrenoc@outlook.com" target="_blank">darrenoc@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">
<div dir="ltr">I no longer work with Brocades, only in my last job. But I did run into the same issue.<div><br></div><div>There is no easy way around it. </div><div><br></div><div>When we ordered circuits that required vlan tags, we created a database specifically in order that no two links used the same vlan tag. This is only a problem if you're terminating a layer 3 subinterface like this. If the CER is an MPLS PE, then each physical interface can have the same vlan tagged into different VLL/VPLS instances.</div><div><br></div><div>There are some workarounds, none of them fun.</div><div><br></div><div>1 - When the link comes in, put the subinterface into a VPLS with any vlan tag, then create a VE interface tied to that VPLS. The VE and vlan tags don't need to match. You will of course need an MPLS license for this. We used XMR so had no issue here.</div><div>2 - Create a VLL to another box doing the actual routing. Same issue as above though.</div><div>3 - Put another box in front that can do vlan manipulation like a Cisco me3600x and swap the vlan before it gets to the CER.</div><div><br></div><div>None of them pretty.</div><div><br></div><div>Darren</div><div><a href="http://www.mellowd.co.uk/ccie" target="_blank">www.mellowd.co.uk/ccie</a></div><span></span><br><br><div>> Date: Mon, 29 Dec 2014 21:43:32 +1030<br>> From: <a href="mailto:matthew@tav.id.au" target="_blank">matthew@tav.id.au</a><br>> To: <a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a><br>> Subject: [f-nsp] Routed sub interfaces?<div><div class="h5"><br>> <br>> Hi,<br>> <br>> We are moving from a Cisco ASR1002 to a Brocade CER2000RT but I can't <br>> see any way to do routed sub interfaces (router on a stick) from looking <br>> through the configuration guide. For example, on the ASR we'd have <br>> gi1/1 going to provider X and gi1/2 going to provider Y with managed <br>> ethernet circuits delivered on the same VLAN tags. The config would look <br>> something like the example below and this wouldn't be an issue as vlan <br>> tag 10 on gi1/1 would be separate from vlan tag 10 on gi1/2.<br>> <br>> int gi 1/1<br>> desc Trunk to provider X<br>> <br>> int gi 1/1.10<br>> desc Link to Site A<br>> encap dot1q 10<br>> ip add 192.168.1.1 255.255.255.252<br>> <br>> int gi 1/2<br>> desc Trunk to provider Y<br>> <br>> int gi 1/2.10<br>> desc Link to Site B<br>> encap dot1q 10<br>> ip add 192.168.2.1 255.255.255.252<br>> <br>> However from reading the configuration guide, to do this on a CER we <br>> would make e1/1 and e1/2 tagged ports in vlan 10 but then the virtual <br>> routing interface (ve10) for vlan 10 would be reachable via both Site A <br>> and B. What are people doing in this situation to keep vlan 10 from e1/1 <br>> separate from vlan 10 on e1/2?<br>> <br>> Thanks,<br>> Matthew<br>> _______________________________________________<br>> foundry-nsp mailing list<br>> <a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a><br>> <a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a><br></div></div></div></div>
</div></div>
<br>_______________________________________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a><br></blockquote></div><br></div>