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

[M/MX/T] Configuration Sample: How to make EBGP router accept/install routes with remote-nexthop value from Single-Hop neighbor

0

0

Article ID: KB15993 KB Last Updated: 19 Aug 2021Version: 4.0
Summary:

This article details how to make EBGP router accept/install routes with remote-nexthop value from Single-Hop neighbor while peering with directly connected physical address.

Symptoms:

In some situations, it is necessary to configure a single-hop EBGP peer to accept a remote next-hop with which it does not share a common subnet. The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded.

Solution:

This requirement of accepting a route from single-hop EBGP peer with remote next-hop is met by the combination of "import policy" and command "accept-remote-nexthop".

  • "Import policy" matches prefixes and changes their next-hop value to a preferred remote-nexthop.

  • "accept-remote-nexthop" enables this EBGP peer to install routes with remote-nexthop value.

Both the remote next-hop and the EBGP peer must support BGP route refresh as defined in RFC 2918, Route Refresh Capability in BGP-4. If the remote peer does not support BGP route refresh, the session is reset.

Sample Topology:

R1(183.1.1.1)----EBGP peering using directly connected physical IP address------(183.1.1.2)R2(173.1.1.1)-----IBGP peering using loopb-----(173.1.1.2)R3

In this setup, R2 is sending 5 prefixes to R1 with the next-hop value set to its own physical peering address; that is 183.1.1.2.R3 is only used to send the prefixes to R2 on the IBGP session and in turn R2 advertises those prefixes to R1.

On R1, the requirement is to match the prefixes and change their next-hop value to 173.1.1.2 before installing in the routing table. This is achieved by the combination of the import policy named "remotenexthop" and command "accept-remote-nexthop."

Configuration on the routers:

R1:
---
user@R1# show
## Last changed: 2009-11-29 09:39:18 UTC
version 9.6R1.13;
system {
host-name R1;
root-authentication {
encrypted-password "$ABC123"; ## SECRET-DATA
}
login {
user lab {
uid 2002;
class super-user;
authentication {
encrypted-password "$ABC123"; ## SECRET-DATA
}
}
}
}
interfaces {
t1-0/2/0 {
unit 0 {
family inet {
address 183.1.1.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 201.218.212.1/32;
}
}
}
}
routing-options {
autonomous-system 200;
}
protocols {
bgp {
group EBGP {
import remotenexthop;
neighbor 183.1.1.2 {
accept-remote-nexthop;
peer-as 100;
}
}
}
ospf {
area 0.0.0.0 {
interface all;
}
}
}
policy-options {
policy-statement remotenexthop {
term 1 {
from {
route-filter 210.1.1.0/24 exact;
route-filter 210.1.2.0/24 exact;
route-filter 210.1.3.0/24 exact;
route-filter 210.1.4.0/24 exact;
route-filter 210.1.5.0/24 exact;
}
then {
next-hop 173.1.1.2;
}
}
}
}

[edit]
user@R1#

R2:

---
root@R2# show
## Last changed: 2009-11-29 09:26:16 UTC
version 9.6R1.13;
system {
host-name R2;
root-authentication {
encrypted-password "$ABC123"; ## SECRET-DATA
}
}
interfaces {
cstm1-0/0/0 {
no-partition interface-type so;
}
so-0/0/0 {
unit 0 {
family inet {
address 173.1.1.1/24;
}
}
}
t1-0/2/0 {
unit 0 {
family inet {
address 183.1.1.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 205.10.1.1/32;
}
}
}
}
routing-options {
autonomous-system 100;
}
protocols {
bgp {
group EBGP {
neighbor 183.1.1.1 {
peer-as 200;
}
}
group IBGP {
neighbor 3.3.3.3 {
local-address 205.10.1.1;
peer-as 100;
}
}
}
ospf {
area 0.0.0.0 {
interface all;
}
}
}

[edit]
root@R2#

R3:

