IPv6: autoconfiguration and suspend/resume or link down/up

IPv6: autoconfiguration and suspend/resume or link down/up

[Jiri Bohac]

Hi,

I came over a surprising behaviour with IPv6 autoconfiguration,
which I think is a bug, but I would first like to hear other
people's opinions before trying to fix this:

Problem 1: all the address/route lifetimes are kept in jiffies
and jiffies don't get incremented on resume. So when a
route/address lifetime is 30 minutes and the system resumes after
1 hour, the route/address should be considered expired, but it is
not.

Problem 2: when a system is moved to a new network a RS is not
sent. Thus, IPv6 does not autoconfigure until the router sends a
periodic RA. This can occur both while the system is alive and
while it is suspended. I think the autoconfigured state should be
discarded when the kernel suspects the system could have been
moved to a different network.

When the cable is unplugged and plugged in again, we already get
notified through linkwatch -> netdev_state_change ->
  -> call_netdevice_notifiers(NETDEV_CHANGE, ...)
However, if the device has already been autoconfigured,
addrconf_notify() only handles this event by printing a
message.

So my idea was to:
- handle link up/down in addrconf_notify() similarly to
  NETDEV_UP/NETDEV_DOWN

- on suspend, faking a link down event; on resume, faking a link up event
  (or better, having a special event type for suspend/resume)

This would cause autoconfiguration to be restarted on resume as
well as cable plug/unplug, solving both the above problems.

Or do we want to completely rely on userspace tools
(networkmanager/ifplug) and expect them to do NETDEV_DOWN on
unplug/suspend and NETDEV_UP on plug/resume?

Any thoughts?

-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Stephen Hemminger]

On Tue, 19 Jul 2011 20:02:53 +0200
Jiri Bohac <jbohac@suse.cz> wrote:

> Hi,
> 
> I came over a surprising behaviour with IPv6 autoconfiguration,
> which I think is a bug, but I would first like to hear other
> people's opinions before trying to fix this:
> 
> Problem 1: all the address/route lifetimes are kept in jiffies
> and jiffies don't get incremented on resume. So when a
> route/address lifetime is 30 minutes and the system resumes after
> 1 hour, the route/address should be considered expired, but it is
> not.
> 
> Problem 2: when a system is moved to a new network a RS is not
> sent. Thus, IPv6 does not autoconfigure until the router sends a
> periodic RA. This can occur both while the system is alive and
> while it is suspended. I think the autoconfigured state should be
> discarded when the kernel suspects the system could have been
> moved to a different network.
> 
> When the cable is unplugged and plugged in again, we already get
> notified through linkwatch -> netdev_state_change ->
>   -> call_netdevice_notifiers(NETDEV_CHANGE, ...)
> However, if the device has already been autoconfigured,
> addrconf_notify() only handles this event by printing a
> message.
> 
> So my idea was to:
> - handle link up/down in addrconf_notify() similarly to
>   NETDEV_UP/NETDEV_DOWN
> 
> - on suspend, faking a link down event; on resume, faking a link up event
>   (or better, having a special event type for suspend/resume)
> 
> This would cause autoconfiguration to be restarted on resume as
> well as cable plug/unplug, solving both the above problems.
> 
> Or do we want to completely rely on userspace tools
> (networkmanager/ifplug) and expect them to do NETDEV_DOWN on
> unplug/suspend and NETDEV_UP on plug/resume?
> 
> Any thoughts?

What hardware?

I think the normal solution is to have the device drop the link
during it's suspend and then attempt to renegotiate it on resume.
This is needed for wired (autonegotiation) and wireless already.
There maybe old drivers that don't do this. That is probably why
Ubuntu and other distro's used to rmmod the drivers during suspend.

If the driver drops the link during suspend then the necessary link
events happen to keep bridging, ipv6, bonding and all the other possible
network protocols happy.

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Jiri Bohac]

On Wed, Jul 20, 2011 at 09:15:56AM -0700, Stephen Hemminger wrote:
> > When the cable is unplugged and plugged in again, we already get
> > notified through linkwatch -> netdev_state_change ->
> >   -> call_netdevice_notifiers(NETDEV_CHANGE, ...)
> > However, if the device has already been autoconfigured,
> > addrconf_notify() only handles this event by printing a
> > message.

