Pipe collision detected when sending to table
Dear List and Bird-Pros, Today we changed our RS config to an additional "Collector" table. We see this "<ERR>" in our logs: 2010-09-22 11:02:02 <ERR> Pipe collision detected when sending W.X.Y.Z/24 to table Collector This is seen for a couple of prefixes. Any hint what we might have messed up? Rgds, Stefan -- Stefan Jakob e-mail: stefan.jakob@de-cix.net DE-CIX Management GmbH Phone: +49 69 1730 902-32 Lindleystr. 12, 60314 Frankfurt Mobile: +49 172 695 8467 Geschaeftsfuehrer Harald A. Summa Fax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net
Hi, current v4 configuration can be found at http://download.de-cix.net/bird_collector.conf.gz Problem occurs in v4 and v6 daemon and seems to be load sensitive. Regards Bernhard Am 22.09.2010 13:06, schrieb Stefan Jakob:
Dear List and Bird-Pros,
Today we changed our RS config to an additional "Collector" table. We see this "<ERR>" in our logs:
2010-09-22 11:02:02 <ERR> Pipe collision detected when sending W.X.Y.Z/24 to table Collector
This is seen for a couple of prefixes.
Any hint what we might have messed up?
Rgds, Stefan
-- Bernhard Hahn DE-CIX Management GmbH e-mail: bernhard.hahn@de-cix.net Lindleystr. 12, 60314 Frankfurt Phone: +49 69 1730 902-34 Geschaeftsfuehrer Harald A. Summa Mobile: +49 171 552 3643 Registergericht AG Koeln, HRB 51135 Fax: +49 69 4056 2716
On Wed, Sep 22, 2010 at 01:06:53PM +0200, Stefan Jakob wrote:
Dear List and Bird-Pros,
Today we changed our RS config to an additional "Collector" table. We see this "<ERR>" in our logs:
2010-09-22 11:02:02 <ERR> Pipe collision detected when sending W.X.Y.Z/24 to table Collector
This is seen for a couple of prefixes.
Any hint what we might have messed up?
This problem may happen if one route (from one protocol) arrives to one routing table via two (or more) different pipes. The original idea is that the graph of routes and pipes is a tree, but it should work even if it is a tree for each route after applying filters. I checked the config file and it seems that there are several ways for one route to get to the collector table: BGP1 - TABLE1 - COLLECTOR BGP1 - TABLE1 - MASTER - TABLE2 - COLLECTOR BGP1 - TABLE1 - MASTER - TABLE3 - COLLECTOR ... The proper way to fix this is to add a filter on a pipe from a peer table to the collector table to propagate only the routes from an attached BGP protocol (and not the routes received transitively from the master table). BTW, why are you adding the collector table? It seems to me that you have same filters to the master table and to the collector table so they would have the same content. -- 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."
On 25.09.2010 18:49 Ondrej Zajicek wrote
BTW, why are you adding the collector table?
to have on one hand a master table where all the "routeable" prefixes go and otoh a table where all valid prefixes are.
It seems to me that you have same filters to the master table and to the collector table so they would have the same content.
I don't think so. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
On Sun, Sep 26, 2010 at 04:48:48PM +0200, Arnold Nipper wrote:
It seems to me that you have same filters to the master table and to the collector table so they would have the same content.
I don't think so.
I checked just first several pipes like M42_pch / C42_pch and M553_belwue / C553_belwue and they have the same import filter (in_pch, in_belwue). -- 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."
On 26.09.2010 17:59 Ondrej Zajicek wrote
On Sun, Sep 26, 2010 at 04:48:48PM +0200, Arnold Nipper wrote:
It seems to me that you have same filters to the master table and to the collector table so they would have the same content.
I don't think so.
I checked just first several pipes like M42_pch / C42_pch and M553_belwue / C553_belwue and they have the same import filter (in_pch, in_belwue).
Right ... but there are a couple of prefixes which don't go to the master table at all. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
Hi Ondrej, thanks for the explanation. Am 25.09.2010 18:49, schrieb Ondrej Zajicek:
The proper way to fix this is to add a filter on a pipe from a peer table to the collector table to propagate only the routes from an attached BGP protocol (and not the routes received transitively from the master table). Does that mean something like a "where from=neighbor_IP" statement or is there a built-in statement or flag to refer to attached protocols?
Is there any harm to be expected running the current configuration, except huge log output? Regards Bernhard -- Bernhard Hahn DE-CIX Management GmbH e-mail: bernhard.hahn@de-cix.net Lindleystr. 12, 60314 Frankfurt Phone: +49 69 1730 902-34 Geschaeftsfuehrer Harald A. Summa Mobile: +49 171 552 3643 Registergericht AG Koeln, HRB 51135 Fax: +49 69 4056 2716
On Sun, Sep 26, 2010 at 11:53:47PM +0200, Bernhard Hahn wrote:
Hi Ondrej,
thanks for the explanation.
Am 25.09.2010 18:49, schrieb Ondrej Zajicek:
The proper way to fix this is to add a filter on a pipe from a peer table to the collector table to propagate only the routes from an attached BGP protocol (and not the routes received transitively from the master table). Does that mean something like a "where from=neighbor_IP" statement or is there a built-in statement or flag to refer to attached protocols?
Yes, testing 'from' is probably the best way to do.
Is there any harm to be expected running the current configuration, except huge log output?
I think this should not cause any problems, esp. if you do not export anything from the collector table. Perhaps some inconsistent counters. -- 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."
Dear Ondrej, Am 25.09.10 18:49, schrieb Ondrej Zajicek:
On Wed, Sep 22, 2010 at 01:06:53PM +0200, Stefan Jakob wrote: ne route to get to the collector table:
BGP1 - TABLE1 - COLLECTOR BGP1 - TABLE1 - MASTER - TABLE2 - COLLECTOR BGP1 - TABLE1 - MASTER - TABLE3 - COLLECTOR ...
The proper way to fix this is to add a filter on a pipe from a peer table to the collector table to propagate only the routes from an attached BGP protocol (and not the routes received transitively from the master table).
I am wondering how such a filter would look like?: bird> show route table Collector where ! ( source = RTS_BGP) count 0 of 2561 routes for 1432 networks Guess source RTS_BGP isn't the answer, since imho all routes are originated from BGP? One solution might be to add an additional table to the protocol definition and use this table in the pipe going to the Collector table. Rgds, Stefan -- Stefan Jakob e-mail: stefan.jakob@de-cix.net DE-CIX Management GmbH Phone: +49 69 1730 902-32 Lindleystr. 12, 60314 Frankfurt Mobile: +49 172 695 8467 Geschaeftsfuehrer Harald A. Summa Fax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net
participants (4)
-
Arnold Nipper -
Bernhard Hahn -
Ondrej Zajicek -
Stefan Jakob