Source address selection + multicast
From: Pierre Ynard <hidden>
Date: 2006-11-06 10:57:57
Hello,
Preferred source address selection in the routing table ("src" field)
currently does not work properly with multicast destination adresses:
it leads packets to be routed through the wrong network device (see
http://bugzilla.kernel.org/show_bug.cgi?id=7398).
It seems to me that the main reason for this is compatibility with
old multicast applications, and I can see no fundamental reason
preventing the use of this two features together.
Why not finding a way to let them coexist?
What about a sysctl option, letting users who really want to disable
the compatibility hack, and restore normal behavior? I am thinking
about something like the patch below. Or does another simple way to
do it come to your mind?
What do you think about it?
diff -urNp linux-2.6.18/Documentation/filesystems/proc.txt linux-2.6.18/Documentation/filesystems/proc.txt--- linux-2.6.18/Documentation/filesystems/proc.txt 2006-09-19 20:42:06.000000000 -0700
+++ linux-2.6.18/Documentation/filesystems/proc.txt 2006-10-26 05:13:15.000000000 -0700@@ -1758,6 +1758,15 @@ max_delay, min_delay Delays for flushing the routing cache. +mc_src_strict +------------- + +There is a hack in the kernel router which provides compatibility for old +multicast applications such as vic, vat and friends. Unfortunately, this +hack also breaks normal behavior of preferred source address selection +(iproute2 "src" field) with multicast and limited broadcast. Enabling this +option disables this hack and restores normal (strict) behavior. + redirect_load, redirect_number ------------------------------
diff -urNp linux-2.6.18/include/linux/sysctl.h linux-2.6.18/include/linux/sysctl.h
--- linux-2.6.18/include/linux/sysctl.h 2006-09-19 20:42:06.000000000 -0700
+++ linux-2.6.18/include/linux/sysctl.h 2006-10-26 04:25:00.000000000 -0700@@ -433,6 +433,7 @@ enum { NET_IPV4_ROUTE_MIN_ADVMSS=17, NET_IPV4_ROUTE_SECRET_INTERVAL=18, NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS=19, + NET_IPV4_ROUTE_MC_SRC_STRICT=20, }; enum
diff -urNp linux-2.6.18/net/ipv4/route.c linux-2.6.18/net/ipv4/route.c
--- linux-2.6.18/net/ipv4/route.c 2006-09-19 20:42:06.000000000 -0700
+++ linux-2.6.18/net/ipv4/route.c 2006-10-26 05:11:00.000000000 -0700@@ -132,6 +132,7 @@ static int ip_rt_mtu_expires = 10 * 60 static int ip_rt_min_pmtu = 512 + 20 + 20; static int ip_rt_min_advmss = 256; static int ip_rt_secret_interval = 10 * 60 * HZ; +static int ip_rt_mc_src_strict = 0; static unsigned long rt_deadline; #define RTprint(a...) printk(KERN_DEBUG a)
@@ -2416,7 +2417,7 @@ static int ip_route_output_slow(struct r of another iface. --ANK */ - if (oldflp->oif == 0 + if (!ip_rt_mc_src_strict && oldflp->oif == 0 && (MULTICAST(oldflp->fl4_dst) || oldflp->fl4_dst == 0xFFFFFFFF)) { /* Special hack: user can direct multicasts and limited broadcast via necessary interface
@@ -2431,6 +2432,12 @@ static int ip_route_output_slow(struct r cannot know, that ttl is zero, so that packet will not leave this host and route is valid). Luckily, this hack is good workaround. + + Unfortunately, it also breaks normal behavior of + source address preference, so I added a sysctl option + to let the user disable this hack and restore normal + behavior. By default, the hack is still enabled (old + compatibility behavior). -- PY */ fl.oif = dev_out->ifindex;
@@ -3057,6 +3064,15 @@ ctl_table ipv4_route_table[] = { .proc_handler = &proc_dointvec_jiffies, .strategy = &sysctl_jiffies, }, + { + .ctl_name = NET_IPV4_ROUTE_MC_SRC_STRICT, + .procname = "mc_src_strict", + .data = &ip_rt_mc_src_strict, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &ipv4_doint_and_flush, + .strategy = &ipv4_doint_and_flush_strategy, + }, { .ctl_name = 0 } }; #endif
--
Pierre Ynard
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com