...

> If the driver drops the link during suspend then the necessary link
> events happen to keep bridging, ipv6, bonding and all the other possible
> network protocols happy.

OK, so maybe providing the link event on suspend/resume should be
left to the drivers.

The main problem persists: IPv6 currently does nothing when the link goes
down and returns. Shouldn't the kernel anticipate that the new
network could be different, forget all the autoconfigured
parameters and restart the autoconfiguration?

-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Dan Williams]

On Tue, 2011-07-19 at 20:02 +0200, Jiri Bohac wrote:
> Hi,
> 
> I came over a surprising behaviour with IPv6 autoconfiguration,
> which I think is a bug, but I would first like to hear other
> people's opinions before trying to fix this:
> 
> Problem 1: all the address/route lifetimes are kept in jiffies
> and jiffies don't get incremented on resume. So when a
> route/address lifetime is 30 minutes and the system resumes after
> 1 hour, the route/address should be considered expired, but it is
> not.
> 
> Problem 2: when a system is moved to a new network a RS is not
> sent. Thus, IPv6 does not autoconfigure until the router sends a
> periodic RA. This can occur both while the system is alive and
> while it is suspended. I think the autoconfigured state should be
> discarded when the kernel suspects the system could have been
> moved to a different network.
> 
> When the cable is unplugged and plugged in again, we already get
> notified through linkwatch -> netdev_state_change ->
>   -> call_netdevice_notifiers(NETDEV_CHANGE, ...)
> However, if the device has already been autoconfigured,
> addrconf_notify() only handles this event by printing a
> message.
> 
> So my idea was to:
> - handle link up/down in addrconf_notify() similarly to
>   NETDEV_UP/NETDEV_DOWN
> 
> - on suspend, faking a link down event; on resume, faking a link up event
>   (or better, having a special event type for suspend/resume)
> 
> This would cause autoconfiguration to be restarted on resume as
> well as cable plug/unplug, solving both the above problems.

Faking a link event seems like a hack.  We had this problem with the
wifi stack a while ago where the current AP list wasn't expired on
wakeup so it still looked like the APs that were there when you went to
sleep were there when you resumed even if you'd moved 100 miles.  What
we did there was save the current time (using get_seconds()) when
suspending, and in the resume handler use that value to age anything
that needs to know about time spent in suspend, and then do what needs
to be done with that.  So something like that may work for IPv6
addrconf; on suspend save current time, and on resume check the current
time, subtract the time you saved on suspend, and magically add that to
the lifetime counts and then run any expiry stuff.

Dan

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Jiri Bohac]

On Wed, Jul 20, 2011 at 11:21:43AM -0500, Dan Williams wrote:
> ... and in the resume handler use that value to age anything
> that needs to know about time spent in suspend, and then do what needs
> to be done with that.  So something like that may work for IPv6
> addrconf; on suspend save current time, and on resume check the current
> time, subtract the time you saved on suspend, and magically add that to
> the lifetime counts and then run any expiry stuff.

IPv6 (by specification) does not send any RS when an IP address
or route expires. So only subtracting the supend time from the
lifetimes and possibly expiring the routes/IP addresses won't fix
the problem.

When I move to a new network, I need to restart the
autoconfiguration. This does not currently happen - neither for
an alive system where the ethernet link goes down/up, nor for a
system that gets suspended, moved and then resumed.

-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Dan Williams]

On Wed, 2011-07-20 at 18:36 +0200, Jiri Bohac wrote:
> On Wed, Jul 20, 2011 at 11:21:43AM -0500, Dan Williams wrote:
> > ... and in the resume handler use that value to age anything
> > that needs to know about time spent in suspend, and then do what needs
> > to be done with that.  So something like that may work for IPv6
> > addrconf; on suspend save current time, and on resume check the current
> > time, subtract the time you saved on suspend, and magically add that to
> > the lifetime counts and then run any expiry stuff.
> 
> IPv6 (by specification) does not send any RS when an IP address
> or route expires. So only subtracting the supend time from the
> lifetimes and possibly expiring the routes/IP addresses won't fix
> the problem.

