Archive
Juniper Employee , Juniper Employee Juniper Employee
Archive
Inter-AS Option B for IPv4 and IPv6 L3VPNs
Jun 20, 2013

Interprovider or Inter-AS Option B is a well-known documented MPLS L3VPN connectivity option under [RFC4364], Section 10B. This interconnect methodology usually provides a tradeoff between scaling and granularity, and for this reason, it is very popular and widely used by many service providers, especially when interconnecting Autonomous Systems belonging to different organizations. There are plenty of documented use cases about this option, such as the following Juniper Networks whitepaper or these MP-eBGP snippets with Junos OS.

 

Junos OS allows using the same IPv4-based Multiprotocol eBGP (MP-eBGP) session at the NNI (Network-to-Network Interface) to distribute L3VPN routes for IPv4 and IPv6 (VPNv4 or VPNv6 routes). There are no specific requirements as for per-family L3VPN definitions, and this can seamlessly occur for VPNv4 and VPNv6 routes over the same MP-eBGP session. In [RFC4659] parlance, this is a BGP Speaker Requesting IPv4 Transport for IPv6 VPNs, as well as IPv4 VPNs.

 

Junos OS performs next-hop validation checks for received routes and this also applies for this MP-eBGP interconnect. And for such session types, Junos OS currently enforces the [RFC4659], Section 3.2.1.2. alignment:

 

  When the IPv6 VPN traffic is to be transported to the BGP speaker

   using IPv4 tunneling (e.g., IPv4 MPLS LSPs, IPsec-protected IPv4

   tunnels), the BGP speaker SHALL advertise to its peer a Next Hop

   Network Address field containing a VPN-IPv6 address:

[...]

      - whose 16-octet IPv6 address is encoded as an IPv4-mapped IPv6

        address [V6ADDR] containing the IPv4 address of the advertising

        BGP speaker. This IPv4 address must be routable by the other

        BGP Speaker.

 

This leads to certain considerations in this setup regarding IPv6!

 

Examples with Junosphere: Inter-AS Option B for IPv4 and IPv6 L3VPN routes

 

Again, let's make use of Junosphere and convert our usual topology into a dual-homed interprovider B scenario between two different Autonomous Systems:

interASB-e2e-topology.jpg

and within this scenario, let's consider again R1 and R24 as remote PEs sharing a common L3VPN with certain IPv4 and IPv6 routes advertised from inside a VRF at each side:

 

interASB-route-advertisement.jpg

Inter-AS Option B is based on a MP-eBGP session over an MPLS-enabled NNI. Looking at R10 as representative ASBR, a single MP-eBGP session negotiates in our environment both inet-vpn unicast and inet6-vpn unicast families:

 

[edit protocols bgp]

[...]

group eBGP-inet {

   type external;

   local-address 192.168.15.1;

   family inet-vpn {

       unicast;

   }

   family inet6-vpn {

       unicast;

   }

   peer-as 65001;

   neighbor 192.168.15.2;

}

 

How are these routes received and distributed at the ASBRs? Before tuning any other configuration stanza, let's have a look at inet6-vpn routes with BGP traceoptions at R10 for the session with R13:

 

Apr 18 10:32:49.298171 BGP RECV 192.168.15.2+63873 -> 192.168.15.1+179

Apr 18 10:32:49.298192 BGP RECV message type 2 (Update) length 240

Apr 18 10:32:49.298199 BGP RECV Update PDU length 240

Apr 18 10:32:49.298205 BGP RECV flags 0x40 code Origin(1): IGP

Apr 18 10:32:49.298213 BGP RECV flags 0x40 code ASPath(2) length 6: 65001

Apr 18 10:32:49.298220 BGP RECV flags 0xc0 code Extended Communities(16): 2:65000:65001

Apr 18 10:32:49.298226 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 2/128

Apr 18 10:32:49.298235 BGP RECV     nhop ::ffff:192.168.15.2 len 24

Apr 18 10:32:49.298259 BGP RECV     192.168.255.24:1:2001:db8:6500:1::/64 (label 300752) , 192.168.255.24:1:2001:db8:6500:1::1/128 (label 300752) , 192.168.255.24:1:2001:db8:6500:1::2/128 (label 300752) , 192.168.255.24:1:2001:db8:6500:1::3/128 (label 300752)

