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 <r...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp