BIRD v1.3.8 - some notes and hamradio requests

[Gustavo Ponza]

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