Ken Schneider - openSUSE wrote:

On 01/05/2012 04:31 AM, Per Jessen pecked at the keyboard and wrote:

...

Lew Wolfgang wrote:

...

Hi Folks,

I noticed that 12.1 seems to have changed DHCP behavior where a new lease is not requested when the network interface is brought up. This manifests itself when an Ethernet cable is moved from one network to another. The DHCP-obtained parameters, including IP address, netmask and default gateway, "stick". The configuration persists through reboots and manually bouncing the network. Yesterday the only way I could get it to reset was to remove the lease files in /var/lib/dhcpd, then bounce the network.

On a reboot dhcpcd has to be started, so check to see what is happening at that point.

...

This behavior is new to 12.1, has anyone else noticed it? How can we tell the DHCP client to re-obtain a lease when its interface is brought up? This behavior noticed on more than one install of x86-64.

I have just checked the dhcp behaviour on my 12.1 laptop - nothing unusual, works just like before. (grep dhcp /var/log/messages).

But did you move from one place to another that has a different address space?

No, I didn't try that, but if the dhcp obtained settings were not renewed on reboot, that might be a place to investigate.

If the OP is using ifup you might want to try using NetworkManager instead.

I guess, although it wouldn't change the issue much, would it? -- Per Jessen, Zürich (7.7°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Lew Wolfgang wrote:

But the server would have been running ifup. I don't have access to this box at this time, but I've got another 12.1 desktop that I can fiddle with.

I hope that plugging in the cable would cause a DHCP request, as I normally configure DHCP enabled systems that way. I currently have one 12.1 system here that's configured that way. I'll have to test it when I have some free time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/05/2012 08:26 AM, James Knott wrote:

Per Jessen wrote:

...

On a reboot dhcpcd has to be started, so check to see what is happening at that point.

I think the idea is to have an immediate dhcp request when connecting to a network, which means dhcpcd should be restarted at that time.

