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<[email protected]> 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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
