Mailing List Archive

On Sun, 9 Nov 2003, Krzysztof Oledzki wrote:

> Hello,
>
> This patch reverts modification in ripd which changed code responsible for
> split horizon calculation. In oryginal quagga 0.96.4 split horizon
> simply does not work and ripd no longer redistribute 0.0.0.0/0. The
> broblem is in rip_output_process function. Code from zebra-0.93b and old
> quagga:
>
> if ((rinfo->type == ZEBRA_ROUTE_RIP ||
> rinfo->type == ZEBRA_ROUTE_CONNECT) &&
> rinfo->ifindex == ifp->ifindex)
> continue;
>
> was changed into:
>
> if ((rinfo->type == ZEBRA_ROUTE_RIP ||
> rinfo->type == ZEBRA_ROUTE_CONNECT) &&
> prefix_match((struct prefix *)p, (struct prefix *)saddr))
> continue;

OK, it seems there are some other changes:

{
+ struct prefix_ipv4 saddr;
+
+ /* saddr will be used for determining which routes to split-horizon.
+ Since the source address we'll pick will be on the same subnet as the
+ destination, for the purpose of split-horizoning, we'll
+ pretend that "from" is our source address. */
+ saddr.family = AF_INET;
+ saddr.prefixlen = IPV4_MAX_BITLEN;
+ saddr.prefix = from->sin_addr;
+ /* All route with split horizon */
- rip_output_process (ifp, from, rip_all_route, packet->version);
+ rip_output_process (ifp, NULL, from, rip_all_route, packet->version,
+ &saddr);
}

Any comment on this? I'm trying to understand how this ought to work.. Hm?

Best regards,


Krzysztof Olêdzki

Krzysztof Oledzki <oleq@ans.pl> asks:

>
> Hello,
>
> This patch reverts modification in ripd which changed code responsible for
> split horizon calculation. In oryginal quagga 0.96.4 split horizon
> simply does not work and ripd no longer redistribute 0.0.0.0/0. The
> broblem is in rip_output_process function. Code from zebra-0.93b and old
> quagga:
>
> if ((rinfo->type =3D=3D ZEBRA_ROUTE_RIP ||
> rinfo->type =3D=3D ZEBRA_ROUTE_CONNECT) &&
> rinfo->ifindex =3D=3D ifp->ifindex)
> continue;
>
> was changed into:
>
> if ((rinfo->type =3D=3D ZEBRA_ROUTE_RIP ||
> rinfo->type =3D=3D ZEBRA_ROUTE_CONNECT) &&
> prefix_match((struct prefix *)p, (struct prefix *)saddr))
> continue;
>
> Mayby I missed something, but I see no explanation to change this. What
> this was suppose to fix, anyway?
>
And adds:

> OK, it seems there are some other changes:
>
> {
> + struct prefix_ipv4 saddr;
> +
> + /* saddr will be used for determining which routes to split-horizon.
> + Since the source address we'll pick will be on the same subnet as the
> + destination, for the purpose of split-horizoning, we'll
> + pretend that "from" is our source address. */
> + saddr.family = AF_INET;
> + saddr.prefixlen = IPV4_MAX_BITLEN;
> + saddr.prefix = from->sin_addr;
> + /* All route with split horizon */
> - rip_output_process (ifp, from, rip_all_route, packet->version);
> + rip_output_process (ifp, NULL, from, rip_all_route, packet->version,
> + &saddr);
> }

This set of changes went in as part of the ripd fix to handle
interface aliases (see [quagga-dev 330]). rfc 2453 requires the
router to send updates and requests to each connected network. Thus,
if an interface has multiple ip addresses, it's connected to multiple
networks, the router has to send an update on each network (i.e., specify
the source address of the multicast packet appropriately, and send
it down that interface).

e.g., if an interface eth0 has 2 addresses: 10.10.80.60/24 and
192.168.80.60/24, the router has to send 2 updates/responses, one
with src addr in the 10.10.80.0/24 network and the other in the
192.168.80.0/24 network.

However, the router has to split-horizon the 10.10.80.60/24 network
when it's sending an update in the 192.168.80.60/24 network and
vice-versa, hence the insertion of the prefix match test.

paul@clubi.ie asked:

> Why rebind at all? even for solaris?

Reason: the router has to set the source address appropriately, and
the prescription for doing this is by binding.

--Sowmini

On Mon, 10 Nov 2003 sowmini.varadhan@sun.com wrote:

