To those who didn't know.. mLDP looks to be supported in 11.2... Hooraayy! provider-tunnel { ldp-p2mp; selective { wildcard-group-inet { wildcard-source { ldp-p2mp;
On Fri, Sep 16, 2011 at 6:17 PM, Chris Evans <chrisccnpsp...@gmail.com>wrote: > Thanks for the replies everyone, i've made it further.. One last thing > stumping me. When I configure a threshold-rate for P-tunnel switchover it > doesn't seem to work. I get flooding to both PE's even after the multicast > stream is over the configured rate. If i configure the threshold-rate to be > 0 everything works as expect, traffic only goes to where it needs to be. Am > I missing something from the configuration? > > provider-tunnel { > rsvp-te { > label-switched-path-template { > default-template; > } > } > selective { > group 239.192.0.0/16 { > wildcard-source { > threshold-rate 500; > rsvp-te { > label-switched-path-template { > default-template; > } > } > } > > On Fri, Sep 16, 2011 at 11:18 AM, Krasimir Avramski <kr...@smartcom.bg>wrote: > >> It is RI context. Actually group and source are (C-S, C-G). >> Please refer the wildcard usage in docs: >> >> http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/config-guide-vpns/topic-40020.html >> >> Regards, >> Krasi >> >> On Fri, Sep 16, 2011 at 5:05 PM, Chris Evans <chrisccnpsp...@gmail.com>wrote: >> >>> Okay that is what I was thinking.. I had the initial configuration >>> without the selective and saw the results I asked about. I then put in >>> selective configuration, but am unsure if I really have it right. >>> >>> What should the source be? routing-instance IP or global IP? I assume the >>> group should be SSM? >>> >>> >>> My original configuration which I saw the flooding: >>> provider-tunnel { >>> rsvp-te { >>> label-switched-path-template { >>> default-template; >>> >>> My configuration that I made to be selective: >>> provider-tunnel { >>> rsvp-te { >>> label-switched-path-template { >>> default-template; >>> } >>> } >>> selective { >>> group 232.1.1.3/32 { >>> wildcard-source { >>> threshold-rate 500; >>> rsvp-te { >>> label-switched-path-template { >>> default-template; >>> } >>> } >>> } >>> source 172.16.1.3/32 { >>> rsvp-te { >>> label-switched-path-template { >>> default-template; >>> >>> >>> On Fri, Sep 16, 2011 at 9:46 AM, Krasimir Avramski <kr...@smartcom.bg>wrote: >>> >>>> Hi, >>>> >>>> It is normal behavior with inclusive P-tunnels (in your case P2MP >>>> lsps).It is default without explicit selective configuration. >>>> >>>> Regards, >>>> Krasi >>>> >>>> On Fri, Sep 16, 2011 at 4:10 PM, Chris Evans >>>> <chrisccnpsp...@gmail.com>wrote: >>>> >>>>> I took a few minutes to setup NG-MVPN using RSVP-TE P2MP LSP in my >>>>> lab. I >>>>> have 3 boxes setup in a triangle format. I have multicast flowing >>>>> properly, >>>>> however I'm seeing a weird anomaly that i'd like to get some >>>>> clarification >>>>> on.**** >>>>> All of the P2MP RSVP sessions are up properly, things appear to be >>>>> signaled >>>>> properly, traffic flows properly on the devices that should be getting >>>>> it. >>>>> What I am seeing is on the sender PE, whenever there is a receiver on a >>>>> far-end PE's requesting traffic the sender PE floods its to both >>>>> downstream >>>>> PEs. It looks to be flooding it across two LSP paths as I see traffic >>>>> rates >>>>> double what they should be. If I stop the receiver both PEs stop >>>>> getting >>>>> traffic, as expected. >>>>> >>>>> On the PE that doesn't have the receiver if I do 'show multicast route >>>>> instance <name> extension' it shows that route in the table, shows that >>>>> is >>>>> received via PIM (forwarding devices show MVPN) and it also shows it >>>>> as >>>>> pruned. >>>>> >>>>> Anyone seen this? >>>>> _______________________________________________ >>>>> 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