From ryanb@ca-1.enteract.com  Wed Nov  1 15:19:20 2000
Return-Path: <ryanb@ca-1.enteract.com>
Received: from mail.enteract.com (mail.enteract.com [207.229.143.33])
	by hub.freebsd.org (Postfix) with ESMTP id ADCEC37B4C5
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  1 Nov 2000 15:19:19 -0800 (PST)
Received: from ca-1.enteract.com (ca-1.enteract.com [207.229.143.13])
	by mail.enteract.com (8.9.3/8.9.3) with ESMTP id RAA38876
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 1 Nov 2000 17:19:18 -0600 (CST)
	(envelope-from ryanb@ca-1.enteract.com)
Received: (from ryanb@localhost)
	by ca-1.enteract.com (8.11.1/8.9.3) id eA1NJHY34630;
	Wed, 1 Nov 2000 17:19:17 -0600 (CST)
	(envelope-from ryanb)
Message-Id: <200011012319.eA1NJHY34630@ca-1.enteract.com>
Date: Wed, 1 Nov 2000 17:19:17 -0600 (CST)
From: R Beasley <ryanb@enteract.com>
Sender: ryanb@ca-1.enteract.com
Reply-To: ryanb@enteract.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: mass-aliasing of IPs to dc0 via ifconfig is unhappy
X-Send-Pr-Version: 3.2

>Number:         22489
>Category:       bin
>Synopsis:       mass IP aliasing via ifconfig broken
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 01 15:20:01 PST 2000
>Closed-Date:    Fri Jul 6 01:48:27 PDT 2001
>Last-Modified:  Fri Jul 06 01:48:42 PDT 2001
>Originator:     R Beasley
>Release:        FreeBSD 4.2-BETA i386
>Organization:
>Environment:

Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD 4.2-BETA #0: Wed Nov  1 11:04:13 CST 2000
    root@:/usr/obj/usr/src/sys/CA1
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (451.03-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x652  Stepping = 2
  Features=0x183fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM
OV,PAT,PSE36,MMX,FXSR>
real memory  = 536858624 (524276K bytes)
avail memory = 519471104 (507296K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
IOAPIC #0 intpin 17 -> irq 11
IOAPIC #0 intpin 18 -> irq 10
IOAPIC #0 intpin 19 -> irq 12
FreeBSD/SMP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  1, version: 0x00040011, at 0xfee00000
 cpu1 (AP):  apic id:  0, version: 0x00040011, at 0xfee00000
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec00000
Preloaded elf kernel "kernel" at 0xc02cc000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc02cc09c.
Pentium Pro MTRR support enabled
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Intel 82443BX (440 BX) host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <Intel 82443BX (440 BX) PCI-PCI (AGP) bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
isab0: <Intel 82371AB PCI to ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on isab0
pci0: <Intel PIIX4 ATA controller> at 4.1
pci0: <Intel 82371AB/EB (PIIX4) USB controller> at 4.2 irq 12
Timecounter "PIIX"  frequency 3579545 Hz
p1: <Intel 82371AB Power management controller> port 0xe800-0xe80f at device
4.3 on pci0
ahc0: <Adaptec aic7890/91 Ultra2 SCSI adapter> port 0xd000-0xd0ff mem 0xe3000000
-0xe3000fff irq 12 at device 6.0 on pci0
aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs
dc0: <82c169 PNIC 10/100BaseTX> port 0xb800-0xb8ff mem 0xe2800000-0xe28000ff irq
 12 at device 9.0 on pci0
dc0: Ethernet address: 00:a0:cc:39:eb:0a
miibus0: <MII bus> on dc0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc1: <82c169 PNIC 10/100BaseTX> port 0xb400-0xb4ff mem 0xe2000000-0xe20000ff irq
 10 at device 10.0 on pci0
dc1: Ethernet address: 00:a0:cc:39:eb:0e
miibus1: <MII bus> on dc1
ukphy1: <Generic IEEE 802.3u media interface> on miibus1
ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci0: <S3 ViRGE graphics accelerator> at 11.0 irq 11
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> on isa0
sc0: VGA <8 virtual consoles, flags=0x200>
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
io0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
Waiting 2 seconds for SCSI devices to settle
SMP: AP CPU #1 Launched!

  - and -

FreeBSD testbed.enteract.com 4.1.1-STABLE FreeBSD 4.1.1-STABLE #0: Thu Oct 26 21:48:10 CDT 2000     root@testbed.enteract.com:/usr/src/sys/compile/TESTBED  i386

(Duplicate dmesg info w/ exception of release.)

> Description:

  (Note:  This is my very first PR, so please bear with me.  :)
  (I haven't tested w/ SMP disabled yet, also haven't tested w/ non-dc cards.)

  On this specific web server, there are over 700 IP addresses bound to
one NIC.  Previously, binding all as aliases by processing a flat text
file w/o pacing between binds would leave all proper addreses bound as
necessary.

  Currently, the same script/text file are in use.  No error msgs are generated
and `ifconfig -a` output appears as normal.  The local machine may ping
and transmit/recv to the bound addresses as expected.  However, all outside
machines are unable to communicate with the 100th or so address on.  ARP
cache flushes have been performed, etc, etc -- manually removing the alias
and rebinding seems to fix.  Also, pacing with at least a 0.75-1 second
between binds seems to be OK as well.

  Example:

file named "ips.ca-1" contains around 750 addresses in a text file like so:

207.134.2.21
139.83.24.76
207.229.127.6
216.80.193.224
(etc)

[root@ca-1][~] $ for tmp in `cat ips.ca-1`; do ifconfig dc0 inet $tmp netmask 255.255.255.255 alias; done

  (IPs appear bound as expected.  Addresses below only meant as examples.)

[root@ca-1][~] $ ifconfig -a

dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 207.229.143.13 netmask 0xffffff00 broadcast 207.229.143.255
	inet 207.134.2.21 netmask 0xffffffff broadcast 207.134.2.21
	inet 139.83.24.76 netmask 0xffffffff broadcast 139.83.24.76
	inet 207.229.127.6 netmask 0xffffffff broadcast 207.229.127.6
	inet 216.80.193.224 netmask 0xffffffff broadcast 216.80.193.224
	[etc etc -snip-]
	inet 193.28.82.99 netmask 0xffffffff broadcast 193.28.82.99
	inet 84.38.19.32 netmask 0xffffffff broadcast 84.38.19.32
 
[ryanb@ca-1][~] $ ping 193.28.82.99
PING 193.28.82.99 (207.229.128.165): 56 data bytes
64 bytes from 193.28.82.99: icmp_seq=0 ttl=255 time=0.260 ms
64 bytes from 193.28.82.99: icmp_seq=1 ttl=255 time=0.048 ms
64 bytes from 193.28.82.99: icmp_seq=2 ttl=255 time=0.054 ms
^C
--- 193.28.82.99 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.048/0.121/0.260/0.099 ms

[ryanb@bjorn][~] $ ping 207.229.143.13
PING 207.229.143.13 (207.229.143.13): 56 data bytes
64 bytes from 207.229.143.13: icmp_seq=0 ttl=255 time=0.310 ms
64 bytes from 207.229.143.13: icmp_seq=1 ttl=255 time=0.026 ms
64 bytes from 207.229.143.13: icmp_seq=2 ttl=255 time=0.024 ms

[ryanb@bjorn][~] $ ping 193.28.82.99
PING 193.28.82.99 (216.80.6.226): 56 data bytes
^C
--- 193.28.82.99 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

(193.28.82.99 listed as [incomplete] in ARP table)

>Description:
>How-To-Repeat:

  1)    Get yourself a flat text file w/ a lot of addresses separated
	by newlines.

  2)	As root, execute the following lame-o script:

	#!/bin/sh
	for tmp in `cat <filename>`; do ifconfig <device_here> inet $tmp netmask 255.255.255.255 alias; done
	
  IPs will appear as being properly bound, yet are truely unusable to the