> Krzysztof Oledzki <oleq@ans.pl> asks:
>
> >
> > Hello,
> >
> > This patch reverts modification in ripd which changed code responsible for
> > split horizon calculation. In oryginal quagga 0.96.4 split horizon
> > simply does not work and ripd no longer redistribute 0.0.0.0/0. The
> > broblem is in rip_output_process function. Code from zebra-0.93b and old
> > quagga:
> >
> > if ((rinfo->type =3D=3D ZEBRA_ROUTE_RIP ||
> > rinfo->type =3D=3D ZEBRA_ROUTE_CONNECT) &&
> > rinfo->ifindex =3D=3D ifp->ifindex)
> > continue;
> >
> > was changed into:
> >
> > if ((rinfo->type =3D=3D ZEBRA_ROUTE_RIP ||
> > rinfo->type =3D=3D ZEBRA_ROUTE_CONNECT) &&
> > prefix_match((struct prefix *)p, (struct prefix *)saddr))
> > continue;
> >
> > Mayby I missed something, but I see no explanation to change this. What
> > this was suppose to fix, anyway?
> >
> And adds:
>
> > OK, it seems there are some other changes:
> >
> > {
> > + struct prefix_ipv4 saddr;
> > +
> > + /* saddr will be used for determining which routes to split-horizon.
> > + Since the source address we'll pick will be on the same subnet as the
> > + destination, for the purpose of split-horizoning, we'll
> > + pretend that "from" is our source address. */
> > + saddr.family = AF_INET;
> > + saddr.prefixlen = IPV4_MAX_BITLEN;
> > + saddr.prefix = from->sin_addr;
> > + /* All route with split horizon */
> > - rip_output_process (ifp, from, rip_all_route, packet->version);
> > + rip_output_process (ifp, NULL, from, rip_all_route, packet->version,
> > + &saddr);
> > }
>
> This set of changes went in as part of the ripd fix to handle
> interface aliases (see [quagga-dev 330]). rfc 2453 requires the
> router to send updates and requests to each connected network. Thus,
> if an interface has multiple ip addresses, it's connected to multiple
> networks, the router has to send an update on each network (i.e., specify
> the source address of the multicast packet appropriately, and send
> it down that interface).

OK :) Clear so far...

> e.g., if an interface eth0 has 2 addresses: 10.10.80.60/24 and
> 192.168.80.60/24, the router has to send 2 updates/responses, one
> with src addr in the 10.10.80.0/24 network and the other in the
> 192.168.80.0/24 network.

True..

> However, the router has to split-horizon the 10.10.80.60/24 network
> when it's sending an update in the 192.168.80.60/24 network and
> vice-versa, hence the insertion of the prefix match test.

Hm... But I'm afraid it does not work that way. For example 0.0.0.0/0
allways match and is never redistributed. And now I have a lot of
redistributed routes that were not redistributed before. They should be
filtered by split-horizon, definitely.

Best regards,

Krzysztof Olêdzki

> Hm... But I'm afraid it does not work that way. For example 0.0.0.0/0

maybe we should make exception for default route?

Prior to my change, the split horizoning was done by testing for
an interface match, but that won't work in this case.. routers on
the 10.10.80.0/24 network need to know that they can reach the
192.169.16.0/24 guys by contacting the multihomed router, so we
can't suppress routes based on the interface...

> allways match and is never redistributed. And now I have a lot of
> redistributed routes that were not redistributed before. They should be
> filtered by split-horizon, definitely.

you are seeing bugs other than the incorrect suppression of default?
Can you clarify with an example?

--Sowmini

On Mon, 10 Nov 2003 sowmini.varadhan@Sun.COM wrote:

>
> > Hm... But I'm afraid it does not work that way. For example 0.0.0.0/0
> maybe we should make exception for default route?
Not sure. default-route should also be check agains split-horizon.


> Prior to my change, the split horizoning was done by testing for
> an interface match,
True, True.

> but that won't work in this case.. routers on the 10.10.80.0/24 network
> need to know that they can reach the 192.169.16.0/24 guys by contacting
> the multihomed router, so we can't suppress routes based on the
> interface...
Agree, but still, there is something wrong with current algo.

> > allways match and is never redistributed. And now I have a lot of
> > redistributed routes that were not redistributed before. They should be
> > filtered by split-horizon, definitely.
>
> you are seeing bugs other than the incorrect suppression of default?
> Can you clarify with an example?
Preparing one :)

Best regards,

Krzysztof Olêdzki

Helo,

On Mon, 10 Nov 2003 sowmini.varadhan@Sun.COM wrote:
> you are seeing bugs other than the incorrect suppression of default?
> Can you clarify with an example?
Sent. This time not to quagga-dev mailing list - it has ip adresses of my
networks.

