Data transfer to multhomed server flooding network.

OK, this has just started happening, and that is another puzzle that
I'm addressing elsewhere.

Anyway, here what's happening.

I start a large (100's of GB as in a backup scenario) data transfer to
a multihomed server (Windows Server 2003 SP1). The IP addresses for
the adapters in the server are on the same subnet.

After about five minutes, the network is flooded with the data from
the source computer.

Looking at the switch, and analyzing Ethereal traces we see that the
packets from the source computer are being directed to the first mac
addy on the server, but the responses from the server back to the
client are originating from the second mac addy on the server. From
what I have discovered so far this could be normal behavior.

The switch (Cisco 2950), however uses the source address of a packet
to maintain its mac table (so I've been told by the resident switch
gurus), and since it is not seeing anything coming from the first mac
addy on the server, it drops that address from the mac address table
at the end of the timeout for such things (currently five minutes -
see above).

Then when the client computer sends another packet out, the switch,
not seeing the destination mac addy in its table, floods all of it's
ports with that packet. And, because the server is sending responses
out the second interface, the mac table on the switch is not getting
updated, and after a few minutes of flooding, nobody is getting
anything done on the network.

I've got several ways to work around this, but I would like to hear
comments from others.

One specific question I have is if there is a way to force a response
to be sent back via that mac addy the request packet was received on?

And, as I opened the message, we're still trying to determine why this
has just started happening. This configuration has been online for a
number of months, and of course, nobody has changed anything.....

Any and all input would be appreciated.

TIA

D

Really interesting problem

You can try to later your routing table (on a server), so that it will
use correct interface for responses.

Now, as I can see, you have such situation:

routing table on server contains string like:

192.168.0.x 255.255.255.0 192.168.0.<second IP> 192.168.0.<second IP>


But you use some <firstIP> to establish connection. So, server uses
interface, which has address <secondIP> and forms frames with it's MAC
address...

You can.
1). Use <secondIP> for connections.
2). Add to routing table entry with command:

route add /p <your src addr> mask 255.255.255.255 <firstIP> IF
<interface number>



--
With best regards
Nickolay Domukhovsky, MCSA

"dhodgeh" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ps.com...
> OK, this has just started happening, and that is another puzzle that
> I'm addressing elsewhere.
>
> Anyway, here what's happening.
>
> I start a large (100's of GB as in a backup scenario) data transfer to
> a multihomed server (Windows Server 2003 SP1). The IP addresses for
> the adapters in the server are on the same subnet.

Ok, no need to read futher. There's the problem. You cannot use the same subnet
on the nics. Each nic in the server needs to be a different subnet.

The only way to make the traffic flow over the right path is the make up "fake"
names for the machines that are associated with the "other" subnet and place
these in either host file or manually enter them in the DNS Server.

But the whole thing might be a waist of time based on a misconception of what
the "separation of traffic" is really like and how it works. On a fully
switched network all the traffic is *already* separated,...that is what switches
do. The reason you are getting flooded is because in your backup scenerio the
data is traveling over the same wire that other traffic is using and saturating
the physical wire. This is because the switches are not wired with the correct
physical layout compatible with what you are doing.

The servers being backed up and the ones recieving the backup data need to be on
the same switch and the switch needs to be of commercial quality (not home user
quality) so the Backplane of the switch can handle the traffic. If they can't
be on the same switch than pay careful attention to how you cable things up so
that the backup data isn't sharing a wire with everyone else. In the process of
doing that do not create any layer2 switching loops because STP will shut one
down to break the loop and you will be in an even bigger mess.

If you choose to use the two-subnet method then you have to do the fake names
like I described and make sure that everything involved in making the backup
"happen" uses these fake names so that it all resolves to the correct IP# and
the traffic follows the correct path.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft, or
anyone else associated with me, including my cats.
-----------------------------------------------------