Apr 18 10:32:49.298274 BGP RECV     192.168.255.24:1:2001:db8:6500:1::4/128 (label 300752) , 192.168.255.24:1:2001:db8:6500:1::5/128 (label 300752)

Apr 18 10:32:49.298290 bgp_should_merge_as2_and_as4_path():2051 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): No merge of as-paths required as the peer is 4 byte as capable

Apr 18 10:32:49.298298 bgp_process_aspath_and_aggr_attr():2500 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): bgp_should_merge_as2_and_as4_path() says NO

Apr 18 10:32:49.298306 bgp_process_aspath_and_aggr_attr():2537 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): Merged asp: path_len 4, path_seg_len 2, path2_len 0, path2_seg_len 0, path4_len 0, path4_seg_len 0, path_attr_len 0, path_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0

Apr 18 10:32:49.298347 bgp_nexthop_sanity: peer 192.168.15.2 (External AS 65001) next hop ::ffff:192.168.15.2 unexpectedly remote, ignoring routes in this update

Apr 18 10:32:49.298362 bgp_rcv_nlri: Peer 192.168.15.2 (External AS 65001)

Apr 18 10:32:49.298373 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::/128

Apr 18 10:32:49.298383 bgp_rcv_nlri: Uninstalling 192.168.255.24:1:2001:db8:6500:1::/128: route entry not found

Apr 18 10:32:49.298393 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::1/192

Apr 18 10:32:49.298403 bgp_rcv_nlri: Uninstalling 192.168.255.24:1:2001:db8:6500:1::1/192: route entry not found

Apr 18 10:32:49.298421 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::2/192

Apr 18 10:32:49.298431 bgp_rcv_nlri: Uninstalling 192.168.255.24:1:2001:db8:6500:1::2/192: route entry not found

Apr 18 10:32:49.298441 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::3/192

Apr 18 10:32:49.298451 bgp_rcv_nlri: Uninstalling 192.168.255.24:1:2001:db8:6500:1::3/192: route entry not found

Apr 18 10:32:49.298460 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::4/192

Apr 18 10:32:49.298470 bgp_rcv_nlri: Uninstalling 192.168.255.24:1:2001:db8:6500:1::4/192: route entry not found

Apr 18 10:32:49.298480 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::5/192

Apr 18 10:32:49.298489 bgp_rcv_nlri: Uninstalling 192.168.255.24:1:2001:db8:6500:1::5/192: route entry not found

 

And this is interpreted in the following fashion: for inet6-vpn routes advertised over an IPv4 based MP-eBGP session, their next-hop attribute is correspondingly translated to an IPv4-mapped IPv6 address for forwarding consistency and sanity purposes, as per [RFC4659], Section 3.2.1.2. If such BGP route next hop does not match any from the directly connected NNI addresses, these updates get subsequently discarded when carrying out such next-hop resolution checks.

 

Using accept-remote-nexthop or multihop at interAS Option B MP-eBGP sessions does not help

 

Trying to skip such in-built next-hop validation in a MP-eBGP session, maybe any reader can be tempted to evaluate the accept-remote-nexthop option in the MP-eBGP session configuration, as explained at http://www.juniper.net/techpubs/en_US/junos12.2/topics/example/bgp-accept-remote-nexthop.html. This option was exactly created to be able to accept non-local next hops in the incoming BGP NLRIs over the external sessions (note that this knob was briefly addressed as well in my previous post IPv6 destination remote triggered blackholing with the 6PE model - Part I).

 

Let's have a look at this configuration option in the R10 MP-eBGP session towards R13:

 

[edit protocols bgp]

juniper@R10# set group eBGP-inet accept-remote-nexthop

[...]

[edit]

juniper@R10# commit and-quit

commit complete

Exiting configuration mode

 

BGP traceoptions illustrate the following in this case:

 

Apr 18 10:43:57.990975 BGP RECV 192.168.15.2+63873 -> 192.168.15.1+179

Apr 18 10:43:57.990982 BGP RECV message type 2 (Update) length 240

Apr 18 10:43:57.990987 BGP RECV Update PDU length 240

Apr 18 10:43:57.990996 BGP RECV flags 0x40 code Origin(1): IGP

Apr 18 10:43:57.991004 BGP RECV flags 0x40 code ASPath(2) length 6: 65001

Apr 18 10:43:57.991010 BGP RECV flags 0xc0 code Extended Communities(16): 2:65000:65001