Best regards,

Krzysztof Olêdzki

On Mon, 10 Nov 2003 sowmini.varadhan@sun.com wrote:

> Prior to my change, the split horizoning was done by testing for
> an interface match, but that won't work in this case.. routers on
> the 10.10.80.0/24 network need to know that they can reach the
> 192.169.16.0/24 guys by contacting the multihomed router, so we
> can't suppress routes based on the interface...

So, IMHO it should work something like this:

- When ripd recives update it should check to which local IP address this
update should be assigned and it should store this IP address insted of device
id. This checking should be performed anyway, since we need to check for
bogus updates, and ignores ones from hosts not on current network, right?

- When sending updates, ripd should check saved IP address and IP
address used in adv. If they match route should not be advertised.

One BIG problem: Assume we have two routers connected to the same network,
both with two IP addresses:
- router A: 192.168.0.1 (main), 192.168.1.1 (secondary)
- router B: 192.168.0.2 (main), 192.168.1.2 (secondary)

Router A adertises route to router B using 192.168.0.1 address.
Then router B adertises this route back to router B using 192.168.1.2.
And... split-horizon based on IP address does not work and we have nasty
loop.


Shouldn't we stay with old working split-horizon calculation based on
intarface? AFAIK this the only safe way to do this. Anyway, I can't see
any reason to do this other way. If is more than one logical network on
one physical network all ripd routers should exist in all networks. Or am
I wrong? Does RFC say something different about this?

Best regards,

Krzysztof Olêdzki

> - When ripd recives update it should check to which local IP address this
> update should be assigned and it should store this IP address insted of device
> id. This checking should be performed anyway, since we need to check for
> bogus updates, and ignores ones from hosts not on current network, right?

Well, it should check that the source address of the respose/update
is on the same network as the interface on which it is received.
To quote rfc 2453 (Section 3.9.2):
" .. The
datagram's IPv4 source address should be checked to see whether the
datagram is from a valid neighbor; the source of the datagram must be
on a directly-connected network. "


> - When sending updates, ripd should check saved IP address and IP
> address used in adv. If they match route should not be advertised.

agreed.

> One BIG problem: Assume we have two routers connected to the same network,
> both with two IP addresses:
> - router A: 192.168.0.1 (main), 192.168.1.1 (secondary)
> - router B: 192.168.0.2 (main), 192.168.1.2 (secondary)
>
> Router A adertises route to router B using 192.168.0.1 address.
> Then router B adertises this route back to router B using 192.168.1.2.
> And... split-horizon based on IP address does not work and we have nasty
> loop.

no.. when router A sends an adv on the 192.168.0.1/24 network,
it should advertise 192.168.1.0/24 as reachable through router A, but
suppress 192.168.0.1/24. Router B should see this adv and realize that
it is directly connected to 192.168.1.0/24 (i.e., reachable with metric 0)
and ignore the route which comes in with metric 1.
(unless the 192.168.1.2 address is deleted, in which case it adds the route).

when router B sends updates back to A on the 192.168.1.2/24 network
it has to decide whether or not to suppress:
1. 192.168.0.0/24 (send)
2. 192.168.1.0/24 (suppress, because prefix matches chosen source address)

> Shouldn't we stay with old working split-horizon calculation based on
> intarface? AFAIK this the only safe way to do this. Anyway, I can't see
> any reason to do this other way. If is more than one logical network on
> one physical network all ripd routers should exist in all networks. Or am
> I wrong? Does RFC say something different about this?
>

The rfc says:

Section 3.9.1:

.... When a router first comes
up, it multicasts a Request on every connected network asking for a
complete routing table.

The special address 0.0.0.0 is used to describe a default route. A
default route is used when it is not convenient to list every
possible network in the RIP updates, and when one or more closely-
connected routers in the system are prepared to handle traffic to the
networks that are not listed explicitly. These routers should create
RIP entries for the address 0.0.0.0, just as if it were a network to
which they are connected. The decision as to how routers create
entries for 0.0.0.0 is left to the implementor.

and in Section 3.10:

.. When a Response is to be sent to all neighbors (i.e., a regular or
triggered update), a Response message is directed to the router at
the far end of each connected point-to-point link, and is broadcast
(multicast for RIP-2) on all connected networks which support
broadcasting. Thus, one Response is prepared for each directly-
connected network, and sent to the appropriate address (direct or
broadcast/multicast).


I think the objective is to handle the case of connectivity when some
address of a multihomed interface is deleted (i.e., the router is removed
from a network on that interface but continues to be homed on other
networks).

--Sowmini