Well, the prefix option of the RA includes the Valid Lifetime (in
seconds, no less) so I'd assume the kernel starts a timer when it
receives the RA and updates any addresses configured as a result of
receiving that RA+prefix, such that when the timer expires, the
autoconfigured address is deleted.  That timer can be used as a base for
the expiry mechanism that I've noted above, no?  This fixes problem #1
from your first mail.

For problem #2, shouldn't a new RS be sent whenever the interface
changes it's IFF_LOWER_UP bit?  IFF_LOWER_UP indicates a carrier on/off
event and thus indicates possible disconnect/reconnect to a new network.
I don't specifically know how it works now, but if RS isn't triggered
from IFF_LOWER_UP, I'd imagine that either (a) something didn't get
updated when IFF_LOWER_UP became how carrier was indicated in 2.6.17
(commit b00055aacdb172c05067612278ba27265fcd05ce) or (b) there's a
reason IFF_LOWER_UP isn't used as the trigger for sending an RS and I'm
qualified to say why.

Dan

> When I move to a new network, I need to restart the
> autoconfiguration. This does not currently happen - neither for
> an alive system where the ethernet link goes down/up, nor for a
> system that gets suspended, moved and then resumed.
> 

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Dan Williams]

On Thu, 2011-07-21 at 00:30 -0500, Dan Williams wrote:
> On Wed, 2011-07-20 at 18:36 +0200, Jiri Bohac wrote:
> > On Wed, Jul 20, 2011 at 11:21:43AM -0500, Dan Williams wrote:
> > > ... and in the resume handler use that value to age anything
> > > that needs to know about time spent in suspend, and then do what needs
> > > to be done with that.  So something like that may work for IPv6
> > > addrconf; on suspend save current time, and on resume check the current
> > > time, subtract the time you saved on suspend, and magically add that to
> > > the lifetime counts and then run any expiry stuff.
> > 
> > IPv6 (by specification) does not send any RS when an IP address
> > or route expires. So only subtracting the supend time from the
> > lifetimes and possibly expiring the routes/IP addresses won't fix
> > the problem.
> 
> Well, the prefix option of the RA includes the Valid Lifetime (in
> seconds, no less) so I'd assume the kernel starts a timer when it
> receives the RA and updates any addresses configured as a result of
> receiving that RA+prefix, such that when the timer expires, the
> autoconfigured address is deleted.  That timer can be used as a base for
> the expiry mechanism that I've noted above, no?  This fixes problem #1
> from your first mail.
> 
> For problem #2, shouldn't a new RS be sent whenever the interface
> changes it's IFF_LOWER_UP bit?  IFF_LOWER_UP indicates a carrier on/off
> event and thus indicates possible disconnect/reconnect to a new network.
> I don't specifically know how it works now, but if RS isn't triggered
> from IFF_LOWER_UP, I'd imagine that either (a) something didn't get
> updated when IFF_LOWER_UP became how carrier was indicated in 2.6.17
> (commit b00055aacdb172c05067612278ba27265fcd05ce) or (b) there's a
> reason IFF_LOWER_UP isn't used as the trigger for sending an RS and I'm
> qualified to say why.

Should be "I'm not qualified to say why".

> Dan
> 
> > When I move to a new network, I need to restart the
> > autoconfiguration. This does not currently happen - neither for
> > an alive system where the ethernet link goes down/up, nor for a
> > system that gets suspended, moved and then resumed.
> > 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Stephen Hemminger]

On Thu, 21 Jul 2011 11:35:37 -0500
Dan Williams <dcbw@redhat.com> wrote:

> > For problem #2, shouldn't a new RS be sent whenever the interface
> > changes it's IFF_LOWER_UP bit?  IFF_LOWER_UP indicates a carrier on/off
> > event and thus indicates possible disconnect/reconnect to a new network.
> > I don't specifically know how it works now, but if RS isn't triggered
> > from IFF_LOWER_UP, I'd imagine that either (a) something didn't get
> > updated when IFF_LOWER_UP became how carrier was indicated in 2.6.17
> > (commit b00055aacdb172c05067612278ba27265fcd05ce) or (b) there's a
> > reason IFF_LOWER_UP isn'