network outside of your machine.

>Fix:

  The only work around I know of is pacing the act of boundin the IPs.
ie: inserting a "sleep 1" in the above script, which then works fine.
(In our situation, that drives the boot time to over 10 minutes.)

>Release-Note:
>Audit-Trail:

From: Bill Swingle <unfurl@dub.net>
To: freebsd-gnats-submit@freebsd.org, ryanb@enteract.com
Cc:  
Subject: Re: bin/22489: mass IP aliasing via ifconfig broken
Date: 29 May 2001 22:43:34 -0700

 Why don't you just use the aliasing mechanisim that is built into
 /etc/rc.network?
 
 ifconfig_de0_alias0="inet 64.81.6.35 netmask 255.255.255.255"
 ifconfig_de0_alias1="inet 64.81.6.36 netmask 255.255.255.255"
 ifconfig_de0_alias2="inet 64.81.6.37 netmask 255.255.255.255"
 ifconfig_de0_alias3="inet 64.81.6.38 netmask 255.255.255.255"
 etc....
 
 I'm not so sure this is a problem with FreeBSD since there is a
 perfectly reasonable way to go about this that works.
 
 -Bill
 
 -- 
 -=| --- Bill Swingle --- http://www.dub.net/
 -=| unfurl@dub.net  - unfurl@freebsd.org 
 -=|    Do Not Taunt Happy Fun Ball(tm)
 
 

