On 07/03/17(Tue) 19:38, Joe Holden wrote:
> On 12/12/2016 16:55, Joe Holden wrote:
> > On 12/12/2016 10:27, Martin Pieuchot wrote:
> > > On 11/12/16(Sun) 00:50, Joe Holden wrote:
> > > > On 10/12/2016 08:43, Mihai Popescu wrote:
> > > > > > > seeing some bizarre behaviour on one box, on one specific
> > > > > > > interface:
> > > > >
> > > > > Hello,
> > > > >
> > > > > This looks like some stupid TV game, where contesters are given some
> > > > > clues from time to time and they have to guess what is the real shit.
> > > > >
> > > > > Do post your FULL dmesg and configurations for network if you really
> > > > > want someone to even think at your issue. Isn't that obvious?
> > > > >
> > > > > Bye!
> > > > >
> > > >
> > > > Appreciate the useless response (but still better than nothing!), the
> > > > affected box has since been reverted to older snapshot and thus no more
> > > > debugging can be done - someone else will have to do it.
> > >
> > > I'd appreciate to see the output of 'netstat -rnf inet' when it is
> > > relevant. Without that information it's hard to understand.
> > >
> > > But there's a bug somewhere, it has to be fixed.
> > >
> > > > Not that dmesg is even relevant since it is a userland bug not a kernel
> > > > problem but anyway:
> > >
> > > It's a kernel problem.
> > >
> > I'll see if I can recreate it but I'm not holding my breath - it only
> > breaks once BGP loaded the table which leads me to thing it is actually
> > bgpd that is updating the llinfo with bogus info and even though I have
> > a feed in my lab it doesn't do the same thing.
> >
> Ok so, inadvertantly recreated this (pretty much exactly the same) issue on
> a lab/test setup:
>
> For the purposes of debug, ignore the fact that the interfaces are tap
> interfaces, they're still emulated ethernet...
>
> Wall of text incoming, various info...
>
> box#1:
>
> tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr fe:e1:ba:d1:be:f3
> index 7 priority 0 llprio 3
> groups: tap
> status: active
> inet 172.20.230.72 netmask 0xfffffffe
>
> box#2:
>
> tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr fe:e1:ba:d1:cf:92
> index 7 priority 0 llprio 3
> groups: tap
> status: active
> inet 172.20.230.73 netmask 0xfffffffe
>
> All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows
> the following:
>
> Host Ethernet Address Netif Expire Flags
> 172.20.230.72 00:00:00:00:20:12 ? 12m30s
>
> # route -n get 172.20.230.72
> route to: 172.20.230.72
> destination: 172.20.230.72
> mask: 255.255.255.255
> interface: tap1
> if address: 172.20.230.73
> priority: 3 ()
> flags: <UP,HOST,DONE,LLINFO,CLONED,CACHED>
> use mtu expire
> 20 0 702
>
> flags destination gateway lpref med aspath origin
> IS*> 172.20.230.72/31 172.20.230.64 200 0 i
>
> .64 is the loopback on one of its connected boxes that doesn't have broken
> entries
>
> tcpdump looks ok, afterwards:
>
> 19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73
> 19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
> 19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73
> 19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
>
> but the correct entry is never installed, after I delete the broken arp
> entry it never readds a new one.
>
> This only happens with redist connected as far as I can tell, but bgpd
> probably shouldn't be able to mangle arp entries and prevent the correct one
> being added.
Here's the fix.
Index: net/rtsock.c
===================================================================
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.232
diff -u -p -r1.232 rtsock.c
--- net/rtsock.c 7 Mar 2017 09:23:27 -0000 1.232
+++ net/rtsock.c 8 Mar 2017 16:06:22 -0000
@@ -895,10 +895,22 @@ rtm_output(struct rt_msghdr *rtm, struct
}
}
change:
- if (info->rti_info[RTAX_GATEWAY] != NULL && (error =
- rt_setgate(rt, info->rti_info[RTAX_GATEWAY],
- tableid)))
- break;
+ if (info->rti_info[RTAX_GATEWAY] != NULL) {
+ /*
+ * When updating the gateway, make sure it's
+ * valid.
+ */
+ if (!newgate && rt->rt_gateway->sa_family !=
+ info->rti_info[RTAX_GATEWAY]->sa_family) {
+ error = EINVAL;
+ break;
+ }
+
+ error = rt_setgate(rt,
+ info->rti_info[RTAX_GATEWAY], tableid);
+ if (error)
+ break;
+ }
#ifdef MPLS
if ((rtm->rtm_flags & RTF_MPLS) &&
info->rti_info[RTAX_SRC] != NULL) {