IFF_RUNING is used to indicate carrier, IFF_LOWER_UP is for layered
devices like vlan's but is rarely used.

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[David Miller]

From: Jiri Bohac <jbohac@suse.cz>
Date: Tue, 19 Jul 2011 20:02:53 +0200

> When the cable is unplugged and plugged in again, we already get
> notified through linkwatch -> netdev_state_change ->
>   -> call_netdevice_notifiers(NETDEV_CHANGE, ...)
> However, if the device has already been autoconfigured,
> addrconf_notify() only handles this event by printing a
> message.
> 
> So my idea was to:
> - handle link up/down in addrconf_notify() similarly to
>   NETDEV_UP/NETDEV_DOWN
> 
> - on suspend, faking a link down event; on resume, faking a link up event
>   (or better, having a special event type for suspend/resume)
> 
> This would cause autoconfiguration to be restarted on resume as
> well as cable plug/unplug, solving both the above problems.
> 
> Or do we want to completely rely on userspace tools
> (networkmanager/ifplug) and expect them to do NETDEV_DOWN on
> unplug/suspend and NETDEV_UP on plug/resume?
> 
> Any thoughts?

This is an oft-reocurring discussion, what to do on link up/down
events wrt. all sorts of autoconfiguration.

My gut instinct is that on any link state change (physical link down,
suspend) we should be prepared to renegotiate everything and anything
since as you state we could be on a different physical network.

Suspend is even more important because while we were suspended we
could be on the same network but the routers present and available
might have changed completely.

In userspace I've noticed that we've grown an ecosystem of stupid
tools and facilities, none (or very few) of which monitor link status
in order to do handle things intelligently.  DHCP servers are a great
example.  DHCP servers spit out broadcast discover packets before we
even have a link up.

Filling this void is NetworkManager, which does listen on a netlink
socket for device state changes, hotplug, etc.  And in response it
explicitly tells various facilities to reprobe the network.

This is why I'm reluctant to give NetworkManager a hard time, because
whilst it's a huge beast, it is at least trying to do the right thing.
:-)

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Herbert Xu]

On Fri, Jul 22, 2011 at 01:06:28AM -0700, David Miller wrote:
> 
> Suspend is even more important because while we were suspended we
> could be on the same network but the routers present and available
> might have changed completely.

Unfortunately virtual machine live migration also uses the suspend
& resume mechanism.  In that case we don't wish to renegotiate
everything, since the goal is to minimise the outage window.

This would suggest that putting the policy in user-space may be the
best option.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Nicolas de Pesloüan]

Le 22/07/2011 11:21, Herbert Xu a écrit :
> On Fri, Jul 22, 2011 at 01:06:28AM -0700, David Miller wrote:
>>
>> Suspend is even more important because while we were suspended we
>> could be on the same network but the routers present and available
>> might have changed completely.
>
> Unfortunately virtual machine live migration also uses the suspend
> &  resume mechanism.  In that case we don't wish to renegotiate
> everything, since the goal is to minimise the outage window.
>
> This would suggest that putting the policy in user-space may be the
> best option.

For the particular situation where we use suspend/resume to migrate a virtual machine, we might have 
a kernel parameter or sysfs entry that instruct the kernel not to renegotiate anything on resume.

That being said, the time to renegotiate a network setup sounds very short, compared to the time for 
a full suspend-migrate-resume cycle. I'm not sure VM migration would really suffer from such 
renegotiation.

And because the local network may change while we migrate the VM (in particular if the migration 
happens because of some failover), I think we should enforce renegotiation on resume anyway.

	Nicolas.

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Herbert Xu]

On Sat, Jul 23, 2011 at 04:31:21PM +0200, Nicolas de Pesloüan wrote:
>
> That being said, the time to renegotiate a network setup sounds very 
> short, compared to the time for a full suspend-migrate-resume cycle. I'm 
> not sure VM migration would really suffer from such renegotiation.

Live migration certainly would suffer from multiple RTTs that
result from renegotiation.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Stephen Hemminger]

On Sat, 23 Jul 2011 23:27:24 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Sat, Jul 23, 2011 at 04:31:21PM +0200, Nicolas de Pesloüan wrote:
> >
> > That being said, the time to renegotiate a network setup sounds very 
> > short, compared to the time for a full suspend-migrate-resume cycle. I'm 
> > not sure VM migration would really suffer from such renegotiation.
> 
> Live migration certainly would suffer from multiple RTTs that
> result from renegotiation.
> 
> Cheers,

Would it be possible to do live migration without dropping carrier
or setting interface down?

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Herbert Xu]

On Sat, Jul 23, 2011 at 09:37:43AM -0700, Stephen Hemminger wrote:
>
> Would it be possible to do live migration without dropping carrier
> or setting interface down?

I think LM uses the same mechanism as suspend and resume so whatever
happens in one case will happen in the other case as well.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Nicolas de Pesloüan]

Le 24/07/2011 02:18, Herbert Xu a écrit :
> On Sat, Jul 23, 2011 at 09:37:43AM -0700, Stephen Hemminger wrote:
>>
>> Would it be possible to do live migration without dropping carrier
>> or setting interface down?
>
> I think LM uses the same mechanism as suspend and resume so whatever
> happens in one case will happen in the other case as well.

So we need to distinguish between two kind of link events:

1/ Really having the link goes down then up. This should trigger a renegotiation.

2/ Having the system suspend then resume :
2a/ This should trigger link down/link up events to force a renegotiation, for normal suspend/resume 
where the network might have changed between suspend and resume.
2/ This should *not* trigger link down/link up events to avoid a renegotiation (for live migration) 
because it is assumed that the network didn't change while suspended.

Can't we allow the user to set a global "link-down-link-up-timeout" and only force a renegotiation 
if the time between link down and link up events is longer than this timeout? Normal user would set 
this timeout close to 0 (default value). Live migration user would set this timeout to about twice 
the time it normally takes to do a live migration. That way, in a VM environment, if the 
suspend/resume cycle happens to take far more than a normal live migration time, the kernel would 
renegotiate, which sounds reasonable, from my point of view.

Does this make sense?

	Nicolas.

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Stephen Hemminger]

On Sun, 24 Jul 2011 10:35:58 +0200
Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:

> Le 24/07/2011 02:18, Herbert Xu a écrit :
> > On Sat, Jul 23, 2011 at 09:37:43AM -0700, Stephen Hemminger wrote:
> >>
> >> Would it be possible to do live migration without dropping carrier
> >> or setting interface down?
> >
> > I think LM uses the same mechanism as suspend and resume so whatever
> > happens in one case will happen in the other case as well.
> 
> So we need to distinguish between two kind of link events:
> 
> 1/ Really having the link goes down then up. This should trigger a renegotiation.
> 
> 2/ Having the system suspend then resume :
> 2a/ This should trigger link down/link up events to force a renegotiation, for normal suspend/resume 
> where the network might have changed between suspend and resume.
> 2/ This should *not* trigger link down/link up events to avoid a renegotiation (for live migration) 
> because it is assumed that the network didn't change while suspended.
> 
> Can't we allow the user to set a global "link-down-link-up-timeout" and only force a renegotiation 
> if the time between link down and link up events is longer than this timeout? Normal user would set 
> this timeout close to 0 (default value). Live migration user would set this timeout to about twice 
> the time it normally takes to do a live migration. That way, in a VM environment, if the 
> suspend/resume cycle happens to take far more than a normal live migration time, the kernel would 
> renegotiate, which sounds reasonable, from my point of view.

I hate building infrastructure where it is not needed.

Since virtual machines should be using virtio network devices, shouldn't
the suspend/resume in that device just work. It doesn't need to drop the link.

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Herbert Xu]