Apr 18 10:43:57.991015 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 2/128

Apr 18 10:43:57.991039 BGP RECV     nhop ::ffff:192.168.15.2 len 24

Apr 18 10:43:57.991070 BGP RECV     192.168.255.24:1:2001:db8:6500:1::/64 (label 300752) , 192.168.255.24:1:2001:db8:6500:1::1/128 (label 300752) , 192.168.255.24:1:2001:db8:6500:1::2/128 (label 300752) , 192.168.255.24:1:2001:db8:6500:1::3/128 (label 300752)

Apr 18 10:43:57.991079 BGP RECV     192.168.255.24:1:2001:db8:6500:1::4/128 (label 300752) , 192.168.255.24:1:2001:db8:6500:1::5/128 (label 300752)

Apr 18 10:43:57.991108 bgp_should_merge_as2_and_as4_path():2051 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): No merge of as-paths required as the peer is 4 byte as capable

Apr 18 10:43:57.991114 bgp_process_aspath_and_aggr_attr():2500 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): bgp_should_merge_as2_and_as4_path() says NO

Apr 18 10:43:57.991119 bgp_process_aspath_and_aggr_attr():2537 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): Merged asp: path_len 4, path_seg_len 2, path2_len 0, path2_seg_len 0, path4_len 0, path4_seg_len 0, path_attr_len 0, path_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0

Apr 18 10:43:57.991160 bgp_rcv_nlri: Peer 192.168.15.2 (External AS 65001)

Apr 18 10:43:57.991170 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::/128

Apr 18 10:43:57.991242 ADD      192.168.255.24:1:2001:db8:6500:1::/128  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001

Apr 18 10:43:57.991278 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::1/192

Apr 18 10:43:57.991305 ADD      192.168.255.24:1:2001:db8:6500:1::1/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001

Apr 18 10:43:57.991322 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::2/192

Apr 18 10:43:57.991351 ADD      192.168.255.24:1:2001:db8:6500:1::2/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001

Apr 18 10:43:57.991370 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::3/192

Apr 18 10:43:57.991389 ADD      192.168.255.24:1:2001:db8:6500:1::3/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001

Apr 18 10:43:57.991422 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::4/192

Apr 18 10:43:57.991441 ADD      192.168.255.24:1:2001:db8:6500:1::4/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001

Apr 18 10:43:57.991453 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::5/192

Apr 18 10:43:57.991470 ADD      192.168.255.24:1:2001:db8:6500:1::5/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001

Apr 18 10:43:57.991484 rt_close: 6 routes proto BGP_65001.192.168.15.2+63873

 

 

Relaxing this next-hop sanity check at the NNI with accept-remote-nexthop yields route acceptance, albeit these routes become hidden because of an unusable path:

 

juniper@R10> show route hidden extensive

[...]

bgp.l3vpn-inet6.0: 12 destinations, 30 routes (12 active, 0 holddown, 6 hidden)

192.168.255.24:1:2001:db8:6500:1::/64 (3 entries, 0 announced)

         BGP    Preference: 170/-101

                Route Distinguisher: 192.168.255.24:1

                Next hop type: Unusable

                Address: 0x903e204

                Next-hop reference count: 6

                State: <Hidden Ext ProtectionCand>

                Inactive reason: Unusable path

                Local AS: 65000 Peer AS: 65001

                Age: 54

                Validation State: unverified

                Task: BGP_65001.192.168.15.2+63873

                AS path: 65001 I

                Communities: target:65000:65001

                Accepted

                VPN Label: 300752

                Localpref: 100

                Router ID: 192.168.255.13

                Indirect next hops: 1  

                        Protocol next hop: ::ffff:192.168.15.2

                        Push 300752

                        Indirect next hop: 0 - INH Session ID: 0x0

[...]

 

 

At the end of the day, the next-hop inconsistency is still there. The next-hop acceptance is relaxed but there is still no correspondence between the BGP route next hop and any other eligible IPv6 prefix. And the same results can be observed if it is attempted to leverage such next-hop checks converting this MP-eBGP peering into a multihop session.

 

Despite all these options, there is still no known or valid next hop for such routes at the Interprovider NNI.


Setting adequate IPv6 addresses at interAS Option B NNIs

 

