[c-nsp] IPV6 RTBH on IOS

Mon May 2 17:39:47 EDT 2016

Hi,

Cisco ist interpretting the RFC a little strange...

You need to disable the connected check on that neighnor to make it work.

Neighbor 1.2.3.4 *disable-connected-check*

As ling as it's enabled, they are preferring the link-local and the
route-map doesn't apply.

There's a feature request open for this.

BR
Sebastian

Am Montag, 2. Mai 2016 schrieb Marco Marzetti :

> Hello,
>
> I am working on RTBH for IPv6 on IOS and i am stuck with the odd behavior
> of the OS.
>
> Let's say that i have the following configuration on the router:
>
> !
> hostname R2
> ipv6 unicast-routing
> !
> interface Gi1/0
>  ipv6 address 2001::DB8::2/64
> !
> router bgp 64512
>  bgp maxas-limit 30
>  neighbor 2001:DB8::1 remote-as 64513
>  !
>  address-family ipv6
>   neighbor 2001:DB8::1 activate
>   neighbor 2001:DB8::1 send-community
>   neighbor 2001:DB8::1 prefix-list AS64513_IN in
>   neighbor 2001:DB8::1 route-map CUST_IN_V6 in
>  exit-address-family
> !
> ipv6 route 100::/64 Null0
> !
> route-map CUST_IN_V6 permit 10
>  match community BLACKHOLE
>  set community no-export additive
>  set local-preference 200
>  set ipv6 next-hop 100::1
> !
> route-map CUST_IN_V6 permit 20
> !
> ipv6 prefix-list AS64513_IN permit 2001:db8:100::/48 le 128
> !
>
>
>
> Now let's say that R1 (the peer) is sending the following prefixes to R2
> via eBGP marked with community BLACKHOLE:
>  - 2001:DB8:100::/48
>  - 2001:DB8:100::1/128
>
>
>
> The prefixes are received by R2 and next-hop is set to 100::1 as expected
> (because of the community)
> R2#show bgp ipv6 unicast
> BGP table version is 17, local router ID is 192.0.2.2
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
>               r RIB-failure, S Stale, m multipath, b backup-path, f
> RT-Filter,
>               x best-external, a additional-path, c RIB-compressed,
> Origin codes: i - IGP, e - EGP, ? - incomplete
> RPKI validation codes: V valid, I invalid, N Not found
>
>      Network          Next Hop            Metric LocPrf Weight Path
>  *>  2001:DB8:100::/48
>                        100::1                 100    200      0 64513 i
>  *>  2001:DB8:100::1/128
>                        100::1                 100    200      0 64513 ?
>
>
> But, even if 100::1 is routed to Null0, the routing table shows that the
> next-hop for the eBGP prefixes is the link-local address of R1 (the peering
> router)
> R2#show ipv6 route
> IPv6 Routing Table - default - 6 entries
> Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
>        B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
>        I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
>        EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE -
> Destination
>        NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
>        OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l -
> LISP
> S   100::/64 [1/0]
>      via Null0, directly connected
> C   2001:DB8::/64 [0/0]
>      via GigabitEthernet1/0, directly connected
> L   2001:DB8::2/128 [0/0]
>      via GigabitEthernet1/0, receive
> B   2001:DB8:100::/48 [20/100]
>      via FE80::C801:37FF:FEB0:1C, GigabitEthernet1/0
> B   2001:DB8:100::1/128 [20/100]
>      via FE80::C801:37FF:FEB0:1C, GigabitEthernet1/0
> L   FF00::/8 [0/0]
>      via Null0, receive
>
>
>
> And the same does FIB:
> R2#show ipv6 cef 2001:DB8:100::1/128
> 2001:DB8:100::1/128
>   nexthop FE80::C801:37FF:FEB0:1C GigabitEthernet1/0
> R2#
>
>
>
> So The prefix is reachable
> R2#ping 2001:DB8:100::1
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 2001:DB8:100::1, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms
> R2#
>
>
>
> The outcomes is that I cannot null-route traffic destined to a neighbor on
> the same router of the source of the attack.
>
> Now, i understand that RFC2545 permits a router to use link-local for eBGP.
> It precisely says:
> " The link-local address shall be included in the Next Hop field if and
> only if the BGP speaker shares a common subnet with the entity
> identified by the global IPv6 address carried in the Network Address
> of Next Hop field and the peer the route is being advertised to. "
>
> But this is "less than optimal" and i wonder if there's a
> trick/kludge/whatever to amend that.
> For instance IOS-XR is smart enough to stick to the specified next-hop if
> the use "set next-hop" within a route-policy.
>
> So far the only thing that have come to my mind was to set ebgp-multihop
> (in the wrong hope that would have forced IOS to consider the neighbor as
> non-connected), but it didn't work.
>
> And you can't even forward the prefixes to another router/exabgp and
> somehow receive them back because you'll end up in overwriting the
> originals.
>
> Do you have any ideas?
>
> --
> Marco
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>