On Sun, Jul 24, 2011 at 08:26:20PM -0700, Stephen Hemminger wrote:
>
> Since virtual machines should be using virtio network devices, shouldn't
> the suspend/resume in that device just work. It doesn't need to drop the link.

The VM may also be using SRIOV.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Dan Williams]

On Fri, 2011-07-22 at 01:06 -0700, David Miller wrote:
> From: Jiri Bohac <jbohac@suse.cz>
> Date: Tue, 19 Jul 2011 20:02:53 +0200
> 
> > When the cable is unplugged and plugged in again, we already get
> > notified through linkwatch -> netdev_state_change ->
> >   -> call_netdevice_notifiers(NETDEV_CHANGE, ...)
> > However, if the device has already been autoconfigured,
> > addrconf_notify() only handles this event by printing a
> > message.
> > 
> > So my idea was to:
> > - handle link up/down in addrconf_notify() similarly to
> >   NETDEV_UP/NETDEV_DOWN
> > 
> > - on suspend, faking a link down event; on resume, faking a link up event
> >   (or better, having a special event type for suspend/resume)
> > 
> > This would cause autoconfiguration to be restarted on resume as
> > well as cable plug/unplug, solving both the above problems.
> > 
> > Or do we want to completely rely on userspace tools
> > (networkmanager/ifplug) and expect them to do NETDEV_DOWN on
> > unplug/suspend and NETDEV_UP on plug/resume?
> > 
> > Any thoughts?
> 
> This is an oft-reocurring discussion, what to do on link up/down
> events wrt. all sorts of autoconfiguration.
> 
> My gut instinct is that on any link state change (physical link down,
> suspend) we should be prepared to renegotiate everything and anything
> since as you state we could be on a different physical network.
> 
> Suspend is even more important because while we were suspended we
> could be on the same network but the routers present and available
> might have changed completely.
> 
> In userspace I've noticed that we've grown an ecosystem of stupid
> tools and facilities, none (or very few) of which monitor link status
> in order to do handle things intelligently.  DHCP servers are a great
> example.  DHCP servers spit out broadcast discover packets before we
> even have a link up.
> 
> Filling this void is NetworkManager, which does listen on a netlink
> socket for device state changes, hotplug, etc.  And in response it
> explicitly tells various facilities to reprobe the network.
> 
> This is why I'm reluctant to give NetworkManager a hard time, because
> whilst it's a huge beast, it is at least trying to do the right thing.
> :-)

Oh, it's not that huge :)  What's huge is the networking problem space,
and thus when you build something that tries to be aware of much of
what's going on (which in the modern world you do really need) it's
going to need to talk to all sorts of different subsystems...  Such is
life :(  It's sufficiently module though that if you have no need to
modems, or PPP, or WiFi, or 802.1x, or WiMAX, you don't need to run
those parts.  Of course now we're adding bridging, VLAN, bonding, etc
support, so the amoeba gets larger.  If only people stopped adding
features to the kernel networking stack :)

Dan

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Stephen Hemminger]

bridge forwarding table; route cache; and neighbor table could have same problem. I thought carrier is supposed to toggle on suspend or hibernate

Jiri Bohac <jbohac@suse.cz> wrote:

>Hi,
>
>I came over a surprising behaviour with IPv6 autoconfiguration,
>which I think is a bug, but I would first like to hear other
>people's opinions before trying to fix this:
>
>Problem 1: all the address/route lifetimes are kept in jiffies
>and jiffies don't get incremented on resume. So when a
>route/address lifetime is 30 minutes and the system resumes after
>1 hour, the route/address should be considered expired, but it is
>not.
>
>Problem 2: when a system is moved to a new network a RS is not
>sent. Thus, IPv6 does not autoconfigure until the router sends a
>periodic RA. This can occur both while the system is alive and
>while it is suspended. I think the autoconfigured state should be
>discarded when the kernel suspects the system could have been
>moved to a different network.
>
>When the cable is unplugged and plugged in again, we already get
>notified through linkwatch -> netdev_state_change ->
>  -> call_netdevice_notifiers(NETDEV_CHANGE, ...)
>However, if the device has already been autoconfigured,
>addrconf_notify() only handles this event by printing a
>message.
>
>So my idea was to:
>- handle link up/down in addrconf_notify() similarly to
>  NETDEV_UP/NETDEV_DOWN
>
>- on suspend, faking a link down event; on resume, faking a link up event
>  (or better, having a special event type for suspend/resume)
>
>This would cause autoconfiguration to be restarted on resume as
>well as cable plug/unplug, solving both the above problems.
>
>Or do we want to completely rely on userspace tools
>(networkmanager/ifplug) and expect them to do NETDEV_DOWN on
>unplug/suspend and NETDEV_UP on plug/resume?
>
>Any thoughts?
>
>-- 
>Jiri Bohac <jbohac@suse.cz>
>SUSE Labs, SUSE CZ
>

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Anirban Chakraborty]