On Mon, 10 Nov 2003 sowmini.varadhan@sun.com wrote:

> Reason: the router has to set the source address appropriately, and
> the prescription for doing this is by binding.

Or how about making use of the info field in struct interface,
creating a struct of rip specific interface information (struct
rip_interface - would be subnet specific), and having a socket per
subnet?

> --Sowmini

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
"It's God. No, not Richard Stallman, or Linus Torvalds, but God."
(By Matt Welsh)

On Mon, 10 Nov 2003 sowmini.varadhan@sun.com wrote:

<CIACH>
> no.. when router A sends an adv on the 192.168.0.1/24 network, it should
> advertise 192.168.1.0/24 as reachable through router A, but suppress
> 192.168.0.1/24. Router B should see this adv and realize that it is
> directly connected to 192.168.1.0/24 (i.e., reachable with metric 0) and
> ignore the route which comes in with metric 1. (unless the 192.168.1.2
> address is deleted, in which case it adds the route).
OK, This example was not very good :) You are right, but...

<CIACH>
> I think the objective is to handle the case of connectivity when some
> address of a multihomed interface is deleted (i.e., the router is removed
> from a network on that interface but continues to be homed on other
> networks).
But the big question is - what we should do with forwarded routes,
received from other RIP routers? I found quite good explanation of
expected split-horizon characteristic:

Split Horizon is a algorithm for avoiding problems caused by
including routes in updates sent to the gateway from which they were
learned. The basic split horizon algorithm omits routes learned from
one neighbor in updates sent to that neighbor. In the case of a
broadcast network, all routes learned from any neighbor on that
network are omitted from updates sent on that network.

It is from rfc2080 (RIPng for IPv6, but this is not very important here)

The problem is what we tread as a natwork? As a physical intarface or a
logical network address?


My new example looks like this:

rC
|
|
rA=====rB


There are two physical networks - rC<->rA and rA<->rB. A and B
routers in rA<->rB network both have two IP addresses like in my previous
example:
- router A: 192.168.0.1 (main), 192.168.1.1 (secondary)
- router B: 192.168.0.2 (main), 192.168.1.2 (secondary)

Let's assume that rC advertises 0.0.0.0/0 network:

- rC send it to rA <- OK
- rA send it to rB via 192.168.0.0 <- OK
- rB send it to rA via 192.168.1.1 <- shouldn't happend

Now, if C lose 0.0.0.0/0 it will advertise it with metric 16 and rA switch
to route received from rB via 192.168.1.1 and it will take "ages" for this
route to expire, even with triggered updates. This needs be handled by
split horizon and that is why we should keep split-horizon based on
physical intarface.

Anyway, maybe there is some clever solution for this problem? How this is
handled by other vendors, like CISCO for example?

Best regards,


Krzysztof Olêdzki

OK, the code looks like this:

/* Split horizon. */
/* if (split_horizon == rip_split_horizon) */
if (ri->split_horizon == RIP_SPLIT_HORIZON)
{
/* We perform split horizon for RIP and connected route. */
if ((rinfo->type == ZEBRA_ROUTE_RIP ||
rinfo->type == ZEBRA_ROUTE_CONNECT) &&
prefix_match((struct prefix *)p, (struct prefix *)saddr))
continue;
}

It seems that ripd compares prefix itself not the IP address of the
interface from which it received it. Definitely. So 0.0.0.0/0 always
matches and will never be redistributed. Connected network address of
current intarface also matches. And that's all. No other addresses match.
So it must be fixed somehow. We can put back old, good, working
based-on-intarface algo or we can fix this one. But if we decided to fix
it we have to solve the problem I have just described in [quagga-dev 450].

Best regards,

Krzysztof Olêdzki

On Tue, 11 Nov 2003, Krzysztof Oledzki wrote:

> addresses match. So it must be fixed somehow. We can put back old,
> good, working based-on-intarface algo or we can fix this one.

I'd say fix this one, ripd does need to deal with multiple subnets,
and sowmini's work goes a long way toward that.

> But if we decided to fix it we have to solve the problem I have
> just described in [quagga-dev 450].

