Exchange latency problem after cisco switch implementation

[dhaselhorst]

I recently upgraded our network with 9 2950's and 1 3560G switch. I've configured 2 vlans, one for servers and the other for clients and everything seems to work ok except communications to our exchange box. Since the upgrade users receive a message box "requesting data from microsoft exchange" several times during the day. For some users it only appears for a second or few seconds, others it's up for a minute or more.

I've run diagnostics on the exchange box and everything there seems to be ok, but i'm wondering if maybe I missed something in the port configuration on the switches that would cause this type of latency problem. Anyone ever see anything like this before?

Regards,

Dave

[Adam Frederick]

Dave;

What type of Exchange setup are you using? IMAP, POP3, etc. Also, what are you 5 largest mailboxes. Off the top of my head, I think you can find this info by going into Exchange System Manager, Servers, "servername", First Storage Group, Mailboxes.

I have definately seen throughput problems when an end system is setup for autonegotiation and the switch is strapped and vice versa. Ensure the port is strapped on both the switchport and the exchange box.

If this does not correct, verify your path end-to-end (i.e. any trunk links, access links). Check this and let us know.

Thanks,

Adam

[dhaselhorst]

5 Largest mailboxes are from 3.5-4.2 GB in size.

Exchange setup is SMTP. Some of the people with these mailboxes are not experiencing problems.

The NIC cards (2) on the exchange box are configured to auto-negotiate 1000mbps. The two ports on the switch which these plug into are set to auto.

What do you mean when you say the "switch is strapped and vice versa ...ensure the port is strapped on both the switchport and the exchange box?"

The trunk links are configured correctly. If I move workstation ports to VLAN100 (location of all servers) the latency problems go away.

[cro9uk]

I had this problem at one site. The issue at the time was due to late collisions caused by duplex mismatches on the switch. Simply telnet into your switches do a "term mon" and monitor them for a while, duplex issues will usually appear every few seconds. When this happens, it slows everything down, remember to also check this on your router if clients are coming in via this path.

[dhaselhorst]

I've got this running on all my switches right now, but I only see a couple of items:

002264: Apr 17 15:47:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/15, changed state to down

002265: Apr 17 15:47:28: %LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to down

I have those types of messages on 2 switches and it is only one set. It does not continue.

[globalnettech]

Hello,

on your VLAN interfaces, try and configure:

interface Vlan2

--> ip tcp adjust-mss 1350

and check if that makes a difference.

Regards,

GNT

[dhaselhorst]

Should this be all VLAN interfaces or just the one the exchange server resides in? I looked up this command and it states it is used to keep tcp sessions from being dropped. Is there a command that shows the number of sessions which have been dropped on the switch?

the show interface command only gives me this:

GigabitEthernet0/27 is up, line protocol is up (connected)

Hardware is Gigabit Ethernet, address is 0014.a9fb.bd9b (bia 0014.a9fb.bd9b)

Description: Exchange

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX

input flow-control is off, output flow-control is unsupported

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 00:00:01, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 210000 bits/sec, 22 packets/sec

5 minute output rate 29000 bits/sec, 10 packets/sec

71823404 packets input, 1002585060 bytes, 0 no buffer

Received 1121971 broadcasts (0 multicast)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

22824962 packets output, 3874554074 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

[dtushing123]

How are you routing packets from one VLAN to the other?

When you put a workstation in the same VLAN as the exchange server there is no problem, seems like the Exchange server to switch connection is fine.

[dhaselhorst]

Cisco 3560G

Ports 2-40 configured for VLAN100 (all servers are located on this switch)

Ports 41-48 are trunk links

The 3560 is routing the packets via inter-vlan routing

Cisco 2950 (9 of these)

All ports configured for VLAN200 access (all clients are on these). the GIG0/01 and/or gig0/02 are configured as trunk ports which plug directly into a port (41-48) on the 3560.

[mbalasko]

This really does sound like a duplex mismatch issue, yet the output of your sh int command shows that port clean. What about the ones with the users having issues? Your looking for crc/runt counters to increment. With the users that are having issues, is there any packet loss associated with those workstations? You can check this with the pathping command from a command prompt. If you see any I'd really start staring down the duplex mismatch path.