Dan,
Thanks very much for your response. Very much appreciated.
We've steered clear of the VPLS model for these services to avoid
learning all the MAC addresses. Eliminating VLL as an option will
force us into a cost/benefit for these services; which isn't a bad
thing, just means we need to get out of the test lab and into CAM /
memory planning mode.
Do you happen to know if Brocade plans to allow VLLs a similar
configuration?
At any rate, thanks again for the reply!
-brad
On Mar 31, 2011, at 1:26 PM, Dan Spataro wrote:
Brad,
You cannot force a VLL to take a specific LSP. You need to convert
your VLLs to VPLS, then you will be able to specify a LSP for the
VPLS to use. So for your DR traffic you would need to create a LSP
with a primary path over the indirect links then reference that LSP
in the VPLS config for your DR VLAN or interface.
Here is an example (you can also create secondary paths and use FRR
for failover).
path DR_traffic_path
to x.x.x.x
to x.x.x.x
enable
lsp DR_traffic
to x.x.x.x
primary DR_traffic_path
enable
vpls DR_traffic xxx
vpls-peer x.x.x.x lsp DR_traffic
vlan xxx
tagged ethe x/x
-----Original Message-----
From: [email protected] [mailto:[email protected]
] On Behalf Of Brad Fleming
Sent: Thursday, March 31, 2011 12:42 PM
To: [email protected]
Subject: [f-nsp] TE for the same VLL peers
Hello all,
If you have two VLLs both pointed at the same remote LER is it
possible to force one VLL over an indirect path while allowing the
other to use a direct path? I don't see options to specify an LSP
when provisioning a VLL and TAC informed me that a VLL must be
provisioned to the remote router-ID.
In our environment we have two routers that handle several VLLs.
Some of the VLLs are of a critical nature (voice) while others are
much lower priority (ie: DR data backups). We'd like to allow the
voice traffic to travel a direct (but narrow) path while forcing the
DR data down a long (but wide) path.
Any help, suggestions, or insight would be appreciated and thanks in
advance!
-brad
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp