You're right it isn't a commonly known feature. I've only had one student
who knew about the feature before I covered it.
-- 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 9:57 PM, "Tony Singh" <mothafungla_at_gmail.com> wrote: >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.netReceived on Sun Mar 31 2013 - 13:15:28 ART
This archive was generated by hypermail 2.2.0 : Wed Apr 03 2013 - 19:06:19 ART