I swapped out our core switch that was a 6024 for a 6248. Since then, we have had nothing but problems. Pinging from a switch that is connected to one of the fiber ports and I'm getting very high latency. Sometimes I don't even get reply's back. It is the oddest thing I have ever seen.
I've messed with the arp and bridge times, flow control, and everything else and can't seem to fix it.
Any ideas? Below is the current running config
!Current Configuration: !System Description "PowerConnect 6248, 3.3.1.10, VxWorks 6.5" !System Software Version 3.3.1.10 !Cut-through mode is configured as disabled ! configure vlan database vlan 100-103,105-107,110,200,1000 ip igmp snooping 100 ip igmp snooping 101 ip igmp snooping 102 ip igmp snooping 103 ip igmp snooping 105 ip igmp snooping 106 ip igmp snooping 107 ip igmp snooping 110 ip igmp snooping 200 ip igmp snooping 1000 vlan routing 100 1 vlan routing 101 2 vlan routing 102 3
--More-- or (q)uit
vlan routing 103 4 vlan routing 105 5 vlan routing 106 6 vlan routing 107 7 vlan routing 110 8 vlan routing 200 9 exit hostname "RENCORESW01" sntp unicast client enable sntp client poll timer 1024 sntp server us.pool.ntp.org clock timezone -5 minutes 0 stack member 1 2 exit ip address 192.168.99.1 255.255.255.0 ip domain-name****.com ip name-server 192.168.100.70 logging console debug logging file debug no diffserv
--More-- or (q)uit
ip routing ip route 0.0.0.0 0.0.0.0 192.168.100.2 ip route 172.16.24.0 255.255.255.0 192.168.100.2 ip route 10.0.0.0 255.255.255.0 192.168.100.2 bootpdhcprelay maxhopcount 8 interface vlan 100 routing ip address 192.168.100.1 255.255.255.0 ip rip ip dvmrp ip igmp exit interface vlan 101 routing ip address 192.168.101.1 255.255.255.0 ip helper-address 192.168.100.70 ip rip ip dvmrp ip igmp exit interface vlan 102
--More-- or (q)uit
routing ip address 192.168.102.1 255.255.255.0 ip rip ip igmp exit interface vlan 103 routing ip address 192.168.103.1 255.255.255.0 ip igmp exit interface vlan 105 routing ip address 192.168.105.1 255.255.255.0 ip igmp exit interface vlan 106 routing ip address 192.168.106.1 255.255.255.0 ip igmp exit interface vlan 107
--More-- or (q)uit
routing ip address 192.168.107.1 255.255.255.0 ip helper-address 192.168.100.70 ip igmp exit interface vlan 110 routing ip address 192.168.110.1 255.255.255.0 ip helper-address 192.168.100.70 dhcp ip igmp exit interface vlan 200 routing ip address 192.168.200.1 255.255.255.0 ip igmp exit username "admin" password 7066e477d3a33162199fb9766ca8694b level 15 encrypted no flowcontrol spanning-tree priority 4096 bridge aging-time 1230 bridge multicast filtering
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:
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.
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?
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.
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.
DELL-Willy M
1 Rookie
•
802 Posts
887
1
Posted February 6th, 2013 16:00
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.