On Tue, Dec 01, 2009 at 10:48:56AM +0100, Wolfgang Hennerbichler wrote:
Every route passes through at most one pipe according to your expected filter behavior?
well, a route can be distributed from one table to let's say 10 other tables by 10 pipes. you remember we do things a little different. but the pipes are set like above. so there can't be a triangle or something that sends routes from table A, to table B, to table C and back to A. That shouldn't be possible.
My question is whether it should be possible taht route was sent from table A through table B to table C (where A != C). According to what you wrote about pipe filters it shouldn't be possible, unless you have someting like two tables associated with one IP address.
Do the pipes ignore the filters at any time?
I think filters are not ignored.
ok. I think it's the loop prevention thing that's in place before the filter which causes this, this is very certain. I also checked quite some routes where bird thinks they're looping, and all of them are where they should be. Are there chances you'll fix the loop checking code so that it at least checks always after filtering?
Your problem is probably related to the problem mentioned by me (loop check before filter) but according to my understanding of the code, it shouldn't happen in your case. It might happen only when route was successfully sent from A through B to C (or through a longer chain). Could you enable logging of routes ('debug protocols { routes }') and send me at least appropriate part (messages related to route triggered loop check) of a log?
PS: We've got BIRD running at VIX in Beta now, about 12 participants, no crashes, no problems at all (except for the loop notices)
BTW, we have implemented route refresh, it will be in the next release. But route refresh solves just changes in import filters. Do you also need similar kind of 'soft reconfiguration' for export filters? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."