Havnt followed it too closely, but the rebind stuff isnt good. Either
use a nicely portable method to set the source address or go back to
socket per interface (which i suggest would be best done by making
use of the (struct interface).info field to maintain a list of rip
network specific information for each struct interface (and hence
which could consolidate some of the extra args that are being passed
up and down layers which sowmini's patch added).

> Best regards,
>
> Krzysztof Olędzki

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The Moral Majority is neither.

On Tue, 11 Nov 2003, Paul Jakma wrote:

> On Tue, 11 Nov 2003, Krzysztof Oledzki wrote:
>
> > addresses match. So it must be fixed somehow. We can put back old,
> > good, working based-on-intarface algo or we can fix this one.
> I'd say fix this one, ripd does need to deal with multiple subnets,
> and sowmini's work goes a long way toward that.
Ah, but split-horizon based on interface does not break multiple
subnets announces. It only keep an eye on announced prefixes so we stay
out of loop problems.

> > But if we decided to fix it we have to solve the problem I have
> > just described in [quagga-dev 450].
>
> Havnt followed it too closely, but the rebind stuff isnt good. Either
> use a nicely portable method to set the source address or go back to
> socket per interface (which i suggest would be best done by making
> use of the (struct interface).
Ah :) [quagga-dev 450] is not exactly about this but since you mention
this..

It took me w while to check this but.. here it is: with RIPv2 ripd trys
to use multicast announces. There is a very usefull function
setsockopt_multicast_ipv4() in lib/sockopt.c - which sets up multicast
socket options. It also sets sender address so that's why in current
broken quagga everything works just fine, without rebinds, etc... until we
use RIPv2 & multicast.

For broadcast, which is standard for RIPv1 and fallback for RIPv2, it is
not so simple. I'm afraid there is no way to bind one socket to
0.0.0.0:520 and second one to other address and this same port, is
there? And we cannot close & open main ripd socket because we will
then lose all packets send to us while the "0.0.0.0:520" is being absent.




Anyway, I have just noticed that there is one more thing broken in ripd
from current quagga. If default version protocol is RIPv2 even if we set
v1 version per interface:

interface eth0
ip rip send version 1

ripd will still use RIPv2 but it will switch from multicast to broadcast
as required for RIPv1. The problem is with this change in ripd.c in
the rip_update_interface() function:

zebra && old quagga:

rip_output_process (ifp, &to, route_type, version);

new quagga:
rip_output_process (ifp, connected->address, &to, route_type,
rip->version_send, saddr);

Since we changed "version" into "rip->version_send" we now use global rip
version not the local to interface one. So, there is no longer possible to
use differet protocol version on different interfaces. Why?


There is also something which I don't understand.
Why we cannot just use:
rip_update_interface (ifp, vsend, route_type, ifaddr);

instead of:
if (vsend & RIPv1)
rip_update_interface (ifp, RIPv1, route_type, ifaddr);
if (vsend & RIPv2)
rip_update_interface (ifp, RIPv2, route_type, ifaddr);

This code is from the rip_update_process() function.

Best regards,


Krzysztof Olêdzki

> From: Krzysztof Oledzki <oleq@ans.pl>
> Ah, but split-horizon based on interface does not break multiple
> subnets announces. It only keep an eye on announced prefixes so we stay
> out of loop problems.

I'm not convinced. In your example:

> My new example looks like this:
>
> rC
> |
> |
> rA=====rB
>
>
> There are two physical networks - rC<->rA and rA<->rB. A and B
> routers in rA<->rB network both have two IP addresses like in my previous
> example:
> - router A: 192.168.0.1 (main), 192.168.1.1 (secondary)
> - router B: 192.168.0.2 (main), 192.168.1.2 (secondary)
>
> Let's assume that rC advertises 0.0.0.0/0 network:
>
> - rC send it to rA <- OK
> - rA send it to rB via 192.168.0.0 <- OK
> - rB send it to rA via 192.168.1.1 <- shouldn't happend

Replace the "====" link between rA and rB with 2 physical links (instead
of having 1 link with multiple subnets), and your "shouldn't happened"
case will happen. Testing for interface match will not prevent the problem.

> The problem is what we tread as a natwork? As a physical intarface or a
> logical network address?

The bigger question is, does it really matter (whether you are multhiomed
on multiple interfaces or the same interface)?

--Sowmini

On Tue, 11 Nov 2003 sowmini.varadhan@sun.com wrote:
> > - router A: 192.168.0.1 (main), 192.168.1.1 (secondary)
> > - router B: 192.168.0.2 (main), 192.168.1.2 (secondary)
> >
> > Let's assume that rC advertises 0.0.0.0/0 network:
> >
> > - rC send it to rA <- OK
> > - rA send it to rB via 192.168.0.0 <- OK
> > - rB send it to rA via 192.168.1.1 <- shouldn't happend
>
> Replace the "====" link between rA and rB with 2 physical links (instead
> of having 1 link with multiple subnets), and your "shouldn't happened"
> case will happen. Testing for interface match will not prevent the problem.

Oh, you can disable RIP per interface, you can make intarface passive.
You can add route-map and match interface. But you can't disable
RIP per address nor make address passive nor match connected address in
route-map.

> > The problem is what we tread as a natwork? As a physical intarface or a
> > logical network address?
>
> The bigger question is, does it really matter (whether you are multhiomed
> on multiple interfaces or the same interface)?
IMHO yes.

Best regards,

Krzysztof Olêdzki

On Tue, 11 Nov 2003, Krzysztof Oledzki wrote:
> It took me w while to check this but.. here it is: with RIPv2 ripd trys
> to use multicast announces. There is a very usefull function
> setsockopt_multicast_ipv4() in lib/sockopt.c - which sets up multicast
> socket options. It also sets sender address so that's why in current
> broken quagga everything works just fine, without rebinds, etc... until we
> use RIPv2 & multicast.
>
> For broadcast, which is standard for RIPv1 and fallback for RIPv2, it is
> not so simple. I'm afraid there is no way to bind one socket to
> 0.0.0.0:520 and second one to other address and this same port, is
> there? And we cannot close & open main ripd socket because we will
> then lose all packets send to us while the "0.0.0.0:520" is being absent.

Eh ;-) It seems that I was wrong. It is possible to do the second, more
specific bind:

#include <string.h>
#include <stdio.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/types.h>

int main() {

int s1, s2;
struct sockaddr_in from;
int on = 1;
int rv;

memset (&from, 0, sizeof (struct sockaddr_in));
from.sin_port = htons(8192);
from.sin_family = AF_INET;
from.sin_addr.s_addr = inet_addr("0.0.0.0");

s1 = socket(PF_INET, SOCK_DGRAM, 0);
setsockopt(s1, SOL_SOCKET, SO_REUSEADDR, (void *) &on, sizeof (on));
rv = bind(s1, (struct sockaddr *) &from, sizeof(from));
printf("bind to %s:%d - %s\n", inet_ntoa(from.sin_addr), ntohs(from.sin_port), (rv)?"error":"OK");

from.sin_addr.s_addr = inet_addr("192.168.0.2");
s2 = socket(PF_INET, SOCK_DGRAM, 0);
setsockopt(s2, SOL_SOCKET, SO_REUSEADDR, (void *) &on, sizeof (on));
rv = bind(s2, (struct sockaddr *) &from, sizeof(from));
printf("bind to %s:%d - %s\n", inet_ntoa(from.sin_addr), ntohs(from.sin_port), (rv)?"error":"OK");

return 0;
}

We just need to use magic SO_REUSEADDR sockopt ;-) So, it is not as bad as
I thought. For RIPv2 multicast announces we can change sender address
without rebinding. For broadcast (RIPv1 and fall back for RIPv2) we need
this second bind. That's is all. Yes, yes, yes. I was wrong. Sorry :)

