Aggregated Trunks via Wireless Bridges between C3750E switches

Unanswered Question
Jan 24th, 2010
User Badges:

Hi All,

We are in the process of mobing buildings.  Our key core switch in the old and the new buildings are C3750Es.  To facilitate the move, we installed two 100 Mb/s wireless links between the sites, and used PAgP (they don't support LACP) to aggregate them.  We run the ports and port channel as trunks.


The idea behind this was that we could "span" the VLANs between the sites and migrate hosts (over 200) from one to the other without having to do a lot of IP address changes.  Sounds reasonable enough?


Anyway, we have recently found some strangeness/slowness in our network.  The first symptom became evident when we moved a virtual server from the old site to the new one, whilst the VLAN gatway Interface is still at the old site.  Accessing the server seems fine, but a particularly traffic intense application was running like a dog.


So, a simple ping and traceroute showed nothing untoward.  Pings worked fine.  Traceroute from both a client and the server ends looked fine, except that it seemed that the server took longer to trace to the client.


Anyway, to eliminate a few things, we have moved the server into a VLAN only at the new site, to no avail.  We have tried clients in VLAN at the new site, and in VLANs at the old site with no real difference.


So I have then tried traceroute on the core switch to the client and server.  This is the really strange bit.

Ping to the client from the Old Building core switch:

mel-01-09-05-core1#ping 192.168.0.147

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.147, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms

Traceroute to the same client from the core switch:

mel-01-09-05-core1#traceroute 192.168.0.147

Type escape sequence to abort.
Tracing the route to moss.isg.unico.com.au (192.168.0.147)

  1  ?  ?  ?
  2  ?  ?  ?
  3  *  ?  ?
  4  ?  *  ?
  5  ?  ?  *
  6  ?  ?  ?
  7  *
mel-01-09-05-core1#

Ping and Traceroute from the New Building core switch:

5qr-5-core1#ping 192.168.0.147

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.147, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/17 ms
5qr-5-core1#traceroute 192.168.0.147

Type escape sequence to abort.
Tracing the route to moss.isg.unico.com.au (192.168.0.147)

  1 10.200.254.1 8 msec 8 msec 8 msec
  2  ?  ?  ?
  3  ?  ?  ?
  4  *  ?  ?
  5  ?  *  ?
  6  ?  ?  *
  7
5qr-5-core1#

10.200.254.1 is the IP address of the Old Building core switch.


Everything appears to disappear into the ether on a traceroute, but not a ping.


Also, if you look at Wireshark outputs on the server and the client during transactions, there is some delay between a sent packet and a received packet on each host.  So, something disappears or is routed somewhere for a while.


I am completely stumped by this and am seeking some advice as to where to look.  Both the core switches are sharing connected VLAN routes with EIGRP, and both report the correct routes, as evidenced by the successful pings. 


We have also recently been experiencing trouble with a Security Device at the new premises.  It has a controlling applicaiton that runs on a workstation in the Old premises and constantly talks to it.  It is in the same VLAN as the old premises security system.  It now intermittently stops communicating with the application, and cannot transfer large blocks of data.  So there is something very wrong, but no wrong enough to break things completely.


Any ideas on this would be greatly appreciated.  I have exhausted my experience and skills in nutting this out.

Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Actions

This Discussion