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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
