Re: BIRD v1.3.8 - some notes and hamradio requests
On Tue, Aug 28, 2012 at 02:33:44PM +0200, Gustavo Ponza wrote:
Eureka! that patch *definitively* solved the above problem, too :) The BIRD behavior is now *perfectly* equal to that of quagga and the Mikrotik and so, for me, no other limitations to run exclusively the BIRD program. Then, that patch *MUST* definitively enter on the official BIRD release.
It probably will.
1) your only activated interfaces in config file were ppp0, tap0 and eth0, therefore no reason to propagate 44.134.33.71/32, which is just on sl0. You probably want to activate these ifaces as stub ifaces ('stub' option for them).
My tests confirm that: declaring an 'iface' as a 'stub' is perfectly equal to *not activate* that 'iface', at least this happens on the OSPF environment. As result I obtained no OSPF activity and no prefix prefix propagation.
Not true. Interface as stub propagate its addresses to OSPF (at least if it is normal broadcast iface with normal IP prefix, ptp ifaces are a bit special), while not active iface is just ignored.
ifaces. BTW, from the log i see that BIRD misdetected AX.25 interfaces - ifconfig says that they can't support multicast while BIRD says the can.
About the disagreement between the BIRD detection and the ifconfig output that should be a good question for the AX.25 linux developers so, as time permits, I'll try to contact one of them.
It is probably a bug in BIRD.
Note that you can also simply add local IP or prefix for propagation using 'stubnet' option. The simplest way to see what your router is propagating is to find it in 'show ospf state'.
I was not able to setup a 'stubnet' command to test that feature :( no examples found on the documentation and so any setup attempts got the reply: errors on configuration file...
You can use it like: area 0.0.0.0 { stubnet 192.168.11.0/24; stubnet 192.168.12.0/24 { hidden; summary; }; }; It is documented here: http://bird.network.cz/?get_doc&f=bird-6.html#ss6.5
But, in the meantime, since I can monitor the exported routes also on the Mikrotik router, I discovered that my LAN prefix 192.168.1.0/ /24 results propagated by the OSPF (FYI on quagga it does not), so, how can I stop the propagation of such a prefix? (and naturally for any other prefix I do not want to export).
Yes, it is propagated because it is on eth0, which is activated for OSPF. You can either activate eth0 just for some of its addresses: interface "eth0" 192.168.2.0/24 { ... } see examples in here: http://bird.network.cz/?get_doc&f=bird-3.html#dsc-iface or you could suppress that prefix for propagation using stubnet option: stubnet 192.168.1.0/24 { hidden; } But this will not work if there is some other OSPF router connected through 192.168.1.0/24, but that is probably not an issue here. -- 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 Thu, 2012-08-30 at 21:01 +0200, Ondrej Zajicek wrote:
On Tue, Aug 28, 2012 at 02:33:44PM +0200, Gustavo Ponza wrote:
Eureka! that patch *definitively* solved the above problem, too :) The BIRD behavior is now *perfectly* equal to that of quagga and the Mikrotik and so, for me, no other limitations to run exclusively the BIRD program. Then, that patch *MUST* definitively enter on the official BIRD release.
It probably will.
OK, thanks very much ;)
1) your only activated interfaces in config file were ppp0, tap0 and eth0, therefore no reason to propagate 44.134.33.71/32, which is just on sl0. You probably want to activate these ifaces as stub ifaces ('stub' option for them).
My tests confirm that: declaring an 'iface' as a 'stub' is perfectly equal to *not activate* that 'iface', at least this happens on the OSPF environment. As result I obtained no OSPF activity and no prefix prefix propagation.
Not true. Interface as stub propagate its addresses to OSPF (at least if it is normal broadcast iface with normal IP prefix, ptp ifaces are a bit special), while not active iface is just ignored.
You are certainly right for its general behavior and everywhere on the other end of the ptp link you find a true standard router. In our hamradio working situations it doesn't happen since we find a far pseudo-routers ... but, however that 'applications' own always a proper standard prefix, i.e. 44.x.x.x, 10.x.x.x and so on, which in turn needs to be propagates as for the other standard situations. I think that the BIRD should be able to look up and read the prefix on the other end, for any kind of interfaces reported further below. So I strongly hope for that feature. However, for a brief review on what concerning the 'sl0', 'tun0' and 'tunl0' interfaces we are speaking about: sl0 = it is created by the standard linux tool 'slattach' which is distributed with the 'net-tools (base linux networking utilities); this is the core collection of tools such as 'ifconfig', 'route' 'slattach', etc., used to configure networking on linux. tun0 = is created by the standard linux module 'tun'. tunl0 = is created by the standard linux module 'ipip'. Furthermore, linux kernel own, starting from the beginning, the Packet Radio protocols AX.25, NETROM, ROSE (ax0, nr0 and rose0 interface names) followed by several AX.25 linux network device drivers, i.e. mkiss, 6pack, bpqether, scc, etc. The AX.25 was developed in the 1970's by radio amateurs and it is based on the existing wired network protocol X.25. Other newer pseudo-AX.25 protocols such as INP3 and FlexNet are currently used nowadays... We also use the AXIP/AXUDP encapsulation described in RFC-1226 since 1991. Then we are using the IPIP encapsulation and use the iproute2 kernel implementation... and so on.
ifaces. BTW, from the log i see that BIRD misdetected AX.25 interfaces - ifconfig says that they can't support multicast while BIRD says the can.
About the disagreement between the BIRD detection and the ifconfig output that should be a good question for the AX.25 linux developers so, as time permits, I'll try to contact one of them.
It is probably a bug in BIRD.
OK.
Note that you can also simply add local IP or prefix for propagation using 'stubnet' option. The simplest way to see what your router is propagating is to find it in 'show ospf state'.
I was not able to setup a 'stubnet' command to test that feature :( no examples found on the documentation and so any setup attempts got the reply: errors on configuration file...
You can use it like:
area 0.0.0.0 { stubnet 192.168.11.0/24; stubnet 192.168.12.0/24 { hidden; summary; }; };
It is documented here:
http://bird.network.cz/?get_doc&f=bird-6.html#ss6.5
But, in the meantime, since I can monitor the exported routes also on the Mikrotik router, I discovered that my LAN prefix 192.168.1.0/ /24 results propagated by the OSPF (FYI on quagga it does not), so, how can I stop the propagation of such a prefix? (and naturally for any other prefix I do not want to export).
Yes, it is propagated because it is on eth0, which is activated for OSPF. You can either activate eth0 just for some of its addresses:
interface "eth0" 192.168.2.0/24 { ... }
see examples in here:
http://bird.network.cz/?get_doc&f=bird-3.html#dsc-iface
or you could suppress that prefix for propagation using stubnet option:
stubnet 192.168.1.0/24 { hidden; }
But this will not work if there is some other OSPF router connected through 192.168.1.0/24, but that is probably not an issue here.
It was my big mistake since I referenced only to the bird.conf.example file and the other disseminated example files and not to the main BIRD doc, sorry. Yes, I obtained the wanted effect with the following command: stubnet 192.168.1.0/24 { hidden; }; The birdc confirms the cure: bird> sh ospf state area 0.0.0.254 router 10.58.1.1 distance 0 router 44.224.12.25 metric 10 stubnet 10.58.1.0/24 metric 10 stubnet 44.134.32.0/24 metric 10 router 44.224.12.25 distance 10 router 10.58.1.1 metric 10 stubnet 44.224.12.254/32 metric 10 bird> ... stop here for now and thanks again for you patience ;) gus
participants (2)
-
Gustavo Ponza -
Ondrej Zajicek