Hi,

  Thanks for all of the replies, i cannot get access to the switch until Monday to obtain some of the info requested. The trunks are definately dot1q as i do not get the option to set encapsulation dot1q on the IOS for these interfaces. This is actually part of a another problem that i posted a while ago and still have not resolved, but i was hoping that this simpler scenario would point me in the right direction. I have run packet captures on the two switches and actually monitored the port that the router is connected to, i compared the packets that leave the swith and cannot see any difference between them, they are tagged and the packets seem to be the same. The issue in this problem is different from another post shown below in that i do see the 6500 switching the packets and directing them towards the router. The router is an ISP managed unit so i do not have acces to it. Basically i can see the end station sending a request out to a device on the WAN and it always gets a response (this packet is about 300bytes). It then makes a request to another device on a different subnet on the WAN with a 64byte packet and it never sees a response. Upon further testing i found that setting up a machine to mimic the end station that i could always ping the far end device with a command prompt but it fails when i use a utility like superscan. It seems that some packets get through and others dont but it is always the same packets that fail. This then starts to look the same as i original post below. The main difference between the two problems is that the with initial problem the 6500 does not seem to even switch the packets they just seem to disapear. There are no drops on interfaces and i have looked for the lost packets on all VLANS and i cannot find them anywhere. Please see original post below, i have modified this slightly following further investigation:

I have a strange problem on a pair of 6500's. The configuration is such that both units are connected together via a port channel dot1q trunk that allows all vlans. One of the switches is running the inter vlan routing with the gateway addresses for clients on the vlan interface of the switch. This unit is also running DHCP for the voice vlan. The problem is that when a phone is plugged into a voice/data enabled port on the non routing switch it fails connectivity to most other devices including the gateway configured on the 6500. I have run a span on the phone port and can see all of the dhcp requests fine and this works, but i do not see the arp requests to the gateway. I then plugged a hub into the phone port along with an analyser and can see the phone making the arp request to the gateway time after time with no response. I have checked the vlan id/ MAC addresses of packets and the arp/ MAC cache in both 6500's and this seems fine. Clearing the arp table on the routing 6500 allows connectivity. If i leave the phone connected for a while the connectivity seems to be OK, by which time the phone has given up looking for an ftp server. Interestingly if the FTP server is off of the 6500, i.e on a remote subnet it can always connect but it fails when it is trying to communicate with a local server on the same VLAN/subnet.Since the post i have now disabled the port channel and am just running a single dot1q trunk between the switches and i am still having the same problems. The routing switch is the root, but i have only just made this change.Everything shows OK in both MAC and ARP tables on the 6500's. I think the forwarding and VLAN/ARP is all good because if i plug a phone into a static non trunked port in either the data or voice vlan it just works. The problem i have is when the phone is in a voice vlan enabled port on the secondary 6500.

Thanks for you time in reading this rambling post.

Please note important change the VLAN 203 has been changed to 103.

The 6500 port in question is port gi1/18

This is the output from the 6509 when the 2924 is in line:

Port Mode Encapsulation Status Native vlan

Gi1/18 on 802.1q trunking 1

Gi3/17 on 802.1q trunking 1

Gi5/17 on 802.1q trunking 101

Po1 on 802.1q trunking 1

Port Vlans allowed on trunk

Gi1/18 1-4094

Gi3/17 2085

Gi5/17 101,104

Po1 1-4094

Port Vlans allowed and active in management domain

Gi1/18 1,101,103-104,303,2085

Gi3/17 2085

Gi5/17 101,104

Po1 1,101,103-104,303,2085

Port Vlans in spanning tree forwarding state and not pruned

Gi1/18 1,101,103-104,303,2085

Gi3/17 2085

Gi5/17 101,104

Po1 1,101,103-104,303,2085

This is when the 2924 is out of line:

Port Mode Encapsulation Status Native vlan

Gi1/18 on 802.1q trunking 1

Gi3/17 on 802.1q trunking 1

Gi5/17 on 802.1q trunking 101

Po1 on 802.1q trunking 1

Po2 on 802.1q trunking 1

Port Vlans allowed on trunk

Gi1/18 1-4094

Gi3/17 2085

Gi5/17 101,104

Po1 1-4094

Po2 1-4094

Port Vlans allowed and active in management domain

Gi1/18 1,101,103-104,303,2085

Gi3/17 2085

Gi5/17 101,104

Po1 1,101,103-104,303,2085

Po2 1,101,103-104,303,2085

Port Vlans in spanning tree forwarding state and not pruned

Gi1/18 1,101,103-104,303,2085

Gi3/17 2085

Gi5/17 101,104

Po1 1,101,103-104,303,2085

Po2 1,101,103-104,303,2085

I also tried restricting the trunk on the 6509 to only allow 1,103 vlan through, this again made no difference.

Perhaps more interestingly i can fix the problem if i plug the router into the SUP engine on port 6/2. The configs for the two ports are as follows:

interface GigabitEthernet1/18

description Uplink yo MPLS Router Switched- Video and RVA

switchport

switchport mode trunk

switchport nonegotiate

wrr-queue bandwidth 50 255

wrr-queue queue-limit 75 15

wrr-queue random-detect min-threshold 2 70 100

wrr-queue random-detect max-threshold 2 90 100

wrr-queue cos-map 1 2 0

wrr-queue cos-map 2 1 1 2 3 4

wrr-queue cos-map 2 2 6 7

spanning-tree portfast

end

Lon6509A#sh run int gi6/2

Building configuration...

Current configuration : 126 bytes

!

interface GigabitEthernet6/2

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

media-type rj45

end

Lon6509A#

This made me look more closely at the hardware when i found this:

CSCeb67650

or field notice

http://www.cisco.com/en/US/ts/fn/200/fn26096.html

as my cards fall into this serial number range