Hello,
I have some questions about the normal wanted ripd (ripv2) behaviour.
(running quagga cvs of 16-03-2004, on a linux 2.6.3)
1) Recently i had a problem with ripd on a ppp0 interface, the error was
"RIP: Can't setsockopt IP_MULTICAST_IF to fd 9", (
http://bugzilla.quagga.net/show_bug.cgi?id=83 with a proposed patch ),
the problem seems to be that ripd used the peer ip adress instead of its
own adress on the link to enable the multicast (i wonder why that 'if'
statement was written at all).
But this leads me to another problem: When the 'buggy' ripd wants to
send a rip announce on the ppp0 link it sends it on eth0 instead (yes,
the ppp0 route is sent on eth0, and it's not the eth0 route for eth0)!
which is really unwanted. (especially if eth0 is in passive).
Do you think this needs to be fixed too? even if the first MULTICAST
problem is already fixed? something like checking that the iface is
ready before sending data on it? or maybe checking the return value of
the setsockopt option (actually it has no return value!)?
2) let's say we do this:
router rip
network eth0
passive-interface eth0
when i tcpdump eth0, i see that ripd sends one (and only one) router
request, should this be allowed? Does cisco rip do this too?
3) it seems rip has problems with distance, or i haven't understood the
correct way to use them. This problem is explained more in detail on
http://bugzilla.quagga.net/show_bug.cgi?id=81 but since i don't know
the cisco behaviour, i can't tell, only suppose this is wrong.
in summary:
doing a
router rip
distance 121 10.0.5.1/24
A) doesn't brink the administrative distance directly to 121 of the
link, until ripd is restarted.
B) if another link shows up for a route where 10.0.5.1/24 interface has
been chosen for (before, because of some "failure conditions"), the
[121/2] link doesn't get updated by a [120/2] link. I suppose this
ain't normal.
Please, can you confirm to me that ripd is indeed doing it wrong? =)
Also, I don't know if i'll be able to fix point 3, i'm still lost in the
source code
--
Jean-Yves Simon <lethalwp@tiscali.be>
I have some questions about the normal wanted ripd (ripv2) behaviour.
(running quagga cvs of 16-03-2004, on a linux 2.6.3)
1) Recently i had a problem with ripd on a ppp0 interface, the error was
"RIP: Can't setsockopt IP_MULTICAST_IF to fd 9", (
http://bugzilla.quagga.net/show_bug.cgi?id=83 with a proposed patch ),
the problem seems to be that ripd used the peer ip adress instead of its
own adress on the link to enable the multicast (i wonder why that 'if'
statement was written at all).
But this leads me to another problem: When the 'buggy' ripd wants to
send a rip announce on the ppp0 link it sends it on eth0 instead (yes,
the ppp0 route is sent on eth0, and it's not the eth0 route for eth0)!
which is really unwanted. (especially if eth0 is in passive).
Do you think this needs to be fixed too? even if the first MULTICAST
problem is already fixed? something like checking that the iface is
ready before sending data on it? or maybe checking the return value of
the setsockopt option (actually it has no return value!)?
2) let's say we do this:
router rip
network eth0
passive-interface eth0
when i tcpdump eth0, i see that ripd sends one (and only one) router
request, should this be allowed? Does cisco rip do this too?
3) it seems rip has problems with distance, or i haven't understood the
correct way to use them. This problem is explained more in detail on
http://bugzilla.quagga.net/show_bug.cgi?id=81 but since i don't know
the cisco behaviour, i can't tell, only suppose this is wrong.
in summary:
doing a
router rip
distance 121 10.0.5.1/24
A) doesn't brink the administrative distance directly to 121 of the
link, until ripd is restarted.
B) if another link shows up for a route where 10.0.5.1/24 interface has
been chosen for (before, because of some "failure conditions"), the
[121/2] link doesn't get updated by a [120/2] link. I suppose this
ain't normal.
Please, can you confirm to me that ripd is indeed doing it wrong? =)
Also, I don't know if i'll be able to fix point 3, i'm still lost in the
source code
--
Jean-Yves Simon <lethalwp@tiscali.be>