Hello LARTC, I'm testing Failover and i'm getting this problem: In the moment the device gets deleted (dissapears from /proc/net/dev) e.g. pppd crashes all RULES regarding this device are flushed. Is this a known bug/problem (i think so :) is there a workaround/solution (except adding the rules again in ip-up.d) ? Thanks in advance Tobias
addition: to be precisly: the problem is i have several nexthops (e.g. ppp0 +eth1 +eth2) for the same route and this WHOLE Route is deleted, although only the ppp0-device dissapears... and i cannot add several entries in different tables, cause this seems not to do failover > Hello LARTC, > > I'm testing Failover and i'm getting this problem: > > In the moment the device gets deleted (dissapears from /proc/net/dev) > e.g. pppd crashes all RULES regarding this device are flushed. > Is this a known bug/problem (i think so :) > is there a workaround/solution (except adding the rules again in > ip-up.d) ? > > Thanks in advance > > Tobias > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello, On Tue, 23 Jul 2002, Tobias Geiger wrote: > to be precisly: the problem is i have several nexthops (e.g. ppp0 +eth1 > +eth2) for the same route and this WHOLE Route is deleted, although only > the ppp0-device dissapears... > and i cannot add several entries in different tables, cause this seems not > to do failover Yes, similar behavior appeared in latest 2.4.19pre kernels, it looks like a recommendation the users to recreate their routes because a device in nexthop was unregistsred. Is this true for your setup? Regards -- Julian Anastasov <ja@ssi.bg>
I've noticed some strange behaivour in tc and can't seem to find a definate "this is a bug" or "this is not a bug". Figured I'd ask the list. I'm using HTB2 and HTB3, on different machines. This happened on both of them. I've created a few different classes and quite a few filters. All of my filters were previously u32 filters. (wont bother posting the exact script, its fairly long, works on 3 separate interfaces, etc) I started to mark FTP packets using iptables (trying for both active and passive ftp), which seems to work fine. When I added a FW filter: /sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 handle 5 fw classid 1:24 I got the infamous: RTNETLINK answers: Invalid argument After a few hours of experimentation, I realized that if I changed the filters PRIO to something not used by one of the u32 filters, all went well. i.e.: /sbin/tc filter add dev eth1 protocol ip parent 1: prio 5 handle 5 fw classid 1:24 Has anyone seen this before? Anyone know if it is definately a bug or not? Or is it something very strange specific to my setup? -- Rob Rankin mahhy@undertow.ca http://undertow.ca
> > Hello, > > On Tue, 23 Jul 2002, Tobias Geiger wrote: > >> to be precisly: the problem is i have several nexthops (e.g. ppp0 >> +eth1 +eth2) for the same route and this WHOLE Route is deleted, >> although only the ppp0-device dissapears... >> and i cannot add several entries in different tables, cause this seems >> not to do failover > > Yes, similar behavior appeared in latest 2.4.19pre kernels, > it looks like a recommendation the users to recreate their routes > because a device in nexthop was unregistsred. Is this true for > your setup? > Yes. i used 2.4.19pre-10 kernel. This behaviour affects only ppp-devices (never tried ippp but i guess it's the same) i also wondered, why failover doesn't work when using different route-entries for each nexthop... another confusing thing: using "nexthop via dev ppp0" in a table made me think that i don't need a gateway address at all... but unfortunatly that's no the case :(seems that ip searches the gateway address itself so that after appp-reconnect (where i get another gateway address) the table-entries aren't valid anymore. Thanks Tobias
Hello, On Wed, 24 Jul 2002, Tobias Geiger wrote: > Yes. i used 2.4.19pre-10 kernel. > This behaviour affects only ppp-devices (never tried ippp but i guess it's > the same) > > i also wondered, why failover doesn't work when using different > route-entries for each nexthop... Hm, the kernel can not perform failover for NOARP devices that are always in UP state. It is possible only for ARP devices and for default routes with same metric. But if the first route is automatically deleted from kernel the 2nd one will be used. No? > another confusing thing: using "nexthop via dev ppp0" in a table made me > think that i don't need a gateway address at all... but unfortunatly > that's no the case :(seems that ip searches the gateway address itself so > that after appp-reconnect (where i get another gateway address) the table-entries > aren't valid anymore. The "via GW" syntax is not mandatory for ppp devices, you can use only "nexthop dev ppp0", just remove this "via", you have syntax error. As for ppp devices, it is recommended your scripts to recreate the multipath routes to contain nexthops only for valid ppp devices (for which you have established link). As you see, the new kernels delete the multipath route for you, so you can't rely on permanent multipath route (I assume the ppp devices really pass unregistration). Even in the old kernels you have to recreate the route because when one ppp devices is registered again its nexthop status does not change, it remains dead. > Thanks > > Tobias Regards -- Julian Anastasov <ja@ssi.bg>