[j-nsp] 6pe between Cisco and Juniper

[Mihai]

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