[quagga-dev 7208] Re: [PATCH 01/17] zebra: Initial RIB cleanup, and eliminate lots of redundant IPv4/IPv6 code.

Joakim Tjernlund joakim.tjernlund at transmode.se
Thu Aug 20 16:58:38 BST 2009


paul at jakma.org wrote on 20/08/2009 17:20:33:
> Subject:
>
> Re: [quagga-dev 7205] Re: [PATCH 01/17] zebra: Initial RIB cleanup, and
> eliminate lots of redundant IPv4/IPv6 code.
>
> On Thu, 20 Aug 2009, Joakim Tjernlund wrote:
>
> >>> If I understand this correctly I would send
> >>>    * +-+-+-+-+-+-+-+-+-+-+-+-+-
> >>>    * |  ZEBRA_NEXTHOP_IFINDEX |
> >>>    * +-+-+-+-+-+-+-+-+-+
> >>>    * |      3          |
> >>>    * +-+-+-+-+-+-+-+-+-+
> >>>    * +-+-+-+-+-+-+-+-+-+-+-+
> >>>    * |  ZEBRA_NEXTHOP_IPV4 |
> >>>    * +-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>    * |      192.168.1.1        |
> >>>    * +-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >>> and this would be the same as ZEBRA_NEXTHOP_IPV4_IFINDEX?
>
> > here you would need ZEBRA_NEXTHOP_IPV4_IFINDEX if you want to add one
> > nexthop with both address and ifindex.
>
> Ok, you want the ability to pin a gateway to a specific interface,
> for a certain route (which implies - not per se for other
> destinations).
>
> Ie if a route consists of:
>
>     destination via nexthops: <nexthop 1>, ..., <nexthop N>
>
> meaning a packet to destination may go via <nexthop 1> OR ...
> OR <nexthop N>. Then you want the ability to say that a nexthop
> consists of:
>
>     <address>
>     <interface>
>     <address, interface>
>
> Where the last one means a restriction "address AND interface".

Exactly. In OSPF a nexthop is always an interface + optional
nexthop IP address. Would be good if you could express this too
when needed.

>
> I.e. if you have prefix P, and address A and interface I, then:
>
>     P via <A,I>
>
> should mean that a packet for P must be sent to A but only ever on I.
>
> Have I got that right?

Yes.

>
> Also, A must be on a multi-access link, otherwise you could just say
> <I>.

How about IP aliases on a link? There interface isn't enough.

>
> If I understand right, this would primarily be useful with
> multi-homed machines, that have multiple interfaces to the same
> subnet. Then questions I would have would be, if I understand the
> motivation correctly:
>
> why not solve this with recursion?
>
> I.e. why not have the OSPF route be just <A> and then have an
> underlying connected-subnet route control which interfaces are valid
> output interfaces for A.
>
> I.e. why must this be done on a per-destination basis?

Possibly, but how to know that this fits all uses? Why
should not the user have a choice? Perhaps the user
just don't want to bother with recursive routes, just turn
on OSPF and it should work, right?

>
> > me first :)
>
> Trying to untangle your interface/area patch at the moment. ;)

:), then you get it the way you want, thanks.
How about the more controversial stuff: nexthop_calculation()?

>
> Feel free to post any other zebra patches.

Not sure I got any more, have to check




More information about the Quagga-dev mailing list