Right, but if there's a still-valid lease showing in /var/lib/dhcpcd it looks like the just-started dhcpcd doesn't request a new lease. At least this how it seemed to me, I was in a hurry. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hi Folks, I've replicated the dhcpcd not getting a new lease on reboot/ifup, problem. This time on a desktop. I captured the dialogs below where we can see dhcpcd timing out after being run as a result of an if-up. But after the timeout, it checks to see if /var/lib/dhcpcd/ contains a valid lease. If it does, it uses that possibly invalid lease. If an old lease doesn't exist it broadcasts for a new one and all is then well. End result is the previous, and now possibly stale, dhcp lease being used. It even survives a complete reboot. This results in a dead network if subnets are changed. Removing /var/lib/dhcpcd/*, then rebooting or issuing /etc/init.d/network restart-all-dhcp-clients, will trigger a new lease broadcast and all is now well. This smells like a feature, intended to quicken the boot process, run amok. Regards, Lew Here's the spoor. IP address have been munged to protect the innocent. Unplugged Ethernet cable from a 192.168.1.0/24 subnet, then plugging into a full-up IPv4/IPv6 enabled network. Jan 5 13:13:09 ironhead kernel: [ 2652.274937] r8169 0000:03:00.0: eth0: link down Jan 5 13:13:14 ironhead kernel: [ 2657.525632] r8169 0000:03:00.0: eth0: link up ifconfig now showed the old 192.168.1.2 address, but did pick up the new IPv6 address. /var/lib/dhcpcd shows: -rw-r--r-- 1 root root 357 Jan 5 12:29 dhcpcd-eth0.info -rw-r--r-- 1 root root 0 Jan 5 13:31 dhcpcd-eth0.timestamp with dhcpcd-eth0.info containing: IPADDR='192.168.1.2' NETMASK='255.255.255.0' NETWORK='192.168.1.0' BROADCAST='192.168.1.255' ROUTES='' GATEWAYS='192.168.1.1' DNSSERVERS='192.168.1.1' DHCPSID='192.168.1.1' LEASEDFROM='1325795365' LEASETIME='86400' RENEWALTIME='43200' REBINDTIME='73440' INTERFACE='eth0' CLASSID='dhcpcd 3.2.3' CLIENTID='01:00:24:e8:08:00:43' DHCPCHADDR='00:24:e8:08:00:43' I then issued: /etc/init.d/network restart messages: Jan 5 13:44:51 ironhead network[4962]: Hint: you may set mandatory devices in /etc/sysconfig/network/config Jan 5 13:44:51 ironhead network[4962]: Setting up network interfaces: Jan 5 13:44:51 ironhead network[4962]: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:44:51 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:44:51 ironhead network[4962]: eth0 DHCP4 client is already running Jan 5 13:44:51 ironhead ifup-dhcp: eth0 DHCP4 client is already running Jan 5 13:44:51 ironhead network[4962]: eth0 IP address: 192.168.1.2/24 Jan 5 13:44:51 ironhead ifup-dhcp: eth0 IP address: 192.168.1.2/24 Jan 5 13:44:51 ironhead network[4962]: ..doneSetting up service network . . . . . . . . . .. done Jan 5 13:44:51 ironhead SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jan 5 13:44:51 ironhead SuSEfirewall2: Firewall rules successfully set I tried: /etc/init.d/network restart-all-dhcp-clients in messages: Jan 5 13:47:09 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:47:09 ironhead dhcpcd[5763]: eth0: sending signal 15 to pid 4325 Jan 5 13:47:09 ironhead dhcpcd[5763]: eth0: exiting Jan 5 13:47:09 ironhead dhcpcd[4325]: eth0: received SIGTERM, stopping Jan 5 13:47:09 ironhead dhcpcd[4325]: eth0: removing default route via 192.168.1.1 metric 0 Jan 5 13:47:09 ironhead dhcpcd[4325]: eth0: removing IP address 192.168.1.2/24 Jan 5 13:47:09 ironhead avahi-daemon[917]: Withdrawing address record for 192.168.1.2 on eth0. Jan 5 13:47:09 ironhead avahi-daemon[917]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.2. Jan 5 13:47:09 ironhead avahi-daemon[917]: Interface eth0.IPv4 no longer relevant for mDNS. Jan 5 13:47:09 ironhead dhcpcd[4325]: eth0: exiting Jan 5 13:47:10 ironhead network[5857]: Shutting down network interfaces: Jan 5 13:47:10 ironhead network[5857]: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:47:10 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:47:10 ironhead dhcpcd[6127]: eth0: dhcpcd not running Jan 5 13:47:10 ironhead dhcpcd[6127]: eth0: exiting Jan 5 13:47:10 ironhead avahi-daemon[917]: Withdrawing address record for XXXX:XXX:XX:44:f92a:9373:e88a:923b on eth0. Jan 5 13:47:10 ironhead avahi-daemon[917]: Withdrawing address record for XXXX:XXX:XX:44:224:e8ff:fe08:43 on eth0. Jan 5 13:47:10 ironhead avahi-daemon[917]: Registering new address record for fe80::224:e8ff:fe08:43 on eth0.*. Jan 5 13:47:10 ironhead avahi-daemon[917]: Withdrawing address record for fe80::224:e8ff:fe08:43 on eth0. Jan 5 13:47:10 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:47:11 ironhead kernel: [ 938.173492] r8169 0000:03:00.0: eth0: link down Jan 5 13:47:11 ironhead kernel: [ 938.173498] r8169 0000:03:00.0: eth0: link down Jan 5 13:47:11 ironhead kernel: [ 938.173808] ADDRCONF(NETDEV_UP): eth0: link is not ready Jan 5 13:47:11 ironhead ifup-dhcp: eth0 Starting DHCP4 client Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: dhcpcd 3.2.3 starting Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: hardware address = 00:24:e8:08:00:43 Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: broadcasting for a lease Jan 5 13:47:11 ironhead ifup-dhcp: . Jan 5 13:47:11 ironhead network[5857]: ..doneShutting down service network . . . . . . . . ...done Jan 5 13:47:12 ironhead kernel: [ 940.037464] show_signal_msg: 48 callbacks suppressed Jan 5 13:47:12 ironhead kernel: [ 940.037468] ntpd[4200]: segfault at 8 ip 00007f4822a31dee sp 00007fffeac10130 error 4 in ntpd[7f4822a15000+a1000] Jan 5 13:47:13 ironhead ifup-dhcp: . Jan 5 13:47:13 ironhead kernel: [ 940.669389] r8169 0000:03:00.0: eth0: link up Jan 5 13:47:13 ironhead kernel: [ 940.669827] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Jan 5 13:47:14 ironhead avahi-daemon[917]: Registering new address record for fe80::224:e8ff:fe08:43 on eth0.*. Jan 5 13:47:15 ironhead ifup-dhcp: . Jan 5 13:47:17 ironhead ifup-dhcp: . Jan 5 13:47:20 ironhead ifup-dhcp: . Jan 5 13:47:22 ironhead ifup-dhcp: . Jan 5 13:47:24 ironhead avahi-daemon[917]: Registering new address record for XXXX:XXX:XX:44:f89a:27d4:eb7d:b86 on eth0.*. Jan 5 13:47:24 ironhead avahi-daemon[917]: Withdrawing address record for fe80::224:e8ff:fe08:43 on eth0. Jan 5 13:47:24 ironhead ifup-dhcp: . Jan 5 13:47:24 ironhead avahi-daemon[917]: Registering new address record for XXXX:XXX:XX:44:224:e8ff:fe08:43 on eth0.*. Jan 5 13:47:26 ironhead ifup-dhcp: . Jan 5 13:47:27 ironhead ifup-dhcp: Jan 5 13:47:27 ironhead ifup-dhcp: eth0 DHCP4 continues in background Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: timed out Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info' Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: adding IP address 192.168.1.2/24 Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: adding default route via 192.168.1.1 metric 0 Jan 5 13:47:31 ironhead avahi-daemon[917]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.2. Jan 5 13:47:31 ironhead avahi-daemon[917]: New relevant interface eth0.IPv4 for mDNS. Jan 5 13:47:31 ironhead avahi-daemon[917]: Registering new address record for 192.168.1.2 on eth0.IPv4. Jan 5 13:47:31 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Jan 5 13:47:31 ironhead rsyslogd: [origin software="rsyslogd" swVersion="5.8.5" x-pid="901" x-info="http://www.rsyslog.com"] rsyslogd was HUPed Jan 5 13:47:31 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Jan 5 13:47:31 ironhead SuSEfirewall2: /var/lock/SuSEfirewall2.booting exists which means system boot in progress, exit. Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: exiting Jan 5 13:47:40 ironhead ntp[7833]: Shutting down network time protocol daemon (NTPD)..done Jan 5 13:47:40 ironhead dbus-daemon[958]: **** /proc/self/mountinfo changed Removing /var/lib/dhcpcd/*, then doing another /etc/init.d/network restart-all-dhcp-clients gives us this: Jan 5 13:58:32 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:58:32 ironhead dhcpcd[8161]: eth0: sending signal 15 to pid 7831 Jan 5 13:58:32 ironhead dhcpcd[8161]: eth0: exiting Jan 5 13:58:32 ironhead dhcpcd[7831]: eth0: received SIGTERM, stopping Jan 5 13:58:32 ironhead dhcpcd[7831]: eth0: removing default route via 192.168.1.1 metric 0 Jan 5 13:58:32 ironhead dhcpcd[7831]: eth0: removing IP address 192.168.1.2/24 Jan 5 13:58:32 ironhead avahi-daemon[917]: Withdrawing address record for 192.168.1.2 on eth0. Jan 5 13:58:32 ironhead avahi-daemon[917]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.2. Jan 5 13:58:32 ironhead avahi-daemon[917]: Interface eth0.IPv4 no longer relevant for mDNS. Jan 5 13:58:32 ironhead dhcpcd-hook: /var/lib/dhcpcd/dhcpcd-eth0.info does not exist. Skipping 'ifdown -o dhcp' call Jan 5 13:58:32 ironhead dhcpcd[7831]: eth0: exiting Jan 5 13:58:33 ironhead avahi-daemon[917]: Withdrawing address record for XXXX:XXX:XX:44:f89a:27d4:eb7d:b86 on eth0. Jan 5 13:58:33 ironhead avahi-daemon[917]: Withdrawing address record for XXXX:XXX:XX:44:224:e8ff:fe08:43 on eth0. Jan 5 13:58:33 ironhead avahi-daemon[917]: Registering new address record for fe80::224:e8ff:fe08:43 on eth0.*. Jan 5 13:58:33 ironhead avahi-daemon[917]: Withdrawing address record for fe80::224:e8ff:fe08:43 on eth0. Jan 5 13:58:33 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:58:33 ironhead kernel: [ 1620.688618] r8169 0000:03:00.0: eth0: link down Jan 5 13:58:33 ironhead kernel: [ 1620.688624] r8169 0000:03:00.0: eth0: link down Jan 5 13:58:33 ironhead kernel: [ 1620.688921] ADDRCONF(NETDEV_UP): eth0: link is not ready Jan 5 13:58:33 ironhead ifup-dhcp: eth0 Starting DHCP4 client Jan 5 13:58:33 ironhead dhcpcd[8502]: eth0: dhcpcd 3.2.3 starting Jan 5 13:58:33 ironhead dhcpcd[8502]: eth0: hardware address = 00:24:e8:08:00:43 Jan 5 13:58:33 ironhead dhcpcd[8502]: eth0: broadcasting for a lease Jan 5 13:58:33 ironhead ifup-dhcp: . Jan 5 13:58:35 ironhead ifup-dhcp: . Jan 5 13:58:36 ironhead kernel: [ 1623.129461] r8169 0000:03:00.0: eth0: link up Jan 5 13:58:36 ironhead kernel: [ 1623.129795] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Jan 5 13:58:37 ironhead avahi-daemon[917]: Registering new address record for fe80::224:e8ff:fe08:43 on eth0.*. Jan 5 13:58:38 ironhead ifup-dhcp: . Jan 5 13:58:40 ironhead ifup-dhcp: . Jan 5 13:58:42 ironhead ifup-dhcp: . Jan 5 13:58:44 ironhead ifup-dhcp: . Jan 5 13:58:46 ironhead kernel: [ 1633.698012] eth0: no IPv6 routers present Jan 5 13:58:46 ironhead ifup-dhcp: . Jan 5 13:58:48 ironhead kernel: [ 1635.308581] martian source 255.255.255.255 from XXX.XXX.44.11, on dev eth0 Jan 5 13:58:48 ironhead kernel: [ 1635.308584] ll header: ff:ff:ff:ff:ff:ff:00:24:e8:0d:ee:63:08:00 Jan 5 13:58:49 ironhead ifup-dhcp: . Jan 5 13:58:50 ironhead ifup-dhcp: Jan 5 13:58:50 ironhead ifup-dhcp: eth0 DHCP4 continues in background Jan 5 13:58:50 ironhead SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jan 5 13:58:50 ironhead SuSEfirewall2: Firewall rules successfully set Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: timed out Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info' Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: lease information file `/var/lib/dhcpcd/dhcpcd-eth0.info' does not exist Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: broadcasting for a lease Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: offered XXX.XXX.44.20 from XXX.XXX.4.2 Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: checking XXX.XXX.44.20 is available on attached networks Jan 5 13:58:54 ironhead dhcpcd[8502]: eth0: leased XXX.XXX.44.20 for 3600 seconds Jan 5 13:58:54 ironhead dhcpcd[8502]: eth0: adding IP address XXX.XXX.44.20/24 Jan 5 13:58:54 ironhead dhcpcd[8502]: eth0: adding default route via XXX.XXX.44.1 metric 0 Jan 5 13:58:54 ironhead avahi-daemon[917]: Joining mDNS multicast group on interface eth0.IPv4 with address XXX.XXX.44.20. Jan 5 13:58:54 ironhead avahi-daemon[917]: New relevant interface eth0.IPv4 for mDNS. Jan 5 13:58:54 ironhead avahi-daemon[917]: Registering new address record for XXX.XXX.44.20 on eth0.IPv4. Jan 5 13:58:54 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Jan 5 13:58:54 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Jan 5 13:58:55 ironhead SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jan 5 13:58:55 ironhead SuSEfirewall2: Firewall rules successfully set Jan 5 13:58:55 ironhead dhcpcd[8502]: eth0: exiting Now we can see dhcpcd broadcasting for a new lease and all is well. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Lew Wolfgang wrote:

On 01/05/2012 08:34 AM, Lew Wolfgang wrote:

...

On 01/05/2012 08:26 AM, James Knott wrote:

...

Per Jessen wrote:

...

On a reboot dhcpcd has to be started, so check to see what is happening at that point.

I think the idea is to have an immediate dhcp request when connecting to a network, which means dhcpcd should be restarted at that time.

Right, but if there's a still-valid lease showing in /var/lib/dhcpcd it looks like the just-started dhcpcd doesn't request a new lease. At least this how it seemed to me, I was in a hurry.

OK, I confirmed the behavior on another 12.1 x86-64 desktop.

I started the system with eth0 connected to a router which assigned a DHCP address of 192.168.1.2. I then unplugged the cable and connected to a fully up and running network. ifconfig showed the old, and now stale, IP address. /var/log/messages showed a "link down", then a "link up" message without re-running dhcpcd.

I then issued a "/etc/init.d/network restart" which didn't help. Messages showed an entry from ifup-dhcp saying the "client is already running" and repeated the old IP address.

I don't know the exact semantics of "rcnetwork restart" - it might make sense to expect dhcpcd to renew leases (dhcpcd -n).

So I then issued a "/etc/init.d/network restart-all-dhcp-clients". This option did a lot more as reflected in messages, but it still didn't renew the DHCP lease. It started dhcpcd but put it in background, then dhcpcd reported "eth0 timed out". At this point it tried to "use old lease in /var/lib/dhcpcd/dhcpcd-eth0.info'", which still contained the old lease info, and proceeded to reuse the old lease without broadcasting for a new one.

It must have done a broadcast, otherwise why would it report "eth0 timed out"? Following a time-out, it seems reasonable to attempt a fall-back to the previous lease.

I then removed the lease files in /var/lib/dhcpcd/ and re-ran /etc/init.d/network restart-all-dhcp-clients. Now dhcpcd says the lease information file does not exist and proceeds to broadcast for a new lease. Now it works!

The key question would appear to be - what caused the time-out on the first attempt?

So I see two issues:

1. dhcpcd doesn't seem to be tickled by the interface going down, then up (cable swap).

If it worked in a previous release, it sounds like a bug.

2. When dhcpcd does start/restart, it doesn't broadcast for a new lease if an old one exists.

Mine does. It requests the still-valid lease, and will reuse that one only if ack'ed by the dhcp server. If nack'ed, it'll broadcast for a new one. -- Per Jessen, Zürich (3.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/06/2012 03:25 AM, Per Jessen wrote:

Per Jessen wrote:

...

...

So I then issued a "/etc/init.d/network restart-all-dhcp-clients". This option did a lot more as reflected in messages, but it still didn't renew the DHCP lease. It started dhcpcd but put it in background, then dhcpcd reported "eth0 timed out". At this point it tried to "use old lease in /var/lib/dhcpcd/dhcpcd-eth0.info'", which still contained the old lease info, and proceeded to reuse the old lease without broadcasting for a new one. It must have done a broadcast, otherwise why would it report "eth0 timed out"? Following a time-out, it seems reasonable to attempt a fall-back to the previous lease. In the logs you posted, there is a 20 second span between broadcast and time-out:

Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: broadcasting for a lease Jan 5 13:47:27 ironhead ifup-dhcp: eth0 DHCP4 continues in background Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: timed out Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info'

Is there a problem with the DHCP server? If you check the server logs, you should see a complete trace of the negotation, but I guess the server isn't responding, hence the time-out.

Ah, good point about the timeout! The network is a large one, many thousands of hosts, and I don't have access to the server logs. But I know who does and will check with him today. I'll also try the switch in the opposite direction: from the big network to the natted side of a small router. There shouldn't be a timeout issue there. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

When they bring up a new machine and do dhcp, it takes about 45 seconds to get the new IP. I'm convinced most of the time is the switches playing games trying to figure out the most efficient way to connect the newly introduced machine to the dhcp server.

Isn't that any easy problem to solve? Whichever switch the new machine is connected to just looks in its tables and asks "how did I send traffic to <the dhcp server> last time somebody asked me?" The answer doesn't depend in any way on there being a new machine. But I'm no expert, so perhaps I'll learn something! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

If you have a full class A (ie. /8 or 10.x.x.x) then you conceivably have 10's of thousands (or more) MACs to potentially keep up with and setup spanning trees for.

Wait 'till you start working with IPv6 networks, where you can have up to 2^64 devices on a subnet! Of course, practical considerations may limit that somewhat. ;-) I have a /56 IPv6 subnet, which can be split into 256 /64 subnets. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

On Fri, Jan 6, 2012 at 1:48 PM, James Knott wrote:

...

Greg Freemyer wrote:

...

If you have a full class A (ie. /8 or 10.x.x.x) then you conceivably have 10's of thousands (or more) MACs to potentially keep up with and setup spanning trees for.

Wait 'till you start working with IPv6 networks, where you can have up to 2^64 devices on a subnet!

Of course, practical considerations may limit that somewhat. ;-)

I have a /56 IPv6 subnet, which can be split into 256 /64 subnets. I'm a IPv6 neophyte, but I have wondered about that.

Since IPv6 is 128 bits I think, a single /64 subnet is as big as the public facing Internet is today. (ie. Ignoring private IP space like 10.x.x.x).

Actually, it's the entire IPv4 address space squared! IPv4 has 2^32 or about 4 billion addresses. 2^64 is 18.4 quintillion. My /56 subnet is 2^72 or 4.7 sextillion, but I haven't used them all yet. ;-)

I have a hard time fathoming how something that big can be managed without some form of hierarchy.

Actually, the IPv6 address space is designed to be a hierarchy, so as to reduce routing table size. Also, most subnets will actually have only a tiny fraction of the possible addresses. The current practice, with recent versions of Linux, Windows etc., is to have at least 3 addresses per device. Those are the link local address, starting with FE80, which all IPv6 devices must have. Then there's a MAC based address on the subnet and due to privacy concerns, one on the subnet using a 64 bit random number, in place of the MAC based address. The MAC address, when used as part of an IPv6 address has FFFE stuck in the middle to fill it out to 64 bits. The reason for that random number address is that the MAC based one is tied to a specific computer and some people think that may be a security issue. So the random number address is used for outgoing connections and the MAC based, incoming. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/06/2012 10:48 AM, James Knott wrote:

Greg Freemyer wrote:

...

If you have a full class A (ie. /8 or 10.x.x.x) then you conceivably have 10's of thousands (or more) MACs to potentially keep up with and setup spanning trees for.

Wait 'till you start working with IPv6 networks, where you can have up to 2^64 devices on a subnet!

Of course, practical considerations may limit that somewhat. ;-)

I have a /56 IPv6 subnet, which can be split into 256 /64 subnets.

Actually, our main network is fully IPv6 enabled. I didn't have any problems with the IPv6 auto configuration, which is obtained from the closest router if I'm not mistaken. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Howorth wrote:

...

When they bring up a new machine and do dhcp, it takes about 45 seconds to get the new IP. I'm convinced most of the time is the switches playing games trying to figure out the most efficient way to connect the newly introduced machine to the dhcp server. Isn't that any easy problem to solve? Whichever switch the new machine is connected to just looks in its tables and asks "how did I send

Greg Freemyer wrote: traffic to<the dhcp server> last time somebody asked me?" The answer doesn't depend in any way on there being a new machine.

But I'm no expert, so perhaps I'll learn something!

Actually, with Spanning Tree Protocol (STP), it shouldn't even take that long. Each switch maintains a table of devices (MAC addresses) connected to it and through STP, the switches determine the best path. If a link fails, an alternate path, if available, is used. This all happens automagically. Of course, switches know nothing about DHCP requests or anything else to do with IP. They handle level 2 traffic (Ethernet etc.) only, not higher protocols. https://en.wikipedia.org/wiki/Spanning_tree_protocol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/06/2012 10:48 AM, Lew Wolfgang wrote:

Still, it would be nice if a hardware-induced (cable swap) interface bounce would also generate a new dhcpcd broadcast. Feature request?

I tried cable swapping on a MAC Mini and it worked exactly as expected. 1. Unplug the Ethernet cable from the home network and connect it to a natted stand-alone router. The MAC saw the port swap and after 12 seconds loaded the new IP addresses. 2. Unplug the cable and reconnect to the home network and after another 12 second delay it showed the correct address for the routable network. I'm sure that Windows boxes will perform in a similar fashion. Why not openSuSE? Not that this situation will be encountered very often, but it does violate Wolfgang's Principle of Least Astonishment. Also, why does the MAC's dhcpcd not timeout as 12.1 does? I'll try this drill on my home cable-modem network too. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still.

Actually, it's very useful for anyone working regularly on computer networks trying to resolve problems. There have been many times in Windows when I've had to do an ipconfig release & renew. With Linux, I simply set the interface to be started when the cable was unplugged. Rebooting or turning the equipment off/on would also cause the cable to "unplug". I have worked on a lot of networking equipment that comes set to 10.0.0.x by default and then had to reconfigure to the desired network range. After it has been changed, it's nice if the computer can follow the address automagically. Restarting the NIC, including dhcpcd when rebooting the device does that. When configuring a Linux computer for dhcp, I always set it to start the NIC on cable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Maybe this is only for NetworkManager, I don't see such an option for ifup/down.

Every time the NIC is brought up, it should assume it's on a different network and run the dhcp client. What possible justification is there for not doing so? How is plugging in a cable supposed to be different from using ifdown/ifup? Either way, it should try to obtain an address. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

For instance, plugging in the cable does not imply you also want the interface brought up.

It does if that's how you configured it. I always configure to do that with DHCP. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Cool, then there is no real problem. Unless the "ifplugd" setting doesn't ctually work, in which case - bugreport.

It seems to me that was the original point of this thread. I don't have the original message anymore, so I can't verify. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/08/2012 11:47 AM, Per Jessen wrote:

James Knott wrote:

...

...

Cool, then there is no real problem. Unless the "ifplugd" setting doesn't ctually work, in which case - bugreport. It seems to me that was the original point of this thread. I don't have the original message anymore, so I can't verify. It's in the archives, but Lew Wolfgangs problem was two-fold - a dhcp timeout, and not getting the lease renewed/updated when unplugging/

Per Jessen wrote: plugging the cable. The solution to the latter would appear to be to define the interface as "ifplugd" when configuring it with yast.

Hi Per, Wow, I had no idea about "ifplugd"! I tried it and it takes care of my plug/unplug issue. I really don't know how I could have been ignorant so long about an important (for me) facility like this. If anyone listening is as ignorant as I was, I enabled ifplugd by editing /etc/sysconfig/network/ifcfg-eth0 and changing STARTMODE='auto' to STARTMODE='ifplugd'. I don't know if this is the politically correct way to set it, but it works. I think an argument can be made that ifplugd should be enabled by default on hard-wired interfaces. I'll fiddle with a 12.1 laptop tomorrow to see if NetworkManager behaves differently. Regarding my second dhcp timeout issue, I'm convinced at this point that it's being caused by some interaction with the large work network. It behaves correctly here at home. I'll see if I can get access to the dhcp server logs to maybe figure out what's going on. Some quality time with tcpdump may also be appropriate. Thanks to everyone for their help! Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 06 Jan 2012 22:36:40 +0100, Per Jessen wrote:

...

Why not openSuSE? Not that this situation will be encountered very often, but it does violate Wolfgang's Principle of Least Astonishment.

I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still.

I agree. A real world example is my university. On the wired network, when a unknown hw-address connects (and is not 802.1x capable) they are placed on a registration vlan and given a temporary dhcp lease. All www is redirected to a captive portal and the user is supposed to give his credentials. If the user succeeds entering a username and a password, we register his mac-address in our database and instructs the switch to put the the port offline for a short while. This is seen from the the client as a disconnect/connect and the process restarts, only this time the hw-addresss is known to the switch and the client is now placed on a suitable vlan. I think this is how most captive portals work. If it is correct that 12.1 just reuses the registration lease after the network has toggled. Then network registration will now take several minutes until the registration lease expires, as opposed to something like 30 sec. for Windows and Mac users. I will certainly have to test this tomorrow, when I get to work. -- Klaus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

hi James Søndag den 8. januar 2012 19:41:39 skrev James Knott:

A lease of several minutes would be unusual.

not on a registration VLAN. Users are requested to present credentials and subsequently moved to the correct VLAN. -- Klaus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Good example, even if perhaps not very common. I've googled a bit, and I think your setup will work if the NIC is set up to work as/with "ifplugd". That may be what James Knott referred to.

VLANs are commonly used where there are different classes of hosts. For example, I have set up VoIP phone systems that use VLANs. What VLAN the phone or computer lands on is determined by info provided by the DHCP server. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Lew Wolfgang wrote:

...

Why not openSuSE? Not that this situation will be encountered very often, but it does violate Wolfgang's Principle of Least Astonishment.

I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still.

I haven't thought about this very hard but what is the effect if I simply unplug a network cable and then plug it back in again? I would hope no effect - it should be completely transparent to any applications with TCP connections in progress. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

...

I haven't thought about this very hard but what is the effect if I simply unplug a network cable and then plug it back in again? I would hope no effect - it should be completely transparent to any applications with TCP connections in progress. It will depend, surely, on how long the cable is unplugged for and what

Dave Howorth said the following on 01/09/2012 07:53 AM: the applications are doing.

The man page says you can specify the poll time and latencies and that might have something to do with it all as well.

Like so many questions, "it all depends" on specific circumstances.

As long as the cable is plugged in again before the lease expires, the same address should be provided. However, if unplugged long enough, open TCP connections and some applications or services will fail. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org