Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Junos] Chained composite next-hop behavior with Inter-AS VPN option B scenario

0

0

Article ID: KB31428 KB Last Updated: 03 Jun 2017Version: 1.0
Summary:

This article explains the behavior of using chained-composite-next-hop along with Inter-AS option B scenario.

Symptoms:

Inter-AS option B scenario is running in the network. Due to certain customer requirements and improved scalability, 'chained-composite-next-hop' is implemented in this network.

A chained composite next hop allows the router to direct sets of routes, sharing the same destination to a common forwarding next hop rather than having each route also include the destination.

Please refer to Juniper documentation on chained-composite-next-hop for more details.

After adding the knob, routes received from peer ASBR are hidden and not installed in the routing table.

Below is the topology for Inter-AS VPN.

           AS1                                  AS2

CE1 ------ PE1 ------ ASBR1------ ASBR2 ------- PE2 ------ CE2


Below is the minimum configuration on ASBR1:

set interfaces ge-1/0/0 unit 0 family inet address 10.10.10.1/24   <-- Towards ASBR2  
set interfaces ge-1/0/0 unit 0 family mpls  
set interfaces ge-1/0/1 unit 0 family inet address 192.168.10.2/24  <-- Towards PE1  
set interfaces ge-1/0/1 unit 0 family mpls  
set interfaces lo0 unit 0 family inet address 2.2.2.2/32    

set protocols bgp group inter-as type external  
set protocols bgp group inter-as family inet-vpn unicast  
set protocols bgp group inter-as family inet-vpn multicast  
set protocols bgp group inter-as family inet6-vpn unicast  
set protocols bgp group inter-as peer-as 7822  
set protocols bgp group inter-as neighbor 10.10.10.2  <-- Physical interface peering towards ASBR2    

set protocols bgp group ibgp type internal  
set protocols bgp group ibgp family inet unicast  
set protocols bgp group ibgp family inet-vpn unicast  
set protocols bgp group ibgp neighbor 1.1.1.1 local-address 2.2.2.2    

set protocols ospf area 0.0.0.0 interface all  
set protocols ospf area 0.0.0.0 interface fxp0.0 disable   

set protocols ldp interface ge-1/0/1.0  
set protocols ldp interface lo0.0

Corresponding configuration from ASBR2 is not shown here in this example.

The following VPN route is received from ASBR2(10.10.10.2) on ASBR1:

root@R2_re# run show route receive-protocol bgp 10.10.10.2

inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden)

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.10.10.2:7:192.168.20.0/24
* 10.10.10.2 7822 I

inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

[edit routing-options]


If we look closely, this route has a direct next-hop which is resolved in inet.0

root@R2_re# run show route 192.168.20/24 extensive

bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
10.10.10.2:7:192.168.20.0/24 (1 entry, 1 announced)
TSI:
Page 0 idx 1, (group ibgp type Internal) Type 1 val 0x9757a84 (adv_entry)
Advertised metrics:
Flags: Nexthop Change
Nexthop: Self
Localpref: 100
AS path: [7821] 7822 I
Communities: target:9000:100
VPN Label: 299808
Path 10.10.10.2:7:192.168.20.0 from 10.10.10.2 Vector len 4. Val: 1
*BGP Preference: 170/-101
Route Distinguisher: 10.10.10.2:7
Next hop type: Router
Address: 0x9784150
Next-hop reference count: 2
Source: 10.10.10.2
Next hop: 10.10.10.2 via ge-1/0/0.0, selected
Label operation: Push 16
Label TTL action: prop-ttl
Load balance label: Label 16: None;
Session Id: 0x0
State: <Active Ext ProtectionPath ProtectionCand>
Local AS: 7821 Peer AS: 7822
Age: 3:37
Validation State: unverified
Task: BGP_7822.10.10.10.2+179
Announcement bits (1): 0-BGP_RT_Background
AS path: 7822 I
Communities: target:9000:100
Accepted
VPN Label: 16
Localpref: 100
Router ID: 128.102.243.166

[edit routing-options]
root@R2_re# run show route 10.10.10.2

inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24 *[Direct/0] 00:05:47
> via ge-1/0/0.0

[edit routing-options]


Now, chained-composite-next-hop is added to the configuration and observe the behavior:

root@R2_re# top show routing-options forwarding-table
chained-composite-next-hop {
    transit {
        l3vpn;
    }
}


Once the configuration is committed, verify the received route again.

[edit routing-options]
root@R2_re# run show route hidden extensive

inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden)

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

bgp.l3vpn.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)
10.10.10.2:7:192.168.20.0/24 (1 entry, 0 announced)
         BGP    Preference: 170/-101
                Route Distinguisher: 10.10.10.2:7
                Next hop type: Unusable
                Address: 0x9421a64
                Next-hop reference count: 1
                State: <Hidden Ext ProtectionPath ProtectionCand>
                Local AS:  7821 Peer AS:  7822
                Age: 1:24
                Validation State: unverified
                Task: BGP_7822.10.10.10.2+179
                AS path: 7822 I
                Communities: target:9000:100
                Accepted
                VPN Label: 16
                Localpref: 100
                Router ID: 128.102.243.166
                Indirect next hops: 1
                        Protocol next hop: 10.10.10.2
                        Label operation: Push 16
                        Label TTL action: prop-ttl
                        Load balance label: Label 16: None;
                        Indirect next hop: 0x0 - INH Session ID: 0x0

 

root@R2_re# run show route 10.10.10.2

inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24      *[Direct/0] 00:12:22
                    > via ge-1/0/0.0


The next-hop is changed to Indirect next-hop, and the route is no-more resolved via inet.0 though we still have the direct route.

Solution:

The behavior seen above is an expected behavior. Once the chained-composite-next-hop is configured, the route will change to indirect-route.

This Indirect route is required to be resolved via inet.3

One way to achieve this is using rib-groups:

set routing-options interface-routes rib-group inet direct-to-inet3
set routing-options rib-groups direct-to-inet3 import-rib inet.0
set routing-options rib-groups direct-to-inet3 import-rib inet.3
set routing-options rib-groups direct-to-inet3 import-policy import-direct

set policy-options policy-statement import-direct term 1 from protocol direct
set policy-options policy-statement import-direct term 1 from route-filter 10.10.10.0/24 exact
set policy-options policy-statement import-direct term 1 then accept
set policy-options policy-statement import-direct term 2 then reject

After the changes, next-hop route is leaked to inet.3 and indirect route is able to resolve next-hop and active again.

root@R2_re# run show route 10.10.10.2

inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24      *[Direct/0] 00:19:36
                    > via ge-1/0/0.0

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24      *[Direct/0] 00:00:03
                    > via ge-1/0/0.0



root@R2_re# run show route 192.168.20/24

bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.2:7:192.168.20.0/24
                   *[BGP/170] 00:10:08, localpref 100
                      AS path: 7822 I, validation-state: unverified
                    > to 10.10.10.2 via ge-1/0/0.0, Push 16

[edit routing-options]

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search