[j-nsp] Multicast senders/receivers on the same PE (different VRF) with NG MVPN

[Krasimir Avramski]

Hi,
vt when used with "multicast" keyword(in configuration upon binding VT ifl
to VRF) is only used for multicast traffic replication(loopback) to
receivers living in different MVPN instances. The unicast traffic can still
use vrf-table-label, the same vt ifl as multicast, a different vt ifl than
multicast, or neither.
Also the tunnel hardware is only needed when remote PE is receiving through
P2MP LSP and has more than one MVPN instance that could have receivers for
a given source (is importing the routes for a particular source).
The VT's to PFE anchoring is defined with tunnel services
definition(slot/pic or mic) - so if needed traffic goes through fabric to
the anchor PFE for processing.


Best Regards,
Krasi

On Mon, Dec 17, 2012 at 3:02 PM, Vladislav A. VASILEV <
vladislavavasilev at gmail.com> wrote:

> Hi Krasimir,
>
> I had only considered vt interfaces for doing filtering/additional look
> ups for traffic egressing L3VPNs (prior to the vrf-table-lable being
> available). I now have a working NG MVPN (extranet). However, what if I
> wanted to have senders/receivers physically terminated on the same router,
> but on different MPCs? Effectively, traffic wouldn't be processed by the
> same Trio chip = different vt interface!
>
> Thanks,
> Vladi
>
>
>
>
> On Thu, Nov 22, 2012 at 1:54 PM, Krasimir Avramski <krasi at smartcom.bg>wrote:
>
>> Hi,
>>
>> NG-MVPN extranets are supported since junos 9.5:
>>
>>
>> http://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/mcast-mbgp-extranets.html#jd0e120
>>
>> As I remember in some corner cases(only two extranet VRFs on the same
>> router - if my memory serves me right) there is NO need for tunnel hw (VT-
>> ifls)  -  only  "vrf-table-label" (lsi ifls) should do the trick.
>>
>> Best Regards,
>> Krasi
>>
>> On Thu, Nov 22, 2012 at 2:54 PM, Vladislav A. VASILEV <
>> vladislavavasilev at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I need to deliver multicast data to a receiver in a VRF, which resides on
>>> the same PE as the sender VRF.
>>>
>>> The only way I see this could be done is by putting one of the VRFs into
>>> a
>>> logical system and presenting the traffic over an lt interface. The
>>> problem
>>> is that this type of design does not scale. What if down the road I had
>>> another customer which wanted to receive multicast data from both the
>>> current sender/receiver? I'd then need to put it into another logical
>>> system (basically introducing another PE, being a logical one)?
>>>
>>> What options do I have?
>>>
>>> Thanks,
>>> Vladi
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>