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

[Krasimir Avramski]

Well, juniper does NOT support fabric multicast replication, so inter PFE
multicast robustness depends on:
number of fabrics installed and fabric capacity(legacy/enhanced).
binary + unary multicast replication support - "trio only" mode (DPC are
not allowed) using network-services enhanced-ip.

Best Regards,
Krasi

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

> Hi,
>
> The only thing I wasn't sure about was, whether or not the traffic goes
> through the fabric in cases where you have different VTs (I'm almost
> certain this used to be a problem).
>
> Thanks,
> Vladi
>
>
> On Mon, Dec 17, 2012 at 2:16 PM, Krasimir Avramski <krasi at smartcom.bg>wrote:
>
>> 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
>>>>>
>>>>
>>>>
>>>
>>
>