[j-nsp] 6pe between Cisco and Juniper

[Mihai Gabriel]

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

 Cisco  can receive both labeled and unlabeled prefixes over the same bgp
session

Cisco 6PE implementation:

Capability Negotiation

Cisco IOS Software already supports Capability Negotiation as specified in
[BGP_CAP], but the Cisco 6PE feature extends BGP capability negotiation for
supporting “IPv6+label” capability in the following way:

•6PE advertises capability for “IPv6+label” to a neighbor when configured
to do so for this neighbor via the new command (see Command Line Interface
section in this document).

•6PE also advertises capability for unlabeled IPv6 since there is a
separate Capabilities Optional Parameters for each SAFI (Subsequent Address
Family Identifier).

•If a neighbor has advertised “IPv6+label” capability, the 6PE advertises
all IPv6 routes as labeled routes.

•If a neighbor has not advertised “IPv6+label” capability but has
advertised “IPv6“ capability, the 6PE advertises all IPv6 routes as IPv6
(unlabelled) routes to this neighbor. Note that if a 6PE receives
unlabelled IPv6 routes, then the 6PE does not resolve the recursion and
marks these prefixes as unreachable in the IPv6 routing table so that
packets to this destination get dropped and not sent into the MPLS cloud.
This behavior avoids having a penultimate MPLS/IPv4 P router dropping an
IPv6 packet because of Penultimate Hop Popping (PHP).

This is what is happening when Cisco announce a non-labeled ipv6 prefix:
Sep  3 23:40:18.324255 BGP RECV flags 0x80 code MP_reach(14): AFI/SAFI 2/1
Sep  3 23:40:18.324277 BGP RECV nhop FC00:1000:1000::1 len 16
Sep  3 23:40:18.324297 BGP RECV xxxx/54 ,
Sep  3 23:40:18.324309 bgp_should_merge_as2_and_as4_path():2111 AS4-Peer
10.10.10.20 (Internal AS 65500)(RECV): No AS4 Path or Aggregator4 Path
Attribute received
Sep  3 23:40:18.324315 bgp_process_aspath_and_aggr_attr():2480 AS4-Peer
10.10.10.20 (Internal AS 65500)(RECV): bgp_should_merge_as2_and_as4_path()
says NO
Sep  3 23:40:18.324323 bgp_process_aspath_and_aggr_attr():2517 AS4-Peer
10.10.10.20 (Internal AS 65500)(RECV): Merged asp: path_len 0, path_seg_len
0, path2_len 0, path2_seg_len 0, path4_len 0, path4_seg_len 0,
path_attr_len 11, path_aggr_len 0, path4_aggr_len 0, path4_flags 0x0,
path_flags 0x4
Sep  3 23:40:18.324365 bgp_read_v4_update:9575: NOTIFICATION sent to
10.10.10.20 (Internal AS 65500): code 3 (Update Message Error) subcode 9
(error with optional attribute), Reason: peer 10.10.10.20 (Internal AS
65500) UPDATE - NLRI inet6-unicast not negotiated


On Mon, Sep 3, 2012 at 7:12 PM, Daniel Roesen <dr at cluenet.de> wrote:

> Hi,
>
> On Mon, Sep 03, 2012 at 11:22:02AM -0400, Colby Barth wrote:
> > Based on the error message:
> >
> > "peer: <inet-unicast inet6-unicast inet6-labeled-unicast>(273) us:
> > <inet-unicast inet6-labeled-unicast>(257)"
> >
> > You need to enable the unicast address family under ipv6
>
> Not really. This "error" message just points out the different
> capability set, but this shouldn't prevent the session to come up. The
> common set of capabilities is <inet-unicast inet6-labeled-unicast>,
> this should work fine. inet6-unicast ain't needed for 6PE anyway, and
> JUNOS even stops you trying to do so.
>
> There is a different reason why the session doesn't come up. Should be
> visible in logs.
>
> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>