[j-nsp] 6pe between Cisco and Juniper

[Mihai]

And the cause is... CSCtf27303 .
I made some test with some theoretically non affected IOS versions but 
they have the same behavior (my RR is a Cisco 7201).

Regards

On 09/04/2012 10:06 PM, Mihai wrote:
> The last test was made using a different version of IOS than the first
> time on RR1.Returning to SRD6 brings me back to the initial problem.
> I will give up at 6pe on this Juniper device for a while.
>
> Best regards
>
> On 09/04/2012 08:35 PM, Mihai wrote:
>> The logical topology is this:
>>
>> Juniper <-bgp-> RR1 <-bgp-> Cisco with 6pe (client for RR1, RR2 for CE)
>> <-ipv6 bgp-> non 6pe device (CE).
>>
>> None of your suggestions worked in this setup, so I disabled the bgp
>> session between RR2 and CE and configured a new IPV6 session between CE
>> and RR1 using a new group.
>>
>> ce#sh bgp ipv6 unicast summar | b Nei
>> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
>>
>> FC00:2000:2000::1
>> 4 65500 36 59 6 0 0 00:32:01 0
>> ce#
>>
>> rr1#show bgp ipv6 unicast summary | b Nei
>> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
>> 10.10.10.10 4 65500 118 130 8 0 0 00:10:20 0
>> FC00:1000:1000::1
>> 4 65500 41 36 8 0 0 00:32:54 1
>>
>> juniper#show configuration protocols bgp
>> group test {
>> type internal;
>> local-address 10.10.10.10;
>> family inet {
>> unicast;
>> }
>> family inet6 {
>> labeled-unicast {
>> explicit-null;
>> }
>> }
>> neighbor 10.10.10.20;
>> }
>> group test2 {
>> type internal;
>> local-address fc00:3000:3000::1;
>> family inet6 {
>> unicast;
>> }
>> neighbor FC00:2000:2000::1;
>> }
>>
>> Now both sessions are up,but the prefix received by the neighbor in
>> inet6 labeled-unicast family is strange:
>>
>> juniper#show route receive-protocol bgp 10.10.10.20
>>
>> inet6.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden)
>> Prefix Nexthop MED Lclpref AS path
>> 7700::/23 fc00:1000:1000::1 0 100 I
>>
>> The good thing is that I receive the correct prefix over the ipv6 bgp
>> session and I can block the bad one in inet6 labeled-unicast using a
>> policy.
>>
>> juniper#show route receive-protocol bgp fc00:2000:2000::1
>> * fc00:7777::/47 fc00:1000:1000::1 0 100 I
>>
>> This is a curious case of 6PE:)
>>
>> Thank you all for your answers!
>>
>> On 09/04/2012 05:16 PM, Olivier Benghozi wrote:
>>> No, the neighbor next-hop-self command doesn't have any impact on
>>> reflected routes. But I guess it would prevent IPv6 routes known from
>>> eBGP by the RR to be sent with an IPv6 NH as unlabeled (but maybe
>>> there are none?).
>>> I wonder if BGP IPv6 routes in the RR, known with an IPv6 NH instead
>>> of an IPv4+label NH, could be the source of your problem ? In those
>>> conditions, maybe a generalized next-hop-self in your whole iBGP could
>>> be fine? Just thinking aloud, but it could make sense.
>>>
>>>
>>>> and move all the traffic through RR? :)
>>>>
>>>> On Tue, Sep 4, 2012 at 4:47 PM, Olivier
>>>> Benghozi<olivier.benghozi at wifirst.fr> wrote:
>>>> Maybe you could try to configure next-hop-self on the Cisco's side,
>>>> on all AFI?
>>>>
>>>> Le 4 sept. 2012 à 13:12, Mihai Gabriel a écrit :
>>>>
>>>>> You are partially right. The bgp session is established without
>>>>> inet6-unicast capability advertised by Juniper, but as soon as Juniper
>>>>> receives an ipv6 prefix with a native ipv6 next-hop from Cisco, it
>>>>> will
>>>>> immediately close the session .
>>>>>
>>>>> My Cisco router is a route reflector with a lot of clients and some
>>>>> of them
>>>>> are advertising ipv6 prefixes with a native ipv6 next-hop and also
>>>>> ipv4
>>>>> prefixes.In this setup,closing the session will affect all services..
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>
>