On Mon, 30 Aug 1999, Arthur Darren Dunham wrote:
NFS, CIFS, and HTTP requests are stored with the incoming interface. Their response is sent via the same interface.
That means that if the switch is round-robining the requests, the responses will also be pretty well distributed.
What happens when a request is larger than one ethernet frame? What happens if the response is larger than one ethernet frame. What happens if you send another request in while the first request is being output?
I don't believe that the NetApp implementation rememebers the interface on which the request came in. I think that it simply remembers the last interface on which a packet came in from a certain host. A sort of "arp" table.
If the requests are bunched up, so will the responses.
But the requests are a lot smaller than the responses so the one interface will be flooded while others will be sitting idle, right?
Is there any way to force a Cisco switch to round-robin traffic to a netapp like this? The one time I played with this configuration, the traffic was not well balanced at all.
I thought you said that it was pretty well distributed.
Tom
On Mon, 30 Aug 1999, Arthur Darren Dunham wrote:
NFS, CIFS, and HTTP requests are stored with the incoming interface. Their response is sent via the same interface.
That means that if the switch is round-robining the requests, the responses will also be pretty well distributed.
What happens when a request is larger than one ethernet frame? What happens if the response is larger than one ethernet frame. What happens if you send another request in while the first request is being output?
All the packets of a response are sent out the same port.
The next request doesn't affect the previous response.
I don't believe that the NetApp implementation rememebers the interface on which the request came in. I think that it simply remembers the last interface on which a packet came in from a certain host. A sort of "arp" table.
If you believe their white papers it does. The reason given is that this is faster than going through the routing table and calculating an outgoing interface. Instead, you just attach the incoming interface and source MAC address and send the response out the same port and to the MAC address. This will work with local hosts and routers alike.
But the requests are a lot smaller than the responses so the one interface will be flooded while others will be sitting idle, right?
Well, if your requests are round-robin, then as long as you're not sending traffic that has strange characteristics, they're still going to be distributed. You're right that a single large response will not be distributed.
Is there any way to force a Cisco switch to round-robin traffic to a netapp like this? The one time I played with this configuration, the traffic was not well balanced at all.
I thought you said that it was pretty well distributed.
My quote was... That means that if the switch is round-robining the requests, the responses will also be pretty well distributed.
If the requests are bunched up, so will the responses.
I've hooked up a SUN with SunTrunking 1.1 and it worked great (it had a round-robin setting), but that's just a single host.
-
Arthur Darren Dunham -
tkaczma＠gryf.net