Best regards,


Krzysztof Olêdzki

> > > Let's assume that rC advertises 0.0.0.0/0 network:
> > >
> > > - rC send it to rA <- OK
> > > - rA send it to rB via 192.168.0.0 <- OK
> > > - rB send it to rA via 192.168.1.1 <- shouldn't happend
> >
> > Replace the "====" link between rA and rB with 2 physical links (instead
> > of having 1 link with multiple subnets), and your "shouldn't happened"
> > case will happen. Testing for interface match will not prevent the problem.
>
> Oh, you can disable RIP per interface, you can make intarface passive.
> You can add route-map and match interface. But you can't disable
> RIP per address nor make address passive nor match connected address in
> route-map.

You can also do "no network 192.168.1.0/24" but that is not the point.

If there's a bug in the split-horizoning logic (in the RFC, not in
this particular implementation of the rfc), then all of these
are workarounds.

I may want to have 2 links to support redundancy at layer 2,
or I may want to have interface aliases to support redundancy at layer 3,
RIP is supposed to play nicely with both solutions, without the
administrator having to cripple/disable/silence something.

--Sowmini

>
> I'm not convinced. In your example:
>
> > My new example looks like this:
> >
> > rC
> > |
> > |
> > rA=====rB
> >
> >
> > There are two physical networks - rC<->rA and rA<->rB. A and B
> > routers in rA<->rB network both have two IP addresses like in my previous
> > example:
> > - router A: 192.168.0.1 (main), 192.168.1.1 (secondary)
> > - router B: 192.168.0.2 (main), 192.168.1.2 (secondary)
> >
> > Let's assume that rC advertises 0.0.0.0/0 network:
> >
> > - rC send it to rA <- OK
> > - rA send it to rB via 192.168.0.0 <- OK
> > - rB send it to rA via 192.168.1.1 <- shouldn't happend
>
> Replace the "====" link between rA and rB with 2 physical links (instead
> of having 1 link with multiple subnets), and your "shouldn't happened"
> case will happen. Testing for interface match will not prevent the problem.

