Mailing List Archive: RFC: CONNECTED/INTERFACE

RFC: CONNECTED/INTERFACE - "C(i)" routes in ripd

Dec 25, 2003, 4:55 PM

Post #1 of 3 (624 views)

Hello,

I'm trying to find the reason of storing CONNECTED/INTERFACE routes (ones
with type==ZEBRA_ROUTE_CONNECT and sub_type==RIP_ROUTE_INTERFACE) in ripd
routes database (this one from "show ip rip"). It seems ripd reads IP
addresses from interfaces and adds such routes (possible multiple times!)
even with "redistribute connected" disabled. When "redistribute connected"
is enabled such routes are replace by CONNECTED routes received from zebra
- they are strored as "CONNECTED/REDISTRIBUTE". Both problems are not a
very important in current ripd code which can only keep one route per
destination, but like I have already mentioned before, for obvious reasons
I have worked with the code to change this. Those CONNECTED/INTERFACE
routes seems to me to be quite useless - they are not announced to rip
neighbors and I'm not able to find code which needs them to work properly.
I was thinking if we can remove then completly but maybe I forget about
something important?

Any comments on this?

Best regards,

Krzysztof Oledzki

Re: RFC: CONNECTED/INTERFACE - "C(i)" routes in ripd [ In reply to ]

Vincent.Jardin at 6WIND

Dec 29, 2003, 3:12 AM

Post #2 of 3 (610 views)

Permalink

When the following configuration is used:

interface ip0:
1.2.3.4/24
2.3.4.5/24

interface jp0:
3.4.5.6/24

router rip
network 1.2.0.0/16
redistribute connected

The RIP dstabase is:
1.2.3.0/24 is C(i)
2.3.4.0/24 is C(r)
3.4.5.0/24 is C(r)
The 3 routes are announced on ip0, but they are not announced via jp0

If the configuration is :
router rip
network ip0
redistribute connected

The RIP database becomes:
1.2.3.0/24 is C(i)
2.3.4.0/24 is C(i)
3.4.5.0/24 is C(r)

Does it help ?

Regards,
Vincent

Krzysztof Oledzki wrote:

>Hello,
>
>I'm trying to find the reason of storing CONNECTED/INTERFACE routes (ones
>with type==ZEBRA_ROUTE_CONNECT and sub_type==RIP_ROUTE_INTERFACE) in ripd
>routes database (this one from "show ip rip"). It seems ripd reads IP
>addresses from interfaces and adds such routes (possible multiple times!)
>even with "redistribute connected" disabled. When "redistribute connected"
>is enabled such routes are replace by CONNECTED routes received from zebra
>- they are strored as "CONNECTED/REDISTRIBUTE". Both problems are not a
>very important in current ripd code which can only keep one route per
>destination, but like I have already mentioned before, for obvious reasons
>I have worked with the code to change this. Those CONNECTED/INTERFACE
>routes seems to me to be quite useless - they are not announced to rip
>neighbors and I'm not able to find code which needs them to work properly.
>I was thinking if we can remove then completly but maybe I forget about
>something important?
>
>Any comments on this?
>
>Best regards,
>
> Krzysztof Oledzki
>_______________________________________________
>Quagga-dev mailing list
>Quagga-dev@lists.quagga.net
>http://lists.quagga.net/mailman/listinfo/quagga-dev
>
>

Re: RFC: CONNECTED/INTERFACE - "C(i)" routes in ripd [ In reply to ]

oleq at ans

Dec 29, 2003, 8:10 AM

Post #3 of 3 (603 views)

Permalink

On Mon, 29 Dec 2003, Vincent Jardin wrote:

> When the following configuration is used:
>
> interface ip0:
> 1.2.3.4/24
> 2.3.4.5/24
>
> interface jp0:
> 3.4.5.6/24
>
> router rip
> network 1.2.0.0/16
> redistribute connected
>
> The RIP dstabase is:
> 1.2.3.0/24 is C(i)
> 2.3.4.0/24 is C(r)
> 3.4.5.0/24 is C(r)
> The 3 routes are announced on ip0, but they are not announced via jp0

OK. Since "network 1.2.0.0/16" matches '1.2.3.4/24' and '2.3.4.5/24' it is
normall that routes are only announced via jp0. But AFAIK without
"redistribute connected" ripd is expected not to announced such routes.

> If the configuration is :
> router rip
> network ip0
> redistribute connected
>
> The RIP database becomes:
> 1.2.3.0/24 is C(i)
> 2.3.4.0/24 is C(i)
> 3.4.5.0/24 is C(r)
>
> Does it help ?
Yes.. No :) Hm :) Hm :) So we can see what the code does. But as far as
I understand RIP this should not happend. Please, correct me if I'm wrong.

Best regards,

Krzysztof Oledzki