On Fri, May 07, 2021 at 11:14:27AM +0000, Joakim Tjernlund wrote:
> On Fri, 2021-05-07 at 13:09 +0200, Ondrej Zajicek wrote:
> > On Fri, May 07, 2021 at 04:53:44AM +0000, Senthil Kumar Nagappan wrote:
> > >  Hi Joakim,
> > > Thanks for your response.
> > > Will try to elaborate point2 with sample config.
> > > 1. Config at Router R1
> > > lo interfaceinterface loopback lo has ip addr 100.100.100.125 
> > > eth1for unnumbered borrowing the lo address for eth1 and 100.100.100.126 
> > > is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev 
> > > eth1
> > > eth2for unnumbered borrowing the lo address for eth2 and 100.100.100.126 
> > > is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev 
> > > eth2
> > > 2. Config at Router R2Its identical to R1 config except for the loopback 
> > > ip which is 100.100.100.126 and the correspondingpeer address config for 
> > > eth1 and eth2
> > > 
> > > 3. Enable ospf on eth1 and eth2 at R1 and R2
> > > 4. Only one of the ospf adj will become FULL either over eth1 or eth2 and 
> > > not both
> > > 5. Since the peer address configurations adds a route to other end 
> > > loopback address and since thedb packets are sent as unicast, route 
> > > lookup happens and db packets wont be sent out from one of the links.
> > 
> > I do not think that should be true (at least on Linux). OSPF sockets are
> > bound to specific interface using SO_BINDTODEVICE and use SO_DONTROUTE to
> > avoid route lookups, so even unicast packets should be sent to specific
> > interface. If that really happens, that is worth investigating. What is
> > your OS and BIRD version? Did you verify that using tcpdump or similar
> > tool?
> > 
> 
> That may be so, but I still think that the issue reported in 1) is valid bug, 
> don't you?

Yes, i agree. Just think that this issue is worth investigating
independently and not just avoiding that by fixing 1).

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@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."

Reply via email to