The simplest option is to adjust NNI IPv6 addressing to match the respective IPv4-mapped IPv6 address that results as automatically translated next hop from a single MP-eBGP session. This means that a network administrator can add IPv6 addresses to the NNI with the objective to align this automatic translation for the next-hop address. The ultimate intention behind this interface configuration adjustment is that the described BGP next-hop sanity check yields a positive result, because both MP_REACH_NLRI next-hop field and IPv6 local interface direct route match.

 

In our example, if the inet6-vpn BGP routes derived an automatic next hop matching ::ffff:192.168.15.2 after mapping the MP-eBGP session peering address, the same IPv6 address can be also explicitly enforced in this NNI with the respective netmask that grants validity for this automatic translation.

 

At R10, as simple as adding an aligned IPv6 address with a netmask that allows resolving ::ffff:192.168.15.2, that is,  /126 at a minimum:

 

[edit interfaces ge-0/0/3.0]

family inet {

    address 192.168.15.1/30;

}

family inet6 {

    address ::ffff:192.168.15.1/126;

}

family mpls;

 

When setting these respective addresses in the interconnect logical interface, BGP traceoptions prove the next hop validity:

 

Apr 18 10:23:50.872007 BGP RECV 192.168.15.2+179 -> 192.168.15.1+61294

Apr 18 10:23:50.872017 BGP RECV message type 2 (Update) length 240

Apr 18 10:23:50.872022 BGP RECV Update PDU length 240

Apr 18 10:23:50.872028 BGP RECV flags 0x40 code Origin(1): IGP

Apr 18 10:23:50.872036 BGP RECV flags 0x40 code ASPath(2) length 6: 65001

Apr 18 10:23:50.872043 BGP RECV flags 0xc0 code Extended Communities(16): 2:65000:65001

Apr 18 10:23:50.872050 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 2/128

Apr 18 10:23:50.872059 BGP RECV     nhop ::ffff:192.168.15.2 len 24

Apr 18 10:23:50.872083 BGP RECV     192.168.255.24:1:2001:db8:6500:1::/64 (label 300560) , 192.168.255.24:1:2001:db8:6500:1::1/128 (label 300560) , 192.168.255.24:1:2001:db8:6500:1::2/128 (label 300560) , 192.168.255.24:1:2001:db8:6500:1::3/128 (label 300560)

Apr 18 10:23:50.872097 BGP RECV     192.168.255.24:1:2001:db8:6500:1::4/128 (label 300560) , 192.168.255.24:1:2001:db8:6500:1::5/128 (label 300560)

Apr 18 10:23:50.872112 bgp_should_merge_as2_and_as4_path():2051 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): No merge of as-paths required as the peer is 4 byte as capable

Apr 18 10:23:50.872120 bgp_process_aspath_and_aggr_attr():2500 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): bgp_should_merge_as2_and_as4_path() says NO

Apr 18 10:23:50.872157 bgp_process_aspath_and_aggr_attr():2537 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): Merged asp: path_len 4, path_seg_len 2, path2_len 0, path2_seg_len 0, path4_len 0, path4_seg_len 0, path_attr_len 0, path_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0

Apr 18 10:23:50.872185 bgp_rcv_nlri: Peer 192.168.15.2 (External AS 65001)

Apr 18 10:23:50.872199 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::/128

Apr 18 10:23:50.872238 rt_loser_eval: New is better.  Flags: 8008000 800c020

Apr 18 10:23:50.872275 CHANGE   192.168.255.24:1:2001:db8:6500:1::/128  nhid 0 gw ::ffff:192.168.15.2 BGP      pref 170/-101 metric  ge-0/0/3.0 <Active Ext ProtectionCand>  as 65001

Apr 18 10:23:50.872291 ADD      192.168.255.24:1:2001:db8:6500:1::/128  nhid 0 gw ::ffff:192.168.15.2 BGP      pref 170/-101 metric  ge-0/0/3.0 <Active Ext ProtectionCand>  as 65001

Apr 18 10:23:50.872305 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::1/192

Apr 18 10:23:50.872327 rt_loser_eval: New is better.  Flags: 8008000 800c020

[...]

 

The following diagram summarizes therefore these settings for both NNIs in this Interprovider Option B scenario:

interASB-next-hop-settings.jpg

It is very important to note that the selected netmask for the interface IPv6 address definition must allow complete alignment between this NNI address and the BGP next hop. In this case, selecting a /127 would not fly, for instance, unless the IPv4 WAN addresing scheme is converted into a /31 and MP-eBGP peering addresses therefore match again with IPv4-mapped IPv6 translated next hops.

 

