Re: Bizarre Networking Problem

2003-02-21 Thread Joseph Noonan
On Thu, 20 Feb 2003 at 7:20pm Bill Moran wrote:

 Perhaps some output form 'netstat -rn' and 'ifconfig' might
 provoke some more useful answers.

Well the problem is solved, but I am not happy about the solution
as it makes absolutely no sense to me.

xl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
options=3rxcsum,txcsum
inet 192.246.38.10 netmask 0xff00 broadcast 255.255.255.0
inet 208.23.240.10 netmask 0xff00 broadcast 208.23.240.255
ether 00:04:75:b0:24:12
media: Ethernet autoselect (100baseTX full-duplex)
status: active

The above was the ifconfig when I had the problem.  Notice the
broadcast addresses.  The commands that brought up the interface
at boot are:

/sbin/ifconfig xl0 192.246.38.10 netmask 255.255.255.0
/sbin/ifconfig xl0 alias 208.23.240.10 netmask 255.255.255.0

(note that the netmask really is not required as those IP's are
from traditional class C, but I like to always be specific so I
don't forget one when I'm working in 'A' or 'B' space.)

So those commands give two different kinds of broadcast addresses
and to my way of thinking, the second one (on the 208...) is
correct.  But if I alias the interface like so:

ifconfig inet 208.23.240.10 netmask 0xff00 broadcast 255.255.255.0

The sluggishness on the 208 net goes away.  I don't understand it,
but it works.  I don't like stuff this, it creeps me out.


-- 

Joseph F. Noonan
Rigaku/MSC Inc.
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message



Re: Bizarre Networking Problem

