[quagga-dev 8948] multipath route redistribution messages

Brett Ciphery brett.ciphery at windriver.com
Mon Nov 14 00:48:24 GMT 2011


Hi,

I'm looking at creating a "dummy" zebra client to listen for all route
redistribution messages.  For those curious, I'm taking this approach
versus netlink so that I have more info about the route (protocol it
came from etc from rib structure).

I noticed when it was finished that zebra server was not sending the
additional nexthops for multipath routes, e.g. zsend_route_multipath()
sent an event just for the first hop and then exited.  zebra log:

2011/11/10 15:55:39 ZEBRA: netlink_route_multipath() (multihop):
RTM_NEWROUTE 192.168.23.0/24, type IPv4 nexthop
2011/11/10 15:55:39 ZEBRA: netlink_route_multipath() (multihop): nexthop
via 192.168.22.2 if 3
2011/11/10 15:55:39 ZEBRA: netlink_route_multipath() (multihop):
RTM_NEWROUTE 192.168.23.0/24, type IPv4 nexthop
2011/11/10 15:55:39 ZEBRA: netlink_route_multipath() (multihop): nexthop
via 192.168.25.2 if 4
2011/11/10 15:55:39 ZEBRA: netlink_talk: netlink-cmd type
RTM_NEWROUTE(24), seq=31
2011/11/10 15:55:39 ZEBRA: netlink_parse_info: netlink-cmd ACK:
type=RTM_NEWROUTE(24), seq=31, pid=0

In this case, just the 192.168.22.2 nexthop info is sent.  Looking
through the git log this commit seemed of interest:

commit 1dcb51729b4a8bd7ed21126c7e5e61bc096f8674
Author: paul <paul>
Date:   Tue May 31 08:38:50 2005 +0000

    2005-05-31 Paul Jakma <paul.jakma at sun.com>

        * zserv.c: (zsend_route_multipath) Fix bug if route is sent
          with no NEXTHOP_FLAG_FIB nexthops. As ZAPI_MESSAGE_IFINDEX
          and ZAPI_MESSAGE_NEXTHOP are always set, clients would try
          read non-existent nexthop information and hit stream assert.
          Zserv is still broken for multi-nexthop messages, but it
always was.

Was the multi-nexthop message never implemented because there was no
real need or is there some gating problem that might break other
clients?

Regards,
Brett



More information about the Quagga-dev mailing list