Qing Li wrote:
qingli 2008-04-13 05:45:14 UTC
FreeBSD src repository
Modified files:
sys/conf files options
sys/net radix.c radix.h route.c route.h rtsock.c
sys/netinet in_proto.c ip_output.c
sys/netinet6 in6_proto.c in6_src.c nd6_nbr.c
Log:
This patch provides the back end support for equal-cost multi-path
(ECMP) for both IPv4 and IPv6. Previously, multipath route insertion
Nice! Long overdue that we get this functionality. :-)
Do you do hash-based next-hop balancing ("flow"-aware) or packet
based round robin? Should it be made an option to switch between them
(globally) like on Cisco routers?
is disallowed. For example,
route add -net 192.103.54.0/24 10.9.44.1
route add -net 192.103.54.0/24 10.9.44.2
The second route insertion will trigger an error message of
"add net 192.103.54.0/24: gateway 10.2.5.2: route already in table"
Would it make sense to retain this behavior by default (POLA) and have
multi-path being enabled via sysctl like packet forwarding in general?
Just adding the same route twice with different next-hops can lead to
very confusing situations for the users which are not used to multi-path.
Multiple default routes can also be inserted. Here is the netstat
output:
default 10.2.5.1 UGS 0 3074 bge0 =>
default 10.2.5.2 UGS 0 0 bge0
When multipath routes exist, the "route delete" command requires
a specific gateway to be specified or else an error message would
be displayed. For example,
route delete default
would fail and trigger the following error message:
"route: writing to routing socket: No such process"
"delete net default: not in table"
Can this be made more descriptive? This messages are about as confusing
and non-descript as possible. Not being aware of the multipath functionality
I would pull out my last hair try to get rid of a route.
On the other hand,
route delete default 10.2.5.2
would be successful: "delete net default: gateway 10.2.5.2"
One does not have to specify a gateway if there is only a single
route for a particular destination.
I need to perform more testings on address aliases and multiple
interfaces that have the same IP prefixes. This patch as it
stands today is not yet ready for prime time. Therefore, the ECMP
code fragments are fully guarded by the RADIX_MPATH macro.
Include the "options RADIX_MPATH" in the kernel configuration
to enable this feature.
How does this behave with common routing daemons; Quagga/Zebra, OpenBGPD,
OpenOSPFD? Do they have to be aware of the multipath functionality? Will
it confuse them?
What about the other big missing piece; new-arp? ;-) Something for BSDCan?
--
Andre
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