2003-02-21 Thread Mark
- Original Message -
From: Joseph Noonan [EMAIL PROTECTED]
To: Bill Moran [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, February 21, 2003 6:07 PM
Subject: Re: Bizarre Networking Problem

 The above was the ifconfig when I had the problem.  Notice the
 broadcast addresses.  The commands that brought up the interface
 at boot are:

 /sbin/ifconfig xl0 192.246.38.10 netmask 255.255.255.0
 /sbin/ifconfig xl0 alias 208.23.240.10 netmask 255.255.255.0


Hmm, I thought aliases always needed to have netmask of 255.255.255.255. Has
something changed?

- Mark


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message



Re: Bizarre Networking Problem

2003-02-21 Thread Bill Moran
Joseph Noonan wrote:

On Thu, 20 Feb 2003 at 7:20pm Bill Moran wrote:


Perhaps some output form 'netstat -rn' and 'ifconfig' might
provoke some more useful answers.


Well the problem is solved, but I am not happy about the solution
as it makes absolutely no sense to me.

xl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
options=3rxcsum,txcsum
inet 192.246.38.10 netmask 0xff00 broadcast 255.255.255.0
inet 208.23.240.10 netmask 0xff00 broadcast 208.23.240.255
ether 00:04:75:b0:24:12
media: Ethernet autoselect (100baseTX full-duplex)
status: active

The above was the ifconfig when I had the problem.  Notice the
broadcast addresses.  The commands that brought up the interface
at boot are:

/sbin/ifconfig xl0 192.246.38.10 netmask 255.255.255.0
/sbin/ifconfig xl0 alias 208.23.240.10 netmask 255.255.255.0

(note that the netmask really is not required as those IP's are
from traditional class C, but I like to always be specific so I
don't forget one when I'm working in 'A' or 'B' space.)

So those commands give two different kinds of broadcast addresses
and to my way of thinking, the second one (on the 208...) is
correct.  But if I alias the interface like so:

ifconfig inet 208.23.240.10 netmask 0xff00 broadcast 255.255.255.0


That doesn't look right.  The broadcast address should be 208.23.240.255
for that IP and 192.246.38.255 for the other one.
Can you try these broadcast addys and see if the problem is fixed there
as well?


The sluggishness on the 208 net goes away.  I don't understand it,
but it works.  I don't like stuff this, it creeps me out.


Can't argue with you.  I don't see how what you did would fix anything.
However, I'm not surprised that ifconfig doesn't guess the right action
all the time.  I wouldn't get upset if you have to specify the broadcast
addy to be sure it's right.

--
Bill Moran
Potential Technologies
http://www.potentialtech.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message



RE: Bizarre Networking Problem

2003-02-21 Thread Brent Wiese
 Well the problem is solved, but I am not happy about the 
 solution as it makes absolutely no sense to me.
 
 xl0: 
 flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
 options=3rxcsum,txcsum
 inet 192.246.38.10 netmask 0xff00 broadcast 255.255.255.0
 inet 208.23.240.10 netmask 0xff00 broadcast 208.23.240.255
 ether 00:04:75:b0:24:12
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 

Your nic is set autosense. While probably not the only culprit, if you
can manage your 3com switch, hard set the port and your NIC to 100 full
duplex. 

It may not solve the problem, but its one more variable eliminated.

I was running a HP 4000M and all the machines set auto. I did a code
upgrade on the switch and all of sudden performance went in the gutter
because, for some reason, autosense broke. Once I hard set 100fd on
everything, performance was once again stellar.

The broadcast for 192.246.38.10 is wrong too.

You shouldn't have to run in promiscous mode to solve this... Doing so
is going to kill your CPU when traffic gets high.

Brent


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message



Re: Bizarre Networking Problem

2003-02-21 Thread Matthew Seaman
On Fri, Feb 21, 2003 at 05:17:17PM +, Mark wrote:
 From: Joseph Noonan [EMAIL PROTECTED]

  The above was the ifconfig when I had the problem.  Notice the
  broadcast addresses.  The commands that brought up the interface
  at boot are:
 
  /sbin/ifconfig xl0 192.246.38.10 netmask 255.255.255.0
  /sbin/ifconfig xl0 alias 208.23.240.10 netmask 255.255.255.0
 
 
 Hmm, I thought aliases always needed to have netmask of 255.255.255.255. Has
 something changed?

Nope.  You only use a netmask of 255.255.255.255 when the alias
address is the second or subsequent address from a given network.
If the alias address is the first one from a distinct network, it
should have the regular netmask.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   26 The Paddocks
  Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614  Bucks., SL7 1TH UK

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message



Netmasks for aliases (was Re: Bizarre Networking Problem)

2003-02-21 Thread Willie Viljoen
On Friday 21 February 2003 19:17, Mark wrote:
 
  /sbin/ifconfig xl0 192.246.38.10 netmask 255.255.255.0
  /sbin/ifconfig xl0 alias 208.23.240.10 netmask 255.255.255.0

 Hmm, I thought aliases always needed to have netmask of 255.255.255.255.
 Has something changed?

 - Mark

Mark,

Aliases on the same subnet should always be 255.255.255.255, this does not 
apply where they are on different subnets, however. Here is a good example, 
from the ifconfig output of a mail server I set up at an ISP in a nearby 
town. They used to use a private range, but have since added a public class 
C which has been broken up into smaller ranges for routing. 

The mail server, for legacy reasons, still has to serve people on the old 
IPs because those are still being used by machines in their office, and 
reconfiguring every office machine with new server IP addresses (they 
didn't have internal DNS then) would be wasting time. We didn't want to 
waste public IPs on beancounters, so we just left their machines as is. 

The host is also serving on the new IP, and acting as a POP server for 
several virtual domains, which have aliases. The 10.0.1.0/24 range (their 
office), and the 196.38.113.0/27 range (used for their server farm + 
virtual domains) are still the same physical network though. The output 
from ifconfig follows:

%ifconfig
dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 196.38.113.2 netmask 0xffe0 broadcast 196.38.113.31
inet6 fe80::a00:8ff:fe00:800%dc0 prefixlen 64 scopeid 0x1
inet 196.38.113.3 netmask 0x broadcast 196.38.113.3
inet 196.38.113.5 netmask 0x broadcast 196.38.113.5
inet 196.38.113.6 netmask 0x broadcast 196.38.113.6
inet 196.38.113.7 netmask 0x broadcast 196.38.113.7
inet 196.38.113.8 netmask 0x broadcast 196.38.113.8
inet 196.38.113.9 netmask 0x broadcast 196.38.113.9
inet 196.38.113.10 netmask 0x broadcast 196.38.113.10
inet 196.38.113.11 netmask 0x broadcast 196.38.113.11
inet 10.0.1.4 netmask 0xff00 broadcast 10.0.1.255
inet 10.0.1.5 netmask 0x broadcast 10.0.1.5
ether 08:00:08:00:08:00
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00

Note how 196.38.113.2 (the machine's real address) has a netmask of 
0xffe0, or 255.255.255.224, and the other addresses in this range (all 
of them aliases) have 0x, 255.255.255.255. Then look at 10.0.1.4, 
which is an alias too. It has a netmask of 0xff00, or 255.255.255.0. 
Now look at 10.0.1.5, an alias used for serving intranet web content to 
legacy machines. Again, a netmask of 0x. 

The reason for this is that 10.0.1.4, even though being an alias, is the 
first address the machine handles on that subnet. Just as 196.38.113.2 is 
the first address the machine has on the public subnet.

Rule of thumb: First address on a subnet, alias or not, has the proper 
subnet netmask. Every other address on the subnet following that, has 
0x, or 255.255.255.255.

Will



 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-questions in the body of the message

-- 
Willie Viljoen
Freelance IT Consultant

214 Paul Kruger Avenue, Universitas
Bloemfontein
9321
South Africa

+27 51 522 15 60
+27 51 522 44 36 (after hours)
+27 82 404 03 27 (mobile)

[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message



Re: Netmasks for aliases (was Re: Bizarre Networking Problem)

2003-02-21 Thread Mark
- Original Message -
From: Willie Viljoen [EMAIL PROTECTED]
To: Mark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, February 21, 2003 7:24 PM
Subject: Netmasks for aliases (was Re: Bizarre Networking Problem)

 On Friday 21 February 2003 19:17, Mark wrote:

   /sbin/ifconfig xl0 192.246.38.10 netmask 255.255.255.0
   /sbin/ifconfig xl0 alias 208.23.240.10 netmask 255.255.255.0
 
  Hmm, I thought aliases always needed to have netmask of 255.255.255.255.
  Has something changed?
 
  - Mark

 Mark,

 Aliases on the same subnet should always be 255.255.255.255, this does not
 apply where they are on different subnets, however. Here is a good
 example, from the ifconfig output of a mail server I set up at an ISP in a
 nearby town. They used to use a private range, but have since added a
 public class C which has been broken up into smaller ranges for routing.

 The mail server, for legacy reasons, still has to serve people on the old
 IPs because those are still being used by machines in their office, and
 reconfiguring every office machine with new server IP addresses (they
 didn't have internal DNS then) would be wasting time. We didn't want to
 waste public IPs on beancounters, so we just left their machines as is.

 The host is also serving on the new IP, and acting as a POP server for
 several virtual domains, which have aliases. The 10.0.1.0/24 range (their
 office), and the 196.38.113.0/27 range (used for their server farm +
 virtual domains) are still the same physical network though. The output
 from ifconfig follows:

 %ifconfig
 dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 inet 196.38.113.2 netmask 0xffe0 broadcast 196.38.113.31
 inet6 fe80::a00:8ff:fe00:800%dc0 prefixlen 64 scopeid 0x1
 inet 196.38.113.3 netmask 0x broadcast 196.38.113.3
 inet 196.38.113.5 netmask 0x broadcast 196.38.113.5
 inet 196.38.113.6 netmask 0x broadcast 196.38.113.6
 inet 196.38.113.7 netmask 0x broadcast 196.38.113.7
 inet 196.38.113.8 netmask 0x broadcast 196.38.113.8
 inet 196.38.113.9 netmask 0x broadcast 196.38.113.9
 inet 196.38.113.10 netmask 0x broadcast 196.38.113.10
 inet 196.38.113.11 netmask 0x broadcast 196.38.113.11
 inet 10.0.1.4 netmask 0xff00 broadcast 10.0.1.255
 inet 10.0.1.5 netmask 0x broadcast 10.0.1.5
 ether 08:00:08:00:08:00
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
 inet6 ::1 prefixlen 128
 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
 inet 127.0.0.1 netmask 0xff00

 Note how 196.38.113.2 (the machine's real address) has a netmask of
 0xffe0, or 255.255.255.224, and the other addresses in this range (all
 of them aliases) have 0x, 255.255.255.255. Then look at 10.0.1.4,
 which is an alias too. It has a netmask of 0xff00, or 255.255.255.0.
 Now look at 10.0.1.5, an alias used for serving intranet web content to
 legacy machines. Again, a netmask of 0x.

 The reason for this is that 10.0.1.4, even though being an alias, is the
 first address the machine handles on that subnet. Just as 196.38.113.2 is
 the first address the machine has on the public subnet.

 Rule of thumb: First address on a subnet, alias or not, has the proper
 subnet netmask. Every other address on the subnet following that, has
 0x, or 255.255.255.255.

 Will


Thanks for clarifying this, Will. :) That was a very lucid and helpful
explanation.

- Mark


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message


Re: Bizarre Networking Problem

2003-02-20 Thread Bill Moran
Joseph Noonan wrote:

I have a really weird networking issue on my firewall box.  The
machine in question has an ethernet facing a cisco facing the
Internet and an ethernet facing the LAN plugged into a 3com
100Mbit switch.  My LAN has all of the servers and most of the
workstations sitting in the /24 that I've had for 10 years.  Some
of the newer workstations are now sitting on a /24 that I got from
one of my providers when I filled up the old space.

On xl0, the LAN ether, I simply added one of the new /24's to the
interface with an ifconfig -alias and thought everything was good.
And it was for users that only use the LAN for e-mail and www.
But when I added some users that started messing around with 25MB
pppts or 100MB .docs, the performance became pathetic, like in the
single or low double digit kbps.  The very same computer, can
download a 100MB file from the 'net over a T1 faster than it can
get a 50MB file off of my Samba based BSD file server.  If I
change the machines IP to one in the old /24 everything is fine
again.

Now it gets really weird.  Today, one of my associates was
investigating this problem and doing the experiments that document
the above facts on two different machine.  He called me and told
me what he found.  I logged into the firewall and started running
tcpdump against the one address and also looking at the firewall
logs to make sure I wasn't firewalling my own network.  A few
minutes later one of the users afflicted by this issue called to
thank me for fixing the problem.  I said eh?  I haven't done
anything other than look at the problem and I'm stumped.  He says
whatever, works great now!  My associate confirmed this on another
machine.

Well, it is true, I *did* do something: I put xl0 into promiscuous
mode.  But why oh why is that fixing what should not even be a
problem to begin with?

Any klews cheerfully accepted (including hitting me with a
clue-by-4 if I'm missing something obvious).


Somewhat of a shot in the dark, but ...
Is the routing possibly messed up such that an attempt to connect to
the aliased IP is being routed through the machine to the other IP on
the same interface?  I don't see why this would cause such terrible
performance, but it's the best guess I have with the information you
provide.
Perhaps some output form 'netstat -rn' and 'ifconfig' might provoke
some more useful answers.

--
Bill Moran
Potential Technologies
http://www.potentialtech.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message