Conclusions

 

Coming back to the original motivation for this post, a key component in the Option B interconnect for inet6-vpn addresses is the NNI addressing configuration.

 

This coupling between inet6-vpn BGP route next hops and peering addresses needs to be enforced in current Junos OS releases to be aligned with [RFC4659], Section 3.2.1.2. and ensure that, despite being MPLS switched at the interconnect, there is consistency for IPv6 forwarding. That is, there needs to be a valid IPv6 next hop for inet6-vpn routes, because Junos OS always validates a viable next hop from the same address family.

 

Beware of this dependency, especially whenever you want to upgrade existing inet-vpn only Interprovider Option B connections with new inet6-vpn routes. It does not suffice with adding a new AFI/SAFI to your MP-eBGP session, next hops need to be tuned at the NNI as well!

 

I hope this can provide some feedback to Vikram in his questions, and food for thought for those who were not aware. Any comments, please be my guest and chime in as usual.

Sep 3, 2013

Another option would be to use routing policy to change the next-hop to that of the inet6 address on the interface. This scenario isn't necessarily specific to Interprovider VPN, either. It goes for any scenario with both address families being carried over a single EBGP peering. 

 

Great article, can't wait to see more!

Sep 17, 2013
Juniper Employee

Hi ,

 

thanks for chiming in!

 

This is indeed very valuable feedback and also an excuse to follow up and extend this article Smiley Wink

 

The original config was actually focused on [RFC4659], Section 3.2.1.2, with regards to next-hop enforcements for BGP Speaker Requesting IPv4 Transport for IPv6 VPNs:

 

   When the IPv6 VPN traffic is to be transported to the BGP speaker
   using IPv4 tunneling (e.g., IPv4 MPLS LSPs, IPsec-protected IPv4
   tunnels), the BGP speaker SHALL advertise to its peer a Next Hop
   Network Address field containing a VPN-IPv6 address:
      - whose 8-octet RD is set to zero, and
      - whose 16-octet IPv6 address is encoded as an IPv4-mapped IPv6
        address [V6ADDR] containing the IPv4 address of the advertising
        BGP speaker.  This IPv4 address must be routable by the other
        BGP Speaker.

 

but as you said, it is possible to rewrite the next hop to the peering interface inet6 address (albeit different from the IPv4-mapped IPv6 address derived from eBGP IPv4-based peering) with an export policy.

 

Taking the same example from this article and setting another specific IPv6 address in the same logical interface:

 

At R10:

 

[edit interfaces]

ge-0/0/3 {
    description R10<-->R13;
    unit 0 {
        family inet {
            address 192.168.15.1/30;    
        }
        family iso;
        family inet6 {
            address 2001:0db8:15::1/126;
        }
        family mpls;
    }
}

 

and at R13:

 

[edit protocols bgp]

group eBGP-inet {
    type external;
    local-address 192.168.15.2;
    family inet-vpn {
        unicast;
    }
    family inet6-vpn {
        unicast;
    }
    export rewrite-inet6-nexthop;
    peer-as 65000;
    neighbor 192.168.15.1;
}

 

[edit interfaces]
ge-0/0/1 {
    description R10<-->R13;
    unit 0 {
        family inet {
            address 192.168.15.2/30;
        }
        family iso;
        family inet6 {
            address 2001:0db8:15::2/126;
        }
        family mpls;
    }
}

 

Note that the 'from family' condition in Junos OS can greatly help you fine tune next-hop settings for such multi-family BGP sessions:

 

juniper@R13> show configuration policy-options policy-statement rewrite-inet6-nexthop
term inet6vpn {
    from family inet6-vpn;
    then {
        next-hop 2001:0db8:15::2;
    }
}

When setting up the BGP session like that, following can be observed through traceoptions:

 