Well, on discussing this with a colleague, here's what I see as the answer:

1. you cannot compare the interface for determining split-horizoning of
ZEBRA_ROUTE_CONNECT routes- this breaks for the case when there are multiple
subnets on the same vlan (i.e., interface has multiple addresses)

2. you cannot use prefix-match for determining split-horizining of
ZEBRA_ROUTE_RIP routes. The correct thing to do, in this case, is
see if the sender will be sending it out with a higher metric
than what he received for that interface. In other words, the
sender has to compare if rinfo->ifindex == ifp->ifindex in this case.

Yes?

--Sowmini

>
> Well, on discussing this with a colleague, here's what I see as the answer:
>
> 1. you cannot compare the interface for determining split-horizoning of
> ZEBRA_ROUTE_CONNECT routes- this breaks for the case when there are multiple
> subnets on the same vlan (i.e., interface has multiple addresses)
>
> 2. you cannot use prefix-match for determining split-horizining of
> ZEBRA_ROUTE_RIP routes. The correct thing to do, in this case, is
> see if the sender will be sending it out with a higher metric
> than what he received for that interface. In other words, the
> sender has to compare if rinfo->ifindex == ifp->ifindex in this case.
>
> Yes?

In other words (tested on the ra <--> rb <==> rc setup proposed in the
example, with 2 physical links between rb and rc, and 2 subnets on
one vlan between rb and rc)

