Re: next-hop-check bgp

If you don't want BGP to use a default route or another BGP route for the
next-hop validation then the configuration below is what you are looking for:

router bgp 65111
 bgp nexthop route-map RM_NH_FILTER
!
ip prefix-list PL_NH_FILTER seq 5 permit 0.0.0.0/0
!
route-map RM_NH_FILTER deny 10
match ip address prefix-list PL_NH_FILTER
!
route-map RM_NH_FILTER deny 20
match source-protocol bgp 65111
!
route-map RM_NH_FILTER permit 30

Here is an example where a default route to null is causing a next-hop to be
validated and actually causes the route to be blackholed.

R14#show bgp ipv4 unicast 192.168.179.0/26
BGP routing table entry for 192.168.179.0/26, version 14
Paths: (1 available, no best path)
  Not advertised to any peer
  65179, (aggregated by 65179 192.168.179.42)
    10.1.15.1 (inaccessible) from 172.16.100.15 (172.16.100.15)
      Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate

> Here the next-hop is inaccessible and in turn the route isn't installed or
advertised onto other BGP peers

R14#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R14(config)#ip route 0.0.0.0 0.0.0.0 null0
R14(config)#^Z

> Now a default route to null is added

R14#show bgp ipv4 unicast 192.168.179.0/26
BGP routing table entry for 192.168.179.0/26, version 15
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
        2
  65179, (aggregated by 65179 192.168.179.42)
    10.1.15.1 from 172.16.100.15 (172.16.100.15)
      Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate,
best

> Now the next-hop is "accessible" since its validated against the default

R14#show ip cef 10.1.15.1
0.0.0.0/0, version 30, epoch 0, attached
0 packets, 0 bytes
  via Null0, 1 dependency
    valid null adjacency

> Now I'll filter the default and any BGP route from being used to validate a
next-hop

R14#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R14(config)#router bgp 65111
R14(config-router)# bgp nexthop route-map RM_NH_FILTER
R14(config-router)#
R14(config-router)#ip prefix-list PL_NH_FILTER seq 5 permit 0.0.0.0/0
R14(config)#
R14(config)#route-map RM_NH_FILTER deny 10
R14(config-route-map)#match ip address prefix-list PL_NH_FILTER
R14(config-route-map)#
R14(config-route-map)#route-map RM_NH_FILTER deny 20
R14(config-route-map)#match source-protocol bgp 65111
R14(config-route-map)#
R14(config-route-map)#route-map RM_NH_FILTER permit 30
R14(config-route-map)#
R14(config-route-map)#^Z
R14#show bgp ipv4 unicast 192.168.179.0/26
BGP routing table entry for 192.168.179.0/26, version 16
Paths: (1 available, no best path)
Flag: 0x820
  Not advertised to any peer
  65179, (aggregated by 65179 192.168.179.42)
    10.1.15.1 (inaccessible) from 172.16.100.15 (172.16.100.15)
      Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate
R14#

This is the desired result (inaccessible) because when the next hop was
accessible via the default to null, the BGP route was advertised onto other
BGP peers when the route really isn't reachable. This configuration will also
not allow the router to validate the next-hop against another BGP route.

--
Brian Dennis, CCIEx5 #2210 (R&S/ISP-Dial/Security/SP/Voice)
bdennis_at_ine.com
INE, Inc.
http://www.INE.com
On 3/30/13 8:30 PM, "Tony Singh"
<mothafungla_at_gmail.com<mailto:mothafungla_at_gmail.com>> wrote:
Hi all
I've worked out the problem in this particular scenario but need help
understanding it..
Topology
R1 ---- R2 ----- R4 ---- R5
---------iBGP------eBGP----
R1 also connects to another iBGP peer = R3 via another interface which
injects a default-route via redistribute-static into BGP
Ok so R1-R2 are RR clients of each other, for which R5 originates an
eBGP route to R4, now R4 to R2 iBGP there is no next-hop-self so the
updates that R2 receives from R4 is the /30 of R5 i.e next hop
unchanged (to fix it simply I have to add next-hop-self on R4's
peering to R2)
But what I don't understand without this command is that R1 receives
the update from R2 with the original next-hop in-tact i.e R5's
interface BUT R1 installs the route into the routing table!!?
On the premise that it has a default route 0.0.0.0 via R1's interface to R3
The original prefix received from the RR R2 & the next-hop /30 of R5
is not reachable via R1's interface to R3 nor via it's interface to R2
but R1 none-the-less creates a CEF entry in it's routing table of the
prefixes (/30 of R5 & original prefix) to point to R3's interface who
originated a default route....
My question is therefore the BGP next hop reachable check, what does
it do behind the scenes at this has got me thinking and confused...
Sorry for the long mail
BR
Tony
Blogs and organic groups at http://www.ccie.net