Sep 16 06:41:42.673608 BGP RECV Update PDU length 163
Sep 16 06:41:42.673617 BGP RECV flags 0x40 code Origin(1): IGP
Sep 16 06:41:42.673626 BGP RECV flags 0x40 code ASPath(2) length 6: 65001
Sep 16 06:41:42.673635 BGP RECV flags 0xc0 code Extended Communities(16): 2:65000:65001
Sep 16 06:41:42.673643 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 1/128
Sep 16 06:41:42.673652 BGP RECV     nhop 192.168.15.2 len 12
Sep 16 06:41:42.673669 BGP RECV     192.168.255.24:1:198.51.100.4/32 (label 300800) , 192.168.255.24:1:198.51.100.3/32 (label 300800) , 192.168.255.24:1:198.51.100.5/32 (label 300800) , 192.168.255.24:1:198.51.100.1/32 (label 300800)
Sep 16 06:41:42.673681 BGP RECV     192.168.255.24:1:198.51.100.0/24 (label 300800) , 192.168.255.24:1:198.51.100.2/32 (label 300800)
Sep 16 06:41:42.673702 bgp_should_merge_as2_and_as4_path():2051 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): No merge of as-paths required as the peer is 4 byte as capable
[...]

Sep 16 06:41:42.794925
Sep 16 06:41:42.794925 BGP RECV 192.168.15.2+179 -> 192.168.15.1+55333
Sep 16 06:41:42.794938 BGP RECV message type 2 (Update) length 240
Sep 16 06:41:42.794945 BGP RECV Update PDU length 240
Sep 16 06:41:42.794952 BGP RECV flags 0x40 code Origin(1): IGP
Sep 16 06:41:42.794961 BGP RECV flags 0x40 code ASPath(2) length 6: 65001
Sep 16 06:41:42.794970 BGP RECV flags 0xc0 code Extended Communities(16): 2:65000:65001
Sep 16 06:41:42.794978 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 2/128
Sep 16 06:41:42.794989 BGP RECV     nhop 2001:db8:15::2 len 24
Sep 16 06:41:42.795016 BGP RECV     192.168.255.24:1:2001:db8:6500:1::2/128 (label 300816) , 192.168.255.24:1:2001:db8:6500:1::/64 (label 300816) , 192.168.255.24:1:2001:db8:6500:1::5/128 (label 300816) , 192.168.255.24:1:2001:db8:6500:1::4/128 (label 300816)
Sep 16 06:41:42.795032 BGP RECV     192.168.255.24:1:2001:db8:6500:1::3/128 (label 300816) , 192.168.255.24:1:2001:db8:6500:1::1/128 (label 300816)
Sep 16 06:41:42.795051 bgp_should_merge_as2_and_as4_path():2051 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): No merge of as-paths required as the peer is 4 byte as capable
Sep 16 06:41:42.795061 bgp_process_aspath_and_aggr_attr():2500 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): bgp_should_merge_as2_and_as4_path() says NO
Sep 16 06:41:42.795086 bgp_process_aspath_and_aggr_attr():2537 AS4-Peer 192.168.15.2 (External AS 65001)(RECV): Merged asp: path_len 4, path_seg_len 2, path2_len 0, path2_seg_len 0, path4_len 0, path4_seg_len 0, path_attr_len 0, path_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0
Sep 16 06:41:42.795118 bgp_rcv_nlri: Peer 192.168.15.2 (External AS 65001)
Sep 16 06:41:42.795134 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::2/192
Sep 16 06:41:42.795175 ADD      192.168.255.24:1:2001:db8:6500:1::2/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001
Sep 16 06:41:42.795204 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::/128
Sep 16 06:41:42.795234 ADD      192.168.255.24:1:2001:db8:6500:1::/128  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001
Sep 16 06:41:42.795255 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::5/192
Sep 16 06:41:42.795284 ADD      192.168.255.24:1:2001:db8:6500:1::5/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001
Sep 16 06:41:42.795304 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::4/192
Sep 16 06:41:42.795368 ADD      192.168.255.24:1:2001:db8:6500:1::4/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001
Sep 16 06:41:42.795395 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::3/192
Sep 16 06:41:42.795424 ADD      192.168.255.24:1:2001:db8:6500:1::3/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001
Sep 16 06:41:42.795444 bgp_rcv_nlri: 192.168.255.24:1:2001:db8:6500:1::1/192
Sep 16 06:41:42.795482 ADD      192.168.255.24:1:2001:db8:6500:1::1/192  nhid 0  BGP      pref 170/-101 metric  <Hidden Ext ProtectionCand>  as 65001
Sep 16 06:41:42.795513 rt_close: 6 routes proto BGP_65001.192.168.15.2+179

So, effectively, we have next hops from the same peering interface and different families. As said, this is tuned to be an inet6 address from the same interface:

 

juniper@R10> show route 2001:db8:6500:1::5/128 extensive    

bgp.l3vpn-inet6.0: 12 destinations, 24 routes (12 active, 0 holddown, 0 hidden)
192.168.255.24:1:2001:db8:6500:1::5/128 (2 entries, 1 announced)
TSI:
Page 0 idx 0 Type 1 val 92823c4
    Flags: Nexthop Change
    Nexthop: Self
    Localpref: 100
    AS path: [65000] 65001 I
    Communities: target:65000:65001
Path 192.168.255.24:1:2001:db8:6500:1::5 from 192.168.15.2 Vector len 4.  Val: 0
        *BGP    Preference: 170/-101
                Route Distinguisher: 192.168.255.24:1
                Next hop type: Router
                Address: 0x9306364
                Next-hop reference count: 7
                Source: 192.168.15.2
                Next hop: 2001:db8:15::2 via ge-0/0/3.0, selected
                Label operation: Push 300976
                Label TTL action: prop-ttl
                Session Id: 0x8
                State: <Active Ext ProtectionCand>
                Local AS: 65000 Peer AS: 65001
                Age: 47
                Validation State: unverified
                Task: BGP_65001.192.168.15.2+179
                Announcement bits (1): 0-BGP_RT_Background
                AS path: 65001 I
                Communities: target:65000:65001
                Accepted
                VPN Label: 300976
                Localpref: 100
                Router ID: 192.168.255.13
         BGP    Preference: 170/-101    
                Route Distinguisher: 192.168.255.24:1
                Next hop type: Indirect
                Address: 0x9306a38
                Next-hop reference count: 6
                Source: 192.168.255.12
                Protocol next hop: ::ffff:192.168.255.11
                Push 300432
[...]

 

This is actually inspired by options offered by [RFC4271], Section 5.3.1 for next-hop settings:

 

    2) When sending a message to an external peer, X, and the peer is
         one IP hop away from the speaker:
          [...]
         - Otherwise, if the external peer to which the route is being
           advertised shares a common subnet with one of the interfaces
           of the announcing BGP speaker, the speaker MAY use the IP
           address associated with such an interface in the NEXT_HOP
           attribute.  This is known as a "first party" NEXT_HOP
           attribute.
         - By default (if none of the above conditions apply), the BGP
           speaker SHOULD use the IP address of the interface that the
           speaker uses to establish the BGP connection to peer X in the
           NEXT_HOP attribute.

 

If another arbitrary Next-hop value needs to be set for the BGP attribute, it is actually required to look for additional artifacts (some of them reviewed under IPv6 destination remote triggered blackholing with the 6PE model - Part I), such as converting this eBGP peering into a multihop session etc.

 

@ , is this the way you implemented it? Do you agree with this approach or have tested other alternatives? Would love to hear your feedback!

 

Thanks,

 

Gonzalo

 

Jun 21, 2016

Hi Gonzalo,

 

I've found an import rewrite next hop is _required_ for InterAS on Juniper with a Cisco on the other side as the ::ffff:x.x.x.x/126 doesn't appear to work.

 

Regards,

  Brett

 

Jun 22, 2016
Juniper Employee

Hi Brett,

 

many thanks for getting in touch. Would you mind sharing the details (config, tcpdump)? I would like to understand which Next Hop was used for the advertisement of the specific NLRIs (since the above is based on resolving the Next Hop over a common and local IPv6 subnet).

 

Thanks a lot for chiming in and providing feedback!

 

Gonzalo

Mar 7, 2018
Basondole Paul

Hi All,

The proble with Juniper-Cisco NNI is that Junper does not allow IPv6-tunneling on eBGP routes, therefore we have to manually make the IPv4-mapped IPv6 address to be resolved. Below I used the import policy to change the next-hop address from eBGP Cisco peer

 

 

Configuration on the Juniper ASBR (AS300) :

 

set protocols bgp group eBGP-inet type external

set protocols bgp group eBGP-inet peer-as 300

set protocols bgp group eBGP-inet local-as 100

set protocols bgp group eBGP-inet family inet6 labeled-unicast explicit-null
set protocols bgp group eBGP-inet accept-remote-nexthop
set protocols bgp group eBGP-inet import CHANGE-inet6.0-NEXT-HOP
set protocols bgp group eBGP-inet neighbor 80.100.100.2

set protocol mpls interface em1.250

