On Sat, Mar 25, 2017 at 02:30:48PM +0100, Pier Carlo Chiodi wrote:
>
> >Synopsis: can't rewrite NEXT_HOP for IPv6 routes
> >Category: user
> >Environment:
> System : OpenBSD 6.0
> Details : OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20 MDT 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
>
> Sorry for duplicate post, I've already tried with the misc mailing
> list but with no luck. Here I include more details about the env and
> hints on how to reproduce the issue I'm facing.
>
> I'm facing an odd behaviour with IPv6 NEXT_HOP rewriting.
>
> Scenario: IXP route server.
> I'm trying to rewrite the NEXT_HOP attribute of an IPv6 route to implement
> traffic diversion for blackhole filtering.
>
> The route server receives a blackhole filtering request from a client, a
> route for a /128 prefix with the BLACKHOLE community attached to it.
> I want the route server to announce this route to other clients with a
> fixed NEXT_HOP of 2001:db8:1:1::66; this address should be the IPv6 address
> configured with a layer-2 ACL to discard traffic entering from members
> ports. It is on the same net of clients.
>
> This is what I do (2001:db8:1:1::11 is a generic client address):
>
>
> match to 2001:db8:1:1::11 community BLACKHOLE set community NO_EXPORT
> match to 2001:db8:1:1::11 community BLACKHOLE set nexthop 2001:db8:1:1::66
>
>
> OpenBGPD seems to like it...
>
>
> bgpctl -n show rib detail out neighbor 2001:db8:1:1::11 2a02:0:3::1/128
>
> BGP routing table entry for 2a02:0:3::1/128
> 2
> Nexthop 2001:db8:1:1::66 (via 2001:db8:1:1::66) from
> 2001:db8:1:1::21 (192.0.2.21)
> Origin IGP, metric 0, localpref 100, weight 0, external, valid, best
> Last update: 00:00:27 ago
> Communities: NO_EXPORT BLACKHOLE
>
> (the "Nexthop" is reported with the expected blackhole address)
>
>
> ... but then a tcpdump on the other peer shows this:
>
>
> Multi-Protocol Reach NLRI (14), length: 55, Flags [O]:
> AFI: IPv6 (2), SAFI: Unicast (1)
> nexthop: 2001:db8:1:1::2, nh-length: 16, no SNPA
> 2a02:0:3::2/128
> 2a02:0:3::1/128
>
Thanks for the detailed bug report. I could reporduce the issue and here
is a fix for this. Seems there was some copy paste error that nobody hit
until now... While there I made the IPv4 and IPv6 case a bit more similar
and removed and assignment in if statement which confused me.
Please test.
--
:wq Claudio
Index: kroute.c
===================================================================
RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
retrieving revision 1.211
diff -u -p -r1.211 kroute.c
--- kroute.c 24 Jan 2017 04:22:42 -0000 1.211
+++ kroute.c 27 Mar 2017 22:17:30 -0000
@@ -2200,9 +2200,10 @@ knexthop_send_update(struct knexthop_nod
kr = kn->kroute;
n.valid = kroute_validate(&kr->r);
n.connected = kr->r.flags & F_CONNECTED;
- if ((n.gateway.v4.s_addr =
- kr->r.nexthop.s_addr) != 0)
+ if (kr->r.nexthop.s_addr != 0) {
n.gateway.aid = AID_INET;
+ n.gateway.v4.s_addr = kr->r.nexthop.s_addr;
+ }
if (n.connected) {
n.net.aid = AID_INET;
n.net.v4.s_addr = kr->r.prefix.s_addr;
@@ -2221,7 +2222,7 @@ knexthop_send_update(struct knexthop_nod
}
if (n.connected) {
n.net.aid = AID_INET6;
- memcpy(&n.net.v6, &kr6->r.nexthop,
+ memcpy(&n.net.v6, &kr6->r.prefix,
sizeof(struct in6_addr));
n.netlen = kr6->r.prefixlen;
}
