[j-nsp] l2circuit communities

[Truman Boyes]

Hi Richard, 

You can likely achieve this a different way, (although you approach has interested me to check it out), by using CBF based on communities. I would use communities for the l2circuits, then associate those communities with a cos-next-hop-map, and have a forwarding policy exported to the FIB. 

Of course this is only useful if you feel like making l2circuits use a specific cos mapping in your network. 


Truman


On 17/05/2010, at 3:51 AM, Richard A Steenbergen wrote:

> I'm trying to do something similar to the example here:
> 
> http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-vpns/vpns-configuring-policies-for-layer-2-circuits.html
> 
> Using a community tag on an l2circuit and a install-nexthop lsp-regex
> policy to control which LSPs get used for transport customers. The goal
> is to make dedicated LSPs for l2circuits, and have them be completely
> separate from the LSPs used for regular IP traffic.
> 
> But in this example, it doesn't say anything about how to keep the
> regular IP traffic-engineering/shortcuts routes from load balancing with
> the transport LSPs, which it wants to do by default. I tried changing
> the preference on the transport LSPs to make them less preferred, but 
> install-nexthop doesn't seem to actually do anything to block the other
> non-matching LSPs being being used, so with the better preference they
> still end up being selected by the l2ckts.
> 
> I tried using the "install-nexthop except", but it didn't quite work
> like I expected either. The documentation on it says "To prevent the
> installation of any matching next hops, include the install-nexthop
> statement with the except option:", so I figured you might need to
> explicitly block the other LSPs using it. If you try to put the "except"
> in the same term as the match, it combined them all into a single
> statement like so:
> 
> term TRANSPORT-GOLD {
>    from community TRANSPORT_GOLD;
>    then {
>        install-nexthop lsp-regex TRANSPORT-.*-GOLD except IP-.*;
>        accept;
>    }
> }
> 
> And it doesn't seem to actually do anything (the regular IP LSPs are 
> still being used). I also tried it in a different term, like so:
> 
> term TRANSPORT-NO-IP {
>    from community [ TRANSPORT_GOLD TRANSPORT_SILVER TRANSPORT_BRONZE ];
>    then {
>        install-nexthop except lsp-regex "^IP.*";
>    }
> }
> term TRANSPORT-GOLD {
>    from community TRANSPORT_GOLD;
>    then {
>        install-nexthop lsp-regex TRANSPORT-.*-GOLD;
>        accept;
>    }
> }
> 
> But it doesn't work either. What am I missing here? I'm hoping there is
> something simple and elegant I'm missing short of having to a no-install
> on all of the regular LSPs, then match everything without the transport
> communities and install them to lsp-regexp IP.*.
> 
> -- 
> Richard A Steenbergen <ras at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>