[f-nsp] TE for the same VLL peers

[Brad Fleming]

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: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net 
> ] On Behalf Of Brad Fleming
> Sent: Thursday, March 31, 2011 12:42 PM
> To: foundry-nsp at puck.nether.net
> 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
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp