[j-nsp] 6pe between Cisco and Juniper

[Mihai]

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
>
>