Re: next-hop-check bgp

Thanks Brian, I see this is a common one amongst your students then

what your basically saying on the route-map sequences match and deny a
default route from bgp as xxx & permit everything else

thanks for the detailed reply

:)

On 31 March 2013 05:33, Brian Dennis <bdennis_at_ine.com> wrote:
> 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> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Mar 31 2013 - 05:57:48 ART