---
lab@R3# show
## Last changed: 2009-11-29 09:49:25 UTC
version 9.6R1.13;
system {
host-name R3;
root-authentication {
encrypted-password "$ABC123"; ## SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
encrypted-password "$ABC123"; ## SECRET-DATA
}
}
}
}
interfaces {
cstm1-0/1/0 {
no-partition interface-type so;
}
so-0/1/0 {
unit 0 {
family inet {
address 173.1.1.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 3.3.3.3/32;
}
}
}
}
routing-options {
static {
route 210.1.1.0/24 discard;
route 210.1.2.0/24 discard;
route 210.1.3.0/24 discard;
route 210.1.4.0/24 discard;
route 210.1.5.0/24 discard;
}
autonomous-system 100;
}
protocols {
bgp {
group IBGP {
export exportstatic;
neighbor 205.10.1.1 {
local-address 3.3.3.3;
peer-as 100;
}
}
}
ospf {
area 0.0.0.0 {
interface all;
}
}
}
policy-options {
policy-statement exportstatic {
term 1 {
from protocol static;
then accept;
}
}
}

[edit]
lab@R3#

Snapshots from R1:

-----------------------------
user@R1> show route protocol bgp

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

210.1.1.0/24 *[BGP/170] 00:42:43, localpref 100, from 183.1.1.2
AS path: 100 I
> via t1-0/2/0.0
210.1.2.0/24 *[BGP/170] 00:42:43, localpref 100, from 183.1.1.2
AS path: 100 I
> via t1-0/2/0.0
210.1.3.0/24 *[BGP/170] 00:42:43, localpref 100, from 183.1.1.2
AS path: 100 I
> via t1-0/2/0.0
210.1.4.0/24 *[BGP/170] 00:42:43, localpref 100, from 183.1.1.2
AS path: 100 I
> via t1-0/2/0.0
210.1.5.0/24 *[BGP/170] 00:42:43, localpref 100, from 183.1.1.2
AS path: 100 I
> via t1-0/2/0.0

user@R1> show route 210.1.1.0 extensive

inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden)
210.1.1.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 210.1.1.0/24 -> {indirect(262142)}
*BGP Preference: 170/-101
Next hop type: Indirect
Next-hop reference count: 15
Source: 183.1.1.2
Next hop type: Router, Next hop index: 541
Next hop: via t1-0/2/0.0, selected
Protocol next hop: 173.1.1.2
Indirect next hop: 8d96000 262142
State: <Active Ext>
Local AS: 200 Peer AS: 100
Age: 44:17 Metric2: 66
Task: BGP_100.183.1.1.2+61015
Announcement bits (2): 0-KRT 4-Resolve tree 1
AS path: 100 I
Accepted
Localpref: 100
Router ID: 205.10.1.1
Indirect next hops: 1
Protocol next hop: 173.1.1.2 Metric: 66
Indirect next hop: 8d96000 262142
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: via t1-0/2/0.0
173.1.1.0/24 Originating RIB: inet.0
Metric: 66 Node path count: 1
Forwarding nexthops: 1
Nexthop: via t1-0/2/0.0


user@R1> show route forwarding-table destination 210.1.1.0
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
210.1.1.0/24 user 0 indr 262142 6
ucst 541 6 t1-0/2/0.0

Routing table: __master.anon__.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 519 1

user@R1>

user@R1> show route forwarding-table destination 210.1.1.0 extensive
Routing table: default.inet [Index 0]
Internet:

Destination: 210.1.1.0/24
Route type: user
Route reference: 0 Route interface-index: 0
Flags: sent to PFE, prefix load balance
Next-hop type: indirect Index: 262142 Reference: 6
Next-hop type: unicast Index: 541 Reference: 6
Next-hop interface: t1-0/2/0.0

Routing table: __master.anon__.inet [Index 3]
Internet:

Destination: default
Route type: permanent
Route reference: 0 Route interface-index: 0
Flags: sent to PFE
Next-hop type: reject Index: 519 Reference: 1

user@R1>
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