From: ryan beasley <ryanb@enteract.com>
To: Bill Swingle <unfurl@dub.net>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/22489: mass IP aliasing via ifconfig broken
Date: Wed, 30 May 2001 09:46:10 -0500

 On Tue, May 29, 2001 at 10:43:34PM -0700, Bill Swingle wrote:
 > Why don't you just use the aliasing mechanisim that is built into
 > /etc/rc.network?
 > 
 > ifconfig_de0_alias0="inet 64.81.6.35 netmask 255.255.255.255"
 > ifconfig_de0_alias1="inet 64.81.6.36 netmask 255.255.255.255"
 > ifconfig_de0_alias2="inet 64.81.6.37 netmask 255.255.255.255"
 > ifconfig_de0_alias3="inet 64.81.6.38 netmask 255.255.255.255"
 > etc....
 
 	The file controlling all of the addresses is an RCS'd flat text
 	file with _just_ IPs listed under it.  The purpose is so that
 	the "junior" types could run around and add/remove addresses to
 	be bound to this machine.  I trust them much more w/ a flat text
 	of IP<newline>IP<newline>etc than I would anyone mucking up
 	rc.conf.  :)
 
 > I'm not so sure this is a problem with FreeBSD since there is a
 > perfectly reasonable way to go about this that works.
 
 	Either way, the rc.network essentially does the same thing;
 	ifconfig <blah1> alias, ifconfig <blah2> alias, etc.  The only
 	difference is that I use a for/do/done loop whereas rc.network
 	uses while/do/done.
 
 	Anywho, if I run ifconfig and find all the addresses I bound
 	listed there, but they're NOT responsive to external network
 	traffic, I think that _is_ a FreeBSD problem.
 
 	... but on another note, I completely forgot that this was still
 	open.  ca-1 is running w/ a kernel from 12/19/2000 and I couldn't
 	replicate the behavior anymore.  (woot.)  Guess it's time to
 	close the PR. ;)
 
 --
 Ryan Beasley				<ryanb@enteract.com>
 FreeBSD SysAdmin			http://www.enteract.com

From: Bill Swingle <unfurl@dub.net>
To: ryan beasley <ryanb@enteract.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/22489: mass IP aliasing via ifconfig broken
Date: 30 May 2001 09:36:44 -0700

 On Wed, May 30, 2001 at 09:46:10AM -0500, ryan beasley wrote:
 > On Tue, May 29, 2001 at 10:43:34PM -0700, Bill Swingle wrote:
 > > Why don't you just use the aliasing mechanisim that is built into
 > > /etc/rc.network?
 > > 
 > > ifconfig_de0_alias0="inet 64.81.6.35 netmask 255.255.255.255"
 > > ifconfig_de0_alias1="inet 64.81.6.36 netmask 255.255.255.255"
 > > ifconfig_de0_alias2="inet 64.81.6.37 netmask 255.255.255.255"
 > > ifconfig_de0_alias3="inet 64.81.6.38 netmask 255.255.255.255"
 > > etc....
 > 
 > 	The file controlling all of the addresses is an RCS'd flat text
 > 	file with _just_ IPs listed under it.  The purpose is so that
 > 	the "junior" types could run around and add/remove addresses to
 > 	be bound to this machine.  I trust them much more w/ a flat text
 > 	of IP<newline>IP<newline>etc than I would anyone mucking up
 > 	rc.conf.  :)
 
 I can totally understand that.
 
 > > I'm not so sure this is a problem with FreeBSD since there is a
 > > perfectly reasonable way to go about this that works.
 > 
 > 	Either way, the rc.network essentially does the same thing;
 > 	ifconfig <blah1> alias, ifconfig <blah2> alias, etc.  The only
 > 	difference is that I use a for/do/done loop whereas rc.network
 > 	uses while/do/done.
 
 Have you tried while/do/done to see if it makes a difference? have you
 tried using the rc.network method to see if this problem exist then?
 
 > 
 > 	Anywho, if I run ifconfig and find all the addresses I bound
 > 	listed there, but they're NOT responsive to external network
 > 	traffic, I think that _is_ a FreeBSD problem.
 
 That's very true.
 
 > 	... but on another note, I completely forgot that this was still
 > 	open.  ca-1 is running w/ a kernel from 12/19/2000 and I couldn't
 > 	replicate the behavior anymore.  (woot.)  Guess it's time to
 > 	close the PR. ;)
 
 Glad to hear it. :)
 
 -Bill
 
 > 
 > -- 
 > Ryan Beasley				<ryanb@enteract.com>
 > FreeBSD SysAdmin			http://www.enteract.com
 
 -- 
 -=| --- Bill Swingle --- http://www.dub.net/
 -=| unfurl@dub.net  - unfurl@freebsd.org 
 -=|    Do Not Taunt Happy Fun Ball(tm)
 
 
State-Changed-From-To: open->closed 
State-Changed-By: roam 
State-Changed-When: Fri Jul 6 01:48:27 PDT 2001 
State-Changed-Why:  
Submitter reports the problem has gone away. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22489 
>Unformatted:
