jch at io
Jun 26, 2012, 10:19 PM
Post #2 of 2
(214 views)
Permalink
|
I suppose I should mention also that PE3 would be a Brocade CER :-/
From: foundry-nsp-bounces [at] puck [mailto:foundry-nsp-bounces [at] puck] On Behalf Of Hall, JC
Sent: Tuesday, June 26, 2012 10:08 PM
To: foundry-nsp [at] puck
Subject: [f-nsp] VPLS - bridging between VCs
Here is my scenario - this is a rare case but, PE3 connecting the CE could have two active VPLS attachment circuits, one each to PE1 and PE2. This would only happen in the event of a failure of PE4 (not pictured - and the CE would actually be dual-home with a connection to PE4).
CE
|
PE3
/ <-x-> \
/ \
P P
| |
PE1 PE2
PE1/PE2 are Cisco routers but it isn't particularly important here.
What I need to accomplish is to bridge or allow the forwarding of broadcast/multicast traffic within PE3 between the VCs.
An excerpt from Brocade's documentation states the following:
The PE devices apply a split horizon rulevwhen forwarding frames within the VPN. When a PE receives a customer frame from a VC LSP, it
can forward the frame only to a directly attached customer device, not to another VC LSP. This allows the VPLS instance to have a loop-free topology without having to run STP.
In the above scenario, represented by the " <-x->", is it possible to bridge or flood traffic that is originated from and destined to PE1/PE2 and vice versa across "VC LSPs"?
The outcome is ultimately to facilitate HSRP (could as easily be VSRP) packets to traverse and flow between PE1 and PE2. Based on the above excerpt this isn't going to work (and doesn't), obviously because those packets will only be forwarded out the port to the CE. Clearly, the CE will not send that back out the interface it was learned on (a hairpinning scenario).
Any insight is helpful.
Regards,
JC
|
