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

IBGP Next-hop self enabled with Route Reflection does not appear to be working

0

0

Article ID: KB12984 KB Last Updated: 11 Aug 2010Version: 2.0
Summary:
IBGP Next-hop self enabled with Route Reflection does not appear to be working
Symptoms:
With Next-hop self enabled on the ISG2000 configured as a Route Reflector (RR), the next-hop of the routes in the RIB-in table of the receiving client (SSG5--B) do not get changed to the RR IP (2.2.2.1). Instead, it shows the IP address 1.1.1.2 of the originating client SSG5--A as the next-hop.

Lab Topology:
SSG5--A(bgroup0 1.1.1.2)----(eth4/1 1.1.1.1)ISG2000(eth4/2 2.2.2.1)-----(bgroup0 2.2.2.2)SSG5--B
ISG2000 is the Route Reflector (RR), and the SSG5s are the clients running IBGP.


ISG2000 Config (RR):
nsisg2000(trust-vr/bgp)-> get config
set protocol bgp 1000
set enable
set always-compare-med
unset synchronization
set neighbor 1.1.1.2 remote-as 1000 local-ip 1.1.1.1/24 outgoing-interface ethernet4/1
set neighbor 1.1.1.2 enable
set neighbor 1.1.1.2 nhself-enable
set neighbor 1.1.1.2 reflector-client
set neighbor 2.2.2.2 remote-as 1000 local-ip 2.2.2.1/24 outgoing-interface ethernet4/2
set neighbor 2.2.2.2 enable
set neighbor 2.2.2.2 nhself-enable
set neighbor 2.2.2.2 reflector-client
set reflector
set reflector cluster-id 10
exit
set interface ethernet4/1 protocol bgp
set interface ethernet4/2 protocol bgp


nsisg2000(trust-vr/bgp)-> get neigh
Peer AS Remote IP Local IP Wt Status State ConnID Up/Down
--------------------------------------------------------------------------------
1000 1.1.1.2 1.1.1.1 100 Enabled ESTABLISH 75 00:02:44
1000 2.2.2.2 2.2.2.1 100 Enabled ESTABLISH 74 00:02:44

total 2 BGP peers shown

Config on SSG5--A:
SSG5--A(trust-vr/bgp)-> get config
set protocol bgp 1000
set enable
set reflector cluster-id 10
set neighbor 1.1.1.1 remote-as 1000 local-ip 1.1.1.2/24 outgoing-interface bgroup0
set neighbor 1.1.1.1 enable
set neighbor 2.2.2.2 remote-as 1000
set neighbor 2.2.2.2 enable
unset ipv4 synchronization
set ipv4 neighbor 1.1.1.1 activate
set ipv4 neighbor 2.2.2.2 activate
set ipv4 network 15.15.15.0/24 no-check
set ipv4 network 16.16.16.0/24 no-check
exit
set interface bgroup0 protocol bgp

Config on SSG5--B:
SSG5--B(trust-vr/bgp)-> get config
set protocol bgp 1000
set enable
set reflector cluster-id 10
set neighbor 1.1.1.2 remote-as 1000
set neighbor 2.2.2.1 remote-as 1000 local-ip 2.2.2.2/24 outgoing-interface bgroup0
set neighbor 2.2.2.1 enable
unset ipv4 synchronization
set ipv4 neighbor 1.1.1.2 activate
set ipv4 neighbor 2.2.2.1 activate
exit
set interface bgroup0 protocol bgp
SSG5--B(trust-vr/bgp)-> get rib
i: IBGP route, e: EBGP route, >: best route, *: valid route
Prefix Nexthop Wt Pref Med Orig AS-Path
--------------------------------------------------------------------------------------
Total ipv4 routes in rib-in: 2 (0 in flap-damping history)
--------------------------------------------------------------------------------------
>i* 15.15.15.0/24 1.1.1.2 100 100 0 IGP
>i* 16.16.16.0/24 1.1.1.2 100 100 0 IGP


Solution:
This is expected behavior.  When you use Next-hop self on RRs, the cause only affects the next hop of eBGP learned routes (i.e. non-reflected routes).  A RR reflects the same gateway for IBGP routes to other IBGP peers that it learns from the orginiating IBGP peer.  The next-hop can only be modified for a reflected route via an outbound route-map.

Please refer to RFC 1966 section 8, as follows:
++++++++++++++++++++
In some implementations, modification of the BGP path attribute, NEXT_HOP is possible. For example, there could be a need for a RR to modify NEXT_HOP for EBGP learned routes sent to its internal peers. However, it must not be possible for an RR to set on reflected IBGP routes as this breaks the basic principle of Route Reflection and will result in potential black holeing of traffic.
++++++++++++++++++++
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