set interface em1.250 vlan-id 250 description "NNI to CISCO"
set interface em1.250 family inet address 80.100.100.1/30
set interface em1.250 family inet6
set interface em1.250 family mpls

set policy-option policy-state CHANGE-inet6.0-NEXT-HOP from family inet6
set policy-option policy-state CHANGE-inet6.0-NEXT-HOP then next-hop 80.100.100.2

 

Configuration on Cisco ASBR (AS100) :

router bgp 100
 neighbor eBGP-6PE peer-group
 neighbor eBGP-6PE remote-as 300
 neighbor 80.100.100.1 peer-group eBGP-6PE
address-family ipv6
  neighbor eBGP-6PE send-community both
  neighbor eBGP-6PE send-label
  neighbor 80.100.100.1 activate

interface FastEthernet0/0.250
 description INTER-AS LINK
 encapsulation dot1Q 250
 ip address 80.100.100.2 255.255.255.252
 mpls bgp forwarding

 

Note: the family inet must be activated on the Juniper NNI interface (no need of IPv6 address to be configured for this, just activate the family inet6). With this configuration the next-hop of the received IPv6 addresses must be change to the IPv4 address of the Cisco.

Altenatively an IPv6 address can be configured on both Juniper and Cisco and the IPv6 on the cisco address can be used as the next hop on the policy. See below altered configuration;

 

Juniper (add the IPv6 address on the NNI and change the next hop in the import policy)

set interface em1.250 vlan-id 250 description "INTER-AS LINK"
set interface em1.250 family inet address 80.100.100.1/30
set interface em1.250 family inet6 address 2001:abcd::1/64
set interface em1.250 family mpls

set policy-option policy-state CHANGE-inet6.0-NEXT-HOP from family inet6
set policy-option policy-state CHANGE-inet6.0-NEXT-HOP then next-hop 2001:abcd::2

 

Cisco (only add the IPv6)

interface FastEthernet0/0.250
 description INTER-AS LINK
 encapsulation dot1Q 250
 ip address 80.100.100.2 255.255.255.252

 ipv6 address 2001:abcd::2/64
 mpls bgp forwarding

 

Checking the RIBs on both ASBRs

 

Below is a 6PE route received from Cisco:

The route 2001:ab33::/64 is received with next hop ::ffff:80.100.100.2, this is IPv4-mapped IPv6

 

# run show route table inet6.0 receive-protocol bgp 80.100.100.2

inet6.0: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 2001:ab33::/64          ::ffff:80.100.100.2  0                  100 ?

 

The import policy changes the next hop to a usable IPv4 address

 

#run show route 2001:ab33::33 table inet6.0 protocol bgp extensive

Path 2001:ab33:: from 80.100.100.2 Vector len 4.  Val: 0
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 618
                Address: 0x93347f0
                Next-hop reference count: 3
                Source: 80.100.100.2
                Next hop: 80.100.100.2 via em1.250, selected
                Label operation: Push 17
                Label TTL action: prop-ttl
                State: <Active Ext>
                Local AS:   300 Peer AS:   100
                Age: 35:43      Metric: 0
                Task: BGP_100.80.100.100.2+179
                Announcement bits (3): 0-KRT 1-BGP_RT_Background 2-Resolve tree 4
                AS path: 100 ?
                Accepted
                Route Label: 17
                Localpref: 100
                Router ID: 11.11.11.33

 

On Cisco side below route is received from Juniper (the next-hop is an IPv4-mapped IPv6)

 

#show bgp ipv6 unicast neighbors 80.100.100.1 received-routes | begin Network

     Network          Next Hop            Metric LocPrf Weight Path
 *>  2001:AB44::/64   ::FFFF:80.100.100.1                   0  300 i

 

Cisco resolves the IPv4-mapped IPv6 to the IPv4 next-hop

 

#show ipv6 route 2001:AB44::/64
Routing entry for 2001:AB44::/64
  Known via "bgp 100", distance 20, metric 0, type external
  Route count is 1/1, share count 0
  Routing paths:
    80.100.100.1%default indirectly connected
      MPLS label: 2
      Last updated 00:56:19 ago

 

For 6VPE there is no need of activating the inet6 family on the NNI. Only application of the import policy to change the next hop is neccessary on the Juniper side and family inet6-vpn must be activated on the eBGP group. On Cisco side address-family vpnv6 is to be used

 

Feedback