===================================================================
RCS file: ripd.c,v
retrieving revision 1.11
diff -uwb -r1.11 ripd.c
--- ripd.c 2003/10/15 23:20:17 1.11
+++ ripd.c 2003/11/12 15:07:52
@@ -2117,9 +2117,20 @@
/* if (split_horizon == rip_split_horizon) */
if (ri->split_horizon == RIP_SPLIT_HORIZON)
{
- /* We perform split horizon for RIP and connected route. */
- if ((rinfo->type == ZEBRA_ROUTE_RIP ||
- rinfo->type == ZEBRA_ROUTE_CONNECT) &&
+ /*
+ * We perform split horizon for RIP and connected route.
+ * For rip routes, we want to suppress the route if we would
+ * end up sending the route back on the interface that we
+ * learned it from, with a higher metric. For connected routes,
+ * we suppress the route if the prefix is a subset of the
+ * source address that we are going to use for the packet
+ * (in order to handle the case when multiple subnets are
+ * configured on the same interface).
+ */
+ if (rinfo->type == ZEBRA_ROUTE_RIP &&
+ rinfo->ifindex == ifp->ifindex)
+ continue;
+ if (rinfo->type == ZEBRA_ROUTE_CONNECT &&
prefix_match((struct prefix *)p, (struct prefix *)saddr))
continue;
}
@@ -2204,10 +2215,22 @@
* for RIP and connected routes.
**/
if (ri->split_horizon == RIP_SPLIT_HORIZON_POISONED_REVERSE) {
- if ((rinfo->type == ZEBRA_ROUTE_RIP ||
- rinfo->type == ZEBRA_ROUTE_CONNECT) &&
+ /*
+ * We perform split horizon for RIP and connected route.
+ * For rip routes, we want to suppress the route if we would
+ * end up sending the route back on the interface that we
+ * learned it from, with a higher metric. For connected routes,
+ * we suppress the route if the prefix is a subset of the
+ * source address that we are going to use for the packet
+ * (in order to handle the case when multiple subnets are
+ * configured on the same interface).
+ */
+ if (rinfo->type == ZEBRA_ROUTE_RIP &&
rinfo->ifindex == ifp->ifindex)
rinfo->metric_out = RIP_METRIC_INFINITY;
+ if (rinfo->type == ZEBRA_ROUTE_CONNECT &&
+ prefix_match((struct prefix *)p, (struct prefix *)saddr))
+ rinfo->metric_out = RIP_METRIC_INFINITY;
}

/* Write RTE to the stream. */

On Wed, 12 Nov 2003 sowmini.varadhan@sun.com wrote:
> ===================================================================
> RCS file: ripd.c,v
> retrieving revision 1.11
> diff -uwb -r1.11 ripd.c
> --- ripd.c 2003/10/15 23:20:17 1.11
> +++ ripd.c 2003/11/12 15:07:52
> @@ -2117,9 +2117,20 @@
> /* if (split_horizon == rip_split_horizon) */
> if (ri->split_horizon == RIP_SPLIT_HORIZON)
> {
> - /* We perform split horizon for RIP and connected route. */
> - if ((rinfo->type == ZEBRA_ROUTE_RIP ||
> - rinfo->type == ZEBRA_ROUTE_CONNECT) &&
> + /*
> + * We perform split horizon for RIP and connected route.
> + * For rip routes, we want to suppress the route if we would
> + * end up sending the route back on the interface that we
> + * learned it from, with a higher metric. For connected routes,
> + * we suppress the route if the prefix is a subset of the
> + * source address that we are going to use for the packet
> + * (in order to handle the case when multiple subnets are
> + * configured on the same interface).
> + */
> + if (rinfo->type == ZEBRA_ROUTE_RIP &&
> + rinfo->ifindex == ifp->ifindex)
> + continue;
> + if (rinfo->type == ZEBRA_ROUTE_CONNECT &&
> prefix_match((struct prefix *)p, (struct prefix *)saddr))
> continue;
> }
> @@ -2204,10 +2215,22 @@
> * for RIP and connected routes.
> **/
> if (ri->split_horizon == RIP_SPLIT_HORIZON_POISONED_REVERSE) {
> - if ((rinfo->type == ZEBRA_ROUTE_RIP ||
> - rinfo->type == ZEBRA_ROUTE_CONNECT) &&
> + /*
> + * We perform split horizon for RIP and connected route.
> + * For rip routes, we want to suppress the route if we would
> + * end up sending the route back on the interface that we
> + * learned it from, with a higher metric. For connected routes,
> + * we suppress the route if the prefix is a subset of the
> + * source address that we are going to use for the packet
> + * (in order to handle the case when multiple subnets are
> + * configured on the same interface).
> + */
> + if (rinfo->type == ZEBRA_ROUTE_RIP &&
> rinfo->ifindex == ifp->ifindex)
> rinfo->metric_out = RIP_METRIC_INFINITY;
> + if (rinfo->type == ZEBRA_ROUTE_CONNECT &&
> + prefix_match((struct prefix *)p, (struct prefix *)saddr))
> + rinfo->metric_out = RIP_METRIC_INFINITY;
> }
>
> /* Write RTE to the stream. */

OK. This patch looks very reasonably for me. ;-)

Best Regards,


Krzysztof Olêdzki

On Wed, 12 Nov 2003, Krzysztof Oledzki wrote:

> OK. This patch looks very reasonably for me. ;-)

And it fixes your problems?

(at least wrt ripd and without prejudice to you :) ).

> Best Regards,
>
>
> Krzysztof Olędzki

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
I'm going to live forever, or die trying!
-- Spider Robinson

> Or how about making use of the info field in struct interface,
> creating a struct of rip specific interface information (struct
> rip_interface - would be subnet specific), and having a socket per
> subnet?

I'm hearing everywhere that having a socket per subnet is not
a good idea as it doesn't scale. I think the concern is that on
systems with tunnels, the addition of more tunnels can quickly
bring the daemon to its knees, make it run out of resources etc.

--Sowmini

On Fri, 14 Nov 2003, Paul Jakma wrote:

> On Wed, 12 Nov 2003, Krzysztof Oledzki wrote:
>
> > OK. This patch looks very reasonably for me. ;-)
>
> And it fixes your problems?

Yes, Yes :))) But only this one. There are some left..

Best Regards,

Krzysztof Olêdzki

On Fri, 14 Nov 2003 sowmini.varadhan@sun.com wrote:

> I'm hearing everywhere that having a socket per subnet is not a
> good idea as it doesn't scale. I think the concern is that on
> systems with tunnels, the addition of more tunnels can quickly
> bring the daemon to its knees, make it run out of resources etc.

Well, its perhaps not the socket per interface which is the scaling
problem, but the thousands of tunnels.

Either way you cut it, you're going to have a problem with thousands
of interfaces. If you multiplex everything through one socket, then
yes you save the system resources for sockets, however, you will have
other costs, eg: the cost of trying to match received packet to
interface.

Which cost is the lesser one, I dont know, but global socket wont
automatically solve the scaling problems. If socket/interface allows
you to easily relate received packet to interface, then the memory
overhead may be an acceptable tradeoff for reduced run-time costs.

Which is better I dont know.

Also, how many people run routing protocols across thousands of
tunnels? (i know of a case mentioned on 6BONE a long time ago.)
Tunnels in (x)k range tend to be for leaf nodes. (DSL, ipv6 end-site
tunnels, etc.)

> --Sowmini

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
We are all born equal... just some of us are more equal than others.