On Jul 19, 2011, at 12:42 PM, Stephen Hemminger wrote:

> bridge forwarding table; route cache; and neighbor table could have same problem. I thought carrier is supposed to toggle on suspend or hibernate

In case of a VM using a VF as a NIC device, the VF would not know of a suspend event unless the hypervisor sends such a notification to the PF,
which the PF could relay back to the VF. Does KVM send such notification at present? Other option would be to bring down the interface in the
VM.

-Anirban



> 
> Jiri Bohac <jbohac@suse.cz> wrote:
> 
>> Hi,
>> 
>> I came over a surprising behaviour with IPv6 autoconfiguration,
>> which I think is a bug, but I would first like to hear other
>> people's opinions before trying to fix this:
>> 
>> Problem 1: all the address/route lifetimes are kept in jiffies
>> and jiffies don't get incremented on resume. So when a
>> route/address lifetime is 30 minutes and the system resumes after
>> 1 hour, the route/address should be considered expired, but it is
>> not.
>> 
>> Problem 2: when a system is moved to a new network a RS is not
>> sent. Thus, IPv6 does not autoconfigure until the router sends a
>> periodic RA. This can occur both while the system is alive and
>> while it is suspended. I think the autoconfigured state should be
>> discarded when the kernel suspects the system could have been
>> moved to a different network.
>> 
>> When the cable is unplugged and plugged in again, we already get
>> notified through linkwatch -> netdev_state_change ->
>> -> call_netdevice_notifiers(NETDEV_CHANGE, ...)
>> However, if the device has already been autoconfigured,
>> addrconf_notify() only handles this event by printing a
>> message.
>> 
>> So my idea was to:
>> - handle link up/down in addrconf_notify() similarly to
>> NETDEV_UP/NETDEV_DOWN
>> 
>> - on suspend, faking a link down event; on resume, faking a link up event
>> (or better, having a special event type for suspend/resume)
>> 
>> This would cause autoconfiguration to be restarted on resume as
>> well as cable plug/unplug, solving both the above problems.
>> 
>> Or do we want to completely rely on userspace tools
>> (networkmanager/ifplug) and expect them to do NETDEV_DOWN on
>> unplug/suspend and NETDEV_UP on plug/resume?
>> 
>> Any thoughts?
>> 
>> -- 
>> Jiri Bohac <jbohac@suse.cz>
>> SUSE Labs, SUSE CZ
>> 
> \x13��칻\x1c�&�~�&�\x18��+-��ݶ\x17��w��˛���m�޵ׯ�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!�i

Re: IPv6: autoconfiguration and suspend/resume or link down/up

[Stephen Hemminger]

who manages link wit sriov? I assume it is up to the guest. And it is not really safe to assume that network is the same after migration. It makes sense to do DAD again.

Herbert Xu <herbert@gondor.apana.org.au> wrote:

>On Sun, Jul 24, 2011 at 08:26:20PM -0700, Stephen Hemminger wrote:
>>
>> Since virtual machines should be using virtio network devices, shouldn't
>> the suspend/resume in that device just work. It doesn't need to drop the link.
>
>The VM may also be using SRIOV.
>
>Cheers,
>-- 
>Email: Herbert Xu <herbert@gondor.apana.org.au>
>Home Page: http://gondor.apana.org.au/~herbert/
>PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt