"gw" attribute assignment in filter invalidates routes learned via BGP, static, and possibly others?

[Ondrej Zajicek]

On Tue, Aug 13, 2013 at 05:31:33PM +0300, Sergey Popovich wrote:
> ?? ???????????? ???? 13 ?????????????? 2013 16:25:14 ???? ????????????????:
>  
> > The patch does not make sense to me - if user sets 'gw' attribute, BIRD
> > should set immediate nexthop of the route, not setup a route with a
> > recursive nexthop - that would be inconsistent, because reading of 'gw'
> > attribute returns the immediate nexhop and not the recursive nexthop of
> > a route.
> 
> Thaks, now I understand why. At least I try to fix problem by myself.

That always counts.

> > The attached patch should do that (essentially just lookup iface,
> > fix it and force the route to RTD_ROUTER in case of setting 'gw').
> > Is this OK for you?
> > 
> 
> Yes, thaks. Patch works as expected.

Well, you should also use this patch, otherwise your BGP sessions
will be restarted if you shutdown the dummy iface. This bug could
also be triggered by other means but i noticed it in connection with
the gw-setting patch.

> > Thanks for the thorough explanation. I am surprised that route to a Linux
> > dummy interface works like that, i always thought that dummy interface
> > would behave more like an ethernet with nothing connected on it than
> > like a loopback (therefore you would get ICMP Destination unreachable
> > instead of TTL exceeded), but i didn't tested that.
> > 
> 
> Sorry I dont have in mind to confuse you, really dummy interface is more
> like ethernet interface with nothing attached to it, nothing is looped back 
> from it (nothing received actually). Anything sent to dummy interface simply 
> discarded as with blackhole route, but no neighbor resolution (ARP, NDP) done 
> on it, and general routing rules applied to it, like any other network 
> interface, that makes it different from blackhole route.
> 
> But network stack generates ICMP TTL Exceeded when it receives datagram
> destined on subnet configured on dummy interface, but cant forward to dummy 
> interface because TTL is 1, and thus generaing ICMP TTL Exceeded.

OK, now i understand. The TTL ICMP message is related just to traceroute
packets, not to the normal traffic (which has large enough TTL).

So in essence route to dummy iface first checks TTL and then blackholes
traffic, while RTD_BLACKHOLE just blackholes traffic.

> Using dummy interfce for blackholing seems simple and elegant solution:-).

Well, i wouldn't call this elegant. RTD_BLACKHOLE seems expected to be
used in such cases, so if it is insufficient for that purpose it is most
likely a bug in kernel and using dummy iface is merely a workaround.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_neigh_notify.patch
Type: text/x-diff
Size: 387 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130813/7680801d/attachment-0001.patch>