ifconfig may not connect an interface to known network. It's a very unpleasant problem if you being use QUAGGA e.g. Fix: Patch attached with submission follows: How-To-Repeat: route add 10.0.0.0/24 some.gateway ifconfig IFACE 10.0.0.1/24 alias
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
Responsible Changed From-To: freebsd-net->glebius I'll work on this.
Just for the reference, here is a backtrace that shows how EEXIST is returned: rtrequest1(1,e6560aec,e6560ae0,e6560aec,30,...) at rtrequest1+0x658^M rtinit(c3e21500,1,1) at rtinit+0x193^M in_addprefix(c3e21500,1,e6560b68,0,1,...) at in_addprefix+0xa1^M in_ifinit(c3c4ec00,c3e21500,c3eb6e50,0) at in_ifinit+0x761^M in_control(c3f37bac,8040691a,c3eb6e40,c3c4ec00,c3e9b740) at in_control+0x93e^M ifioctl(c3f37bac,8040691a,c3eb6e40,c3e9b740,0,...) at ifioctl+0x1cf^M soo_ioctl(c3e5a828,8040691a,c3eb6e40,c414e000,c3e9b740) at soo_ioctl+0x2db^M kern_ioctl(c3e9b740,3,8040691a,c3eb6e40) at kern_ioctl+0x296^M ioctl(c3e9b740,e6560d00) at ioctl+0xf1^M syscall(e6560d38) at syscall+0x242^M Xint0x80_syscall() at Xint0x80_syscall+0x20^M The patch proposed vy Vladimir really looks like a hack. It covers only a case when old route was a gateway one. So, even with patch the following won't work: route add 10.0.0.0/24 -iface lo0 ifconfig IFACE 10.0.0.1/24 alias Also, I am afraid of the side effects, when patched kernel will substitute route in a case when it should return error. AFAIK, the problem needs a more generic approach. I see two approaches. 1) Introduce RTM_CHANGEADD, a command that will forcibly add route, deleting all conflicting ones. Use this command in in_addprefix(). 2) In rt_flags field we still have several extra bits. We can use them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX, where XXX is a routing protocol. When issuing RTM_ADD a route with a preferred source (e.g. CONNECTED vs STATIC) will override the old one. freebsd-net subscibers, what do you think? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Gleb Smirnoff wrote: > AFAIK, the problem needs a more generic approach. I see two approaches. > > 1) Introduce RTM_CHANGEADD, a command that will forcibly add route, > deleting all conflicting ones. Use this command in in_addprefix(). > > 2) In rt_flags field we still have several extra bits. We can use > them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX, > where XXX is a routing protocol. When issuing RTM_ADD a route with > a preferred source (e.g. CONNECTED vs STATIC) will override the old > one. > > The proposed changes also constitute a hack. I understand that they are being proposed to address problems we currently have in the stack, i.e. that we do not support multipathing, though it is more than likely they will be blown away in future when the architecture changes (and it has to change). Approach 1 is largely irrelevant if multiple paths are introduced to the network stack; there is then no concept of a conflicting forwarding entry, only preference derived from the interface, entry flags, or the entry ('route') itself. Approach 2 has some merit to it, although the forwarding plane should not care where the forwarding entry came from unless it needs to (e.g. next-hop resolution). It seems reasonable that the forwarding plane should tag entries as being 'CONNECTED' i.e. derived from the address configuration of an interface. I believe many implementations out there do this, and multi-path does not change this. We already have the RTF_PROTO1 flag to determine if the forwarding entry ('route') came from a routing protocol in userland, so there should be no need to change the existing flags. The RTF_STATIC flag only has special meaning in that it means 'the user added this forwarding entry manually via the route(8) command'. We should preserve these semantics, though I believe we should start implementing forwarding preference in the radix trie. I think it seems acceptable and reasonable that we use a limited form of Approach 2 to clobber 'routes' being aded in the case described in the PR, until such time as the network stack is re-engineered to support multiple paths and forwarding preference. I also believe it is useful if we start to use more modern technical jargon to discuss 'routes' in the network stack, because we are actually discussing the behaviour of entries in a forwarding table. Regards, BMS
On Wed, Mar 14, 2007 at 04:00:13PM +0000, Bruce M. Simpson wrote: B> The proposed changes also constitute a hack. B> B> I understand that they are being proposed to address problems we B> currently have in the stack, i.e. that we do not support multipathing, B> though it is more than likely they will be blown away in future when the B> architecture changes (and it has to change). B> B> Approach 1 is largely irrelevant if multiple paths are introduced to the B> network stack; there is then no concept of a conflicting forwarding B> entry, only preference derived from the interface, entry flags, or the B> entry ('route') itself. B> B> Approach 2 has some merit to it, although the forwarding plane should B> not care where the forwarding entry came from unless it needs to (e.g. B> next-hop resolution). B> B> It seems reasonable that the forwarding plane should tag entries as B> being 'CONNECTED' i.e. derived from the address configuration of an B> interface. I believe many implementations out there do this, and B> multi-path does not change this. B> B> We already have the RTF_PROTO1 flag to determine if the forwarding entry B> ('route') came from a routing protocol in userland, so there should be B> no need to change the existing flags. B> B> The RTF_STATIC flag only has special meaning in that it means 'the user B> added this forwarding entry manually via the route(8) command'. We B> should preserve these semantics, though I believe we should start B> implementing forwarding preference in the radix trie. B> B> I think it seems acceptable and reasonable that we use a limited form of B> Approach 2 to clobber 'routes' being aded in the case described in the B> PR, until such time as the network stack is re-engineered to support B> multiple paths and forwarding preference. B> B> I also believe it is useful if we start to use more modern technical B> jargon to discuss 'routes' in the network stack, because we are actually B> discussing the behaviour of entries in a forwarding table. I was afraid that this would raise an argument on multipath routing. Let's temporary do not speak about multipath but just decide what is the correct way to remove conflicting routes when we are assigning an IP prefix to a local interface? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Gleb Smirnoff wrote: > I was afraid that this would raise an argument on multipath routing. Let's > temporary do not speak about multipath but just decide what is the correct > way to remove conflicting routes when we are assigning an IP prefix to a > local interface? > My suggestion is to take the second approach you outlined but modify it slightly. That way, the conflict between the 'connected' FTE introduced by ifconfig'ing the interface and the pre-existing FTE for that network prefix, may be resolved in a manner which doesn't break current consumers of the routing code, and leaves the way open to do multipath later w/o problems. Regards, BMS
Gleb Smirnoff wrote: > > I was afraid that this would raise an argument on multipath routing. Let's > temporary do not speak about multipath but just decide what is the correct > way to remove conflicting routes when we are assigning an IP prefix to a > local interface? IMO when configuring a interface with an IP address and network it should kick out previous host and/or network routes matching it. Unless those are from locally configured interfaces, then it should reject the new attempt. The current behavior is a big problem when running routing daemons like OpenBGPD or OpenOSPFD. If you add a second router to a subnet and that router receives that subnet already via the routing protocol you can't configure the interface. For the routing daemon a RTM_CHANGE in the replacement case is fine. -- Andre
Responsible Changed From-To: glebius->melifaro Alexander is fixing this.
State Changed From-To: open->patched Fixed in r248070.