I see the firmware level you have on the switch is 3.3.1.10.  I would consider updating the firmware to the most recent update 3.3.5.5 released 11/20/2012.  Here is link for the download:

www.dell.com/.../powerconnect-6224

I’m not certain this is something affecting your set up.  When you mentioned upgrading from 6024 to a 6224 then this came to mind:

General links are mostly used today for legacy equipment.  However, on the PowerConnect 62xx series switches, you must use General mode if you want to allow management traffic onto the switch over the PVID.  If you use Trunk mode, you will not have the default VLAN on those ports.  The ports will only allow tagged traffic.

General Links consist of a combination of VLAN Trunk and Access Links.

General Links can have both tagged and untagged frames, However, all frames sent to a specific VLAN must be tagged.  All untagged  frames are sent to the native VLAN.

The native VLAN still applies to the General LINK.  While it is possible to have multiple untagged vlans on a General link, you can only have ONE (1) PVID.  The PVID represents the native VLAN.  

While untagged traffic may be sent via several untagged VLANs, returning untagged traffic will only be received by the PVID and therefore will NOT be forwarded to a specific VLAN.

I will continue to look at the configurations that you have provided for any other possible suggestions for resolution.

I will be performing the firmware upgrade tonight. I really hope that it helps our situation.  If you need more background on our network, please let me know.

Thank you for the help!

Here is a question I should know but... If I have a switch that has jumbo frames configured. does the trunk port of that  switch that connects to the core need to have jumbo frames enabled too?

Also, i ran the statistics counter and most see ok, except for the one that connects to our point to point. Here are the errors i'm getting on port 44

RENCORESW01#show statistics ethernet 1/g44

Total Packets Received (Octets)................ 326902333190

Packets Received 64 Octets..................... 44847080

Packets Received 65-127 Octets................. 219738547

Packets Received 128-255 Octets................ 22330660

Packets Received 256-511 Octets................ 14207893

Packets Received 512-1023 Octets............... 7569813

Packets Received 1024-1518 Octets.............. 202519007

Packets Received > 1518 Octets................. 3546

Packets RX and TX 64 Octets.................... 130667934

Packets RX and TX 65-127 Octets................ 308223478

Packets RX and TX 128-255 Octets............... 46510420

Packets RX and TX 256-511 Octets............... 36731989

Packets RX and TX 512-1023 Octets.............. 16133396

Packets RX and TX 1024-1518 Octets............. 589228509

Packets RX and TX 1519-2047 Octets............. 3546

Packets RX and TX 2048-4095 Octets............. 0

Packets RX and TX 4096-9216 Octets............. 0

Total Packets Received Without Errors.......... 511213000

Unicast Packets Received....................... 511176137

Multicast Packets Received..................... 0

Broadcast Packets Received..................... 36863

--More-- or (q)uit

Total Packets Received with MAC Errors......... 3546

Jabbers Received............................... 0

Fragments/Undersize Received................... 0

Alignment Errors............................... 3546

FCS Errors..................................... 0

Overruns....................................... 0

802.3x Pause Frames Received................... 0

Unacceptable Frame Type........................ 3

Total Packets Transmitted (Octets)............. 592782496551

Packets Transmitted 64 Octets.................. 85820854

Packets Transmitted 65-127 Octets.............. 88484931

Packets Transmitted 128-255 Octets............. 24179760

Packets Transmitted 256-511 Octets............. 22524096

Packets Transmitted 512-1023 Octets............ 8563583

Packets Transmitted 1024-1518 Octets........... 386709502

Packets Transmitted > 1518 Octets ............. 0

Max Frame Size................................. 1518

Total Packets Transmitted Successfully......... 616282726

Unicast Packets Transmitted.................... 603829515

Multicast Packets Transmitted.................. 3195425

--More-- or (q)uit

Broadcast Packets Transmitted.................. 9257786

Total Transmit Packets Discarded............... 0

Single Collision Frames........................ 0

Multiple Collision Frames...................... 0

Excessive Collision Frames..................... 0

802.3x Pause Frames Transmitted................ 0

GVRP PDUs received............................. 0

GVRP PDUs Transmitted.......................... 0

GVRP Failed Registrations...................... 0

BPDU: sent 569869, received 0

EAPOL Frames Transmitted....................... 0

EAPOL Start Frames Received.................... 0

Time Since Counters Last Cleared............... 13 day 4 hr 34 min 8 sec

I pulled all the trunk/general mode interfaces configured for multiple VLAN to pass traffic (listed below) to get a better picture of what is connecting on your set up.  

interface ethernet 1/g2

interface ethernet 1/g4

interface ethernet 1/g8

interface ethernet 1/g13

interface ethernet 1/g18

interface ethernet 1/g19

interface ethernet 1/g20

interface ethernet 1/g45

interface ethernet 1/g46

interface ethernet 1/g47

interface ethernet 1/g48

interface port-channel 1

interface port-channel 2

I’m not seeing any configurations that are associating a physical interface into either of the port-channel interfaces.

The following example shows how port g5 is configured to port-channel number 1 without LACP.

Console (config)# interface ethernet 1/g5

Console (config-if)# channel-group 1 mode on

When setting up a port-channel with the channel group command.  The only configuration on the physical interface that is set for the port-channel is the channel-group command.  Then once the port-channel is set the switchport commands are configured on the port-channel and not the individual interfaces associated with the port-channel.

It may be helpful to look at the show interfaces counters [ethernet interface | port-channel port-channelnumber] command for each of the above interfaces to see if any abnormal traffic is revealed.

Page 299-301 of the CLI Guide discusses the definitions of the output of the show interfaces counters command.

support.dell.com/.../cli_en.zip

we were using port-channel for a little while and were having issues. so we removed the port from the port-channel. Will this cause issues the way it is?

I would suggest removing the configurations off the 2 port-channels if you are not using them.

Yes, if you have Jumbo Frames enabled at the access point you will need Jumbo Frames enabled on all the pass thru interfaces that the Jumbo Frames would need to pass.  If not you would be creating a bottle neck.  It's like when you are driving down a 4 lane highway and then you come up on some road construction and the 4 lanes go down to 1 lane.  You will inevitably have a traffic jam.

If there is a chance the Jumbo Frame traffic is going to traverse or is allowed to traverse over an interface then you will want Jumbo Frames enabled on that interface.  This will allow the larger packets to flow freely without any congestion on the network.

Last question on the jumbo frames. If sw1 has jumbo frames enabled, and the core has it enabled. will sw2 that is connected to the core also need it enabled? On occasion sw2 talks to sw1, but not always.