Hello all, I make some testbed and testing some scenarios and i found weird "show route" behaviour. I have 2 bgp peers without filter. First router, called testr1, has 3 tables: master, t_nix and t_tranzit. Second router called "nix1_nix" has quite default settings. Conf file from testr1 is attached. To every single table on testr1 is imported 1 different static route via protocol static. Tables t_nix and t_tranzit are "piped" to master table, opposite direction is filtered. BGP peer nix1_nix is defined with "table t_nix". This is "show protocols" on tesr1: device1 Device master up 00:29 kernel1 Kernel master up 00:29 k_nix Kernel t_nix up 00:29 k_tranzit Kernel t_tranzit up 00:29 p_nix Pipe t_nix up 00:29 => master p_tranzit Pipe t_tranzit up 00:29 => master s_master Static master up 00:29 s_nix Static t_nix up 00:29 s_tranzit Static t_tranzit up 00:29 nix1_nix BGP t_nix up 00:29 Established There is route tables print. Table t_nix has imported default route from nix1_nix and table master has the same default route imported through pipe from t_nix (this is correct, just explanation): bird> show route table master 0.0.0.0/0 via 192.168.1.3 on eth1 [nix1_nix 00:29] ! (100) [AS65000i] 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) bird> show route table t_nix 0.0.0.0/0 via 192.168.1.3 on eth1 [nix1_nix 00:29] * (100) [AS65000i] 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) bird> show route table t_tranzit 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) Weird show behaviour comes now: bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) It show all routes from all tables, although table t_nix is defined on this peer. But, nix1_nix receive only one route, correct route from t_nix table: bird> show protocols name proto table state since info device1 Device master up 00:28 kernel1 Kernel master up 00:28 r1 BGP master up 00:29 Established bird> show route protocol r1 5.5.5.0/24 via 192.168.1.1 on eth1 [r1 00:29] * (100) [AS64000i] I tryid simplify scenario and delete pipes to master table temporarily and situation looks this way: testr1: bird> show protocols name proto table state since info device1 Device master up 00:31 kernel1 Kernel master up 00:31 k_nix Kernel t_nix up 00:31 k_tranzit Kernel t_tranzit up 00:31 s_master Static master up 00:31 s_nix Static t_nix up 00:31 s_tranzit Static t_tranzit up 00:31 nix1_nix BGP t_nix up 00:31 Established bird> bird> show route table master 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:31] * (200) bird> show route table t_nix 0.0.0.0/0 via 192.168.1.3 on eth1 [nix1_nix 00:31] * (100) [AS65000i] 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:31] * (200) bird> show route table t_tranzit 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:31] * (200) and now, command show route from master table only bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:31] * (200) although peer receive correct route: bird> show route protocol r1 5.5.5.0/24 via 192.168.1.1 on eth1 [r1 00:31] * (100) [AS64000i] It looks like "show" command bug only, which is good, but it is pretty confusing :) Both peers is: Linux testr1 3.4.4-5.fc17.x86_64 #1 SMP Thu Jul 5 20:20:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux running latest: bird> show status BIRD 1.3.9 Regards, Dan
Hi, On 02/24/2013 01:08 AM, Dan Rimal wrote:
Weird show behaviour comes now:
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
It show all routes from all tables, although table t_nix is defined on this peer. But, nix1_nix receive only one route, correct route from t_nix table:
[...]
It looks like "show" command bug only, which is good, but it is pretty confusing :)
I have a very similar setup, and noticed the same thing a few days ago (also bird 1.3.9), while sharing output of show commands with someone else to explain the use of multiple tables (which resulted in a funny situation "huh? heh?"). show route export shows routes that aren't actually there. It looks like a bug in the show command indeed. Thanks for the report, it was also on my todo list. :-) -- Hans van Kranenburg - System / Network Engineer T +31 (0)10 2760434 | hans.van.kranenburg@mendix.com | www.mendix.com
On 24.2.2013 01:08, Dan Rimal wrote:
Hello all,
Hi Dan!
I make some testbed and testing some scenarios and i found weird "show route" behaviour.
[ ... ]
Weird show behaviour comes now:
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I believe 'show route export nix1_nix table t_nix' does the right thing. Can you test it please? I think I understand the issue, I will look at it. Ondrej
Regards,
Dan
On 02/24/2013 05:12 PM, Ondrej Filip wrote:
On 24.2.2013 01:08, Dan Rimal wrote:
Weird show behaviour comes now:
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I believe 'show route export nix1_nix table t_nix' does the right thing. Can you test it please?
In my case similar case, the equivalent command of this does show the right output indeed.
I think I understand the issue, I will look at it.
Adding 'table master' instead of the table name that was chosen in the protocol declaration shows the same as the default output when not adding the table name. -- Hans van Kranenburg - System / Network Engineer T +31 (0)10 2760434 | hans.van.kranenburg@mendix.com | www.mendix.com
On 24.2.2013 17:28, Hans van Kranenburg wrote:
On 02/24/2013 05:12 PM, Ondrej Filip wrote:
On 24.2.2013 01:08, Dan Rimal wrote:
Hans and Dan,
Weird show behaviour comes now:
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I believe 'show route export nix1_nix table t_nix' does the right thing. Can you test it please?
In my case similar case, the equivalent command of this does show the right output indeed.
I think I understand the issue, I will look at it.
Adding 'table master' instead of the table name that was chosen in the protocol declaration shows the same as the default output when not adding the table name.
yes, because 'table master' is default. I produced a simple patch (attached) against the current git repository, but it should work against 1.3.9. However I am not 100% sure whether to submit this into the main branch or rather just document that 'table master' is default. I will discuss it with my teammates. And of course, your comments are welcome. Ondrej
On 02/24/2013 06:52 PM, Ondrej Filip wrote:
On 24.2.2013 17:28, Hans van Kranenburg wrote:
On 02/24/2013 05:12 PM, Ondrej Filip wrote:
On 24.2.2013 01:08, Dan Rimal wrote:
Weird show behaviour comes now:
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I believe 'show route export nix1_nix table t_nix' does the right thing. Can you test it please?
In my case similar case, the equivalent command of this does show the right output indeed.
I think I understand the issue, I will look at it.
Adding 'table master' instead of the table name that was chosen in the protocol declaration shows the same as the default output when not adding the table name.
yes, because 'table master' is default. I produced a simple patch (attached) against the current git repository, but it should work against 1.3.9. However I am not 100% sure whether to submit this into the main branch or rather just document that 'table master' is default. I will discuss it with my teammates. And of course, your comments are welcome.
How should the output of the following command in Dans example be interpreted? bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) I guess it should be done like: "these are the routes that could possibly be exported from table master via table t_nix to nix1_nix if none of them were being filtered"? This does not make any sense to me as default output. The config Dan is showing explicitely has an import none from master to t_nix, so when being busy to debug route information at the nix1_nix proto, after filtering all those routes from t_nix to nix1_nix (possibly to isolate the test case while tracking down a problem) this looks very confusing. I'm always a fan of defaults that match how (new) people would use the software intuitively, and here's how I would intuitively think: One of the first pages you read when starting with bird is this one: http://bird.network.cz/?get_doc&f=bird-2.html "Each protocol is connected to a routing table through two filters which can accept, reject and modify the routes. An export filter checks routes passed from the routing table to the protocol, an import filter checks routes in the opposite direction." This makes me think by default that show route export <protocol> would show me information about what is actually going in in <protocol> right now by default, related to its own connected bird table. -- Hans van Kranenburg - System / Network Engineer T +31 (0)10 2760434 | hans.van.kranenburg@mendix.com | www.mendix.com
On 24.2.2013 19:35, Hans van Kranenburg wrote:
yes, because 'table master' is default. I produced a simple patch (attached) against the current git repository, but it should work against 1.3.9. However I am not 100% sure whether to submit this into the main branch or rather just document that 'table master' is default. I will discuss it with my teammates. And of course, your comments are welcome.
How should the output of the following command in Dans example be interpreted?
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I guess it should be done like: "these are the routes that could possibly be exported from table master via table t_nix to nix1_nix if none of them were being filtered"? This does not make any sense to me as default output.
No, that are routes from master table that could be exported to protocol nix1_nix filtered by import protocol. But anyway.
The config Dan is showing explicitely has an import none from master to t_nix, so when being busy to debug route information at the nix1_nix proto, after filtering all those routes from t_nix to nix1_nix (possibly to isolate the test case while tracking down a problem) this looks very confusing.
I'm always a fan of defaults that match how (new) people would use the software intuitively, and here's how I would intuitively think:
One of the first pages you read when starting with bird is this one:
http://bird.network.cz/?get_doc&f=bird-2.html
"Each protocol is connected to a routing table through two filters which can accept, reject and modify the routes. An export filter checks routes passed from the routing table to the protocol, an import filter checks routes in the opposite direction."
This makes me think by default that show route export <protocol> would show me information about what is actually going in in <protocol> right now by default, related to its own connected bird table.
OK. I understand your point. Ondrej
Hi, On 02/24/2013 07:40 PM, Ondrej Filip wrote:
On 24.2.2013 19:35, Hans van Kranenburg wrote:
How should the output of the following command in Dans example be interpreted?
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I guess it should be done like: "these are the routes that could possibly be exported from table master via table t_nix to nix1_nix if none of them were being filtered"? This does not make any sense to me as default output.
No, that are routes from master table that could be exported to protocol nix1_nix filtered by import protocol. But anyway.
Hm, I'm trying to understand this, while reading the documentation: show route [[for] prefix|IP] [table sym] [filter f|where c] [(export|preexport) p] [protocol p] [options] * Show contents of a routing table (by default of the main one) * The export and preexport switches ask for printing of entries that are exported to the specified protocol. But there are no entries from table master exported to nix1_nix. I don't mean to bother you with all my questions, I'm interested to understand how bird works, and I guess I should stop here and start reading the C code instead. >:) -- Hans van Kranenburg - System / Network Engineer T +31 (0)10 2760434 | hans.van.kranenburg@mendix.com | www.mendix.com
I agree with Hans. I think bird should use table defined within each protocol or use master if table isn't defined. But i don't know, if other part of bird will not be affected (in negative point of view) by this behaviour. I will try patch this evenging, thank you for it. Dan On 02/24/2013 07:40 PM, Ondrej Filip wrote:
On 24.2.2013 19:35, Hans van Kranenburg wrote:
yes, because 'table master' is default. I produced a simple patch (attached) against the current git repository, but it should work against 1.3.9. However I am not 100% sure whether to submit this into the main branch or rather just document that 'table master' is default. I will discuss it with my teammates. And of course, your comments are welcome. How should the output of the following command in Dans example be interpreted?
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I guess it should be done like: "these are the routes that could possibly be exported from table master via table t_nix to nix1_nix if none of them were being filtered"? This does not make any sense to me as default output. No, that are routes from master table that could be exported to protocol nix1_nix filtered by import protocol. But anyway.
The config Dan is showing explicitely has an import none from master to t_nix, so when being busy to debug route information at the nix1_nix proto, after filtering all those routes from t_nix to nix1_nix (possibly to isolate the test case while tracking down a problem) this looks very confusing.
I'm always a fan of defaults that match how (new) people would use the software intuitively, and here's how I would intuitively think:
One of the first pages you read when starting with bird is this one:
http://bird.network.cz/?get_doc&f=bird-2.html
"Each protocol is connected to a routing table through two filters which can accept, reject and modify the routes. An export filter checks routes passed from the routing table to the protocol, an import filter checks routes in the opposite direction."
This makes me think by default that show route export <protocol> would show me information about what is actually going in in <protocol> right now by default, related to its own connected bird table.
OK. I understand your point.
Ondrej
On 25.2.2013 09:01, Dan Rimal wrote: OK, guys! Please let me know if it works. And it will go to 1.3.10. Thank you. Ondrej
I agree with Hans. I think bird should use table defined within each protocol or use master if table isn't defined. But i don't know, if other part of bird will not be affected (in negative point of view) by this behaviour.
I will try patch this evenging, thank you for it.
Dan
On 02/24/2013 07:40 PM, Ondrej Filip wrote:
On 24.2.2013 19:35, Hans van Kranenburg wrote:
yes, because 'table master' is default. I produced a simple patch (attached) against the current git repository, but it should work against 1.3.9. However I am not 100% sure whether to submit this into the main branch or rather just document that 'table master' is default. I will discuss it with my teammates. And of course, your comments are welcome. How should the output of the following command in Dans example be interpreted?
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I guess it should be done like: "these are the routes that could possibly be exported from table master via table t_nix to nix1_nix if none of them were being filtered"? This does not make any sense to me as default output. No, that are routes from master table that could be exported to protocol nix1_nix filtered by import protocol. But anyway.
The config Dan is showing explicitely has an import none from master to t_nix, so when being busy to debug route information at the nix1_nix proto, after filtering all those routes from t_nix to nix1_nix (possibly to isolate the test case while tracking down a problem) this looks very confusing.
I'm always a fan of defaults that match how (new) people would use the software intuitively, and here's how I would intuitively think:
One of the first pages you read when starting with bird is this one:
http://bird.network.cz/?get_doc&f=bird-2.html
"Each protocol is connected to a routing table through two filters which can accept, reject and modify the routes. An export filter checks routes passed from the routing table to the protocol, an import filter checks routes in the opposite direction."
This makes me think by default that show route export <protocol> would show me information about what is actually going in in <protocol> right now by default, related to its own connected bird table.
OK. I understand your point.
Ondrej
Patch works great, show correct routes. Thank you Dan Dne 25.02.13 10:33, Ondrej Filip napsal(a):
On 25.2.2013 09:01, Dan Rimal wrote:
OK, guys! Please let me know if it works. And it will go to 1.3.10. Thank you.
Ondrej
I agree with Hans. I think bird should use table defined within each protocol or use master if table isn't defined. But i don't know, if other part of bird will not be affected (in negative point of view) by this behaviour.
I will try patch this evenging, thank you for it.
Dan
On 02/24/2013 07:40 PM, Ondrej Filip wrote:
On 24.2.2013 19:35, Hans van Kranenburg wrote:
yes, because 'table master' is default. I produced a simple patch (attached) against the current git repository, but it should work against 1.3.9. However I am not 100% sure whether to submit this into the main branch or rather just document that 'table master' is default. I will discuss it with my teammates. And of course, your comments are welcome. How should the output of the following command in Dans example be interpreted?
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I guess it should be done like: "these are the routes that could possibly be exported from table master via table t_nix to nix1_nix if none of them were being filtered"? This does not make any sense to me as default output. No, that are routes from master table that could be exported to protocol nix1_nix filtered by import protocol. But anyway.
The config Dan is showing explicitely has an import none from master to t_nix, so when being busy to debug route information at the nix1_nix proto, after filtering all those routes from t_nix to nix1_nix (possibly to isolate the test case while tracking down a problem) this looks very confusing.
I'm always a fan of defaults that match how (new) people would use the software intuitively, and here's how I would intuitively think:
One of the first pages you read when starting with bird is this one:
http://bird.network.cz/?get_doc&f=bird-2.html
"Each protocol is connected to a routing table through two filters which can accept, reject and modify the routes. An export filter checks routes passed from the routing table to the protocol, an import filter checks routes in the opposite direction."
This makes me think by default that show route export <protocol> would show me information about what is actually going in in <protocol> right now by default, related to its own connected bird table.
OK. I understand your point.
Ondrej
On 25.2.2013 18:14, Dan Rimal wrote:
Patch works great, show correct routes.
OK. It's sent to the main git tree and will go into 1.3.10. Ondrej
Thank you
Dan
Dne 25.02.13 10:33, Ondrej Filip napsal(a):
On 25.2.2013 09:01, Dan Rimal wrote:
OK, guys! Please let me know if it works. And it will go to 1.3.10. Thank you.
Ondrej
I agree with Hans. I think bird should use table defined within each protocol or use master if table isn't defined. But i don't know, if other part of bird will not be affected (in negative point of view) by this behaviour.
I will try patch this evenging, thank you for it.
Dan
On 02/24/2013 07:40 PM, Ondrej Filip wrote:
On 24.2.2013 19:35, Hans van Kranenburg wrote:
yes, because 'table master' is default. I produced a simple patch (attached) against the current git repository, but it should work against 1.3.9. However I am not 100% sure whether to submit this into the main branch or rather just document that 'table master' is default. I will discuss it with my teammates. And of course, your comments are welcome. How should the output of the following command in Dans example be interpreted?
bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200)
I guess it should be done like: "these are the routes that could possibly be exported from table master via table t_nix to nix1_nix if none of them were being filtered"? This does not make any sense to me as default output. No, that are routes from master table that could be exported to protocol nix1_nix filtered by import protocol. But anyway.
The config Dan is showing explicitely has an import none from master to t_nix, so when being busy to debug route information at the nix1_nix proto, after filtering all those routes from t_nix to nix1_nix (possibly to isolate the test case while tracking down a problem) this looks very confusing.
I'm always a fan of defaults that match how (new) people would use the software intuitively, and here's how I would intuitively think:
One of the first pages you read when starting with bird is this one:
http://bird.network.cz/?get_doc&f=bird-2.html
"Each protocol is connected to a routing table through two filters which can accept, reject and modify the routes. An export filter checks routes passed from the routing table to the protocol, an import filter checks routes in the opposite direction."
This makes me think by default that show route export <protocol> would show me information about what is actually going in in <protocol> right now by default, related to its own connected bird table.
OK. I understand your point.
Ondrej
participants (3)
-
Dan Rimal -
Hans van Kranenburg -
Ondrej Filip