Power Connect 6224 VLAN routing and management VLAN

Daniel, thank you, your comments helped me get my head around this. Unfortunately I just spent a half hour typing up an informative summary of what all this means,to try to help the next guy out,  but this F'ing web page just blew it away when I clicked "this answered my question" or whatever that button is. Could have used a little Ajax there.

Anyways I got over the confusion. Use the CLI to set up one routable interface with a static IP on your regular subnet and put the management interface somewhere else. Then you can jump into the web utility and finish the job.

Thanks again for your reply.

Chris

Glad to hear you have made some progression. Could you post up your current running config? I can help look through it and see if i spot anything that needs to be changed or added. Also, what OS is installed on the devices you are pinging back and forth to?

Thanks

Ok, so this reply box apparently has an unadvertised input length limit and it cut off my configuration. Here's the rest of the running config starting with the 1/g2 from above:

!

interface ethernet 1/g2

switchport mode general

switchport general pvid 20

switchport general allowed vlan add 20

exit

!

interface ethernet 1/g3

switchport mode general

switchport general pvid 3

switchport general allowed vlan add 3

exit

!

interface ethernet 1/g4

switchport mode general

switchport general pvid 4

switchport general allowed vlan add 4

exit

!

interface ethernet 1/g10

switchport access vlan 10

exit

exit

Thanks for posting up the additional info. The VLAN configuration looks alright to me. On the port configuration i suggest sticking with access mode unless you need the port to receive tagged frames from multiple VLANs. As an example, port 4 would be access mode for VLAN 4.

I would also double check the IP settings on the clients. It sounds like they have an IP address in the correct subnet, but double check the default gateway and make sure it is set to the IP address of the VLAN. For example, device plugged into port 4 will be in access mode for VLAN 4, will have an IP address in the 192.168.4.x subnet, and will have a default gateway of 192.168.4.1.

Specifically windows 7 can sometimes have some issues replying to pings. May be worth looking into.

www.sysprobs.com/enable-ping-reply-windows-7

For directly connected subnets you should not need to create a static route.

Here's the running config. It's interesting to note that port 1/g1 does not appear in this output. I ran it twice to be sure. 1/g1 is on the default vlan, presently set to Access mode although I have tested it in General mode as well with the same results of no traffic beyond the interface port.

The other devices on the network include my laptop (Win7Pro), another laptop (some flavor of windows 7), Windows Server2008, and two ESXI hosts. All of these devices will answer pings from each other within their own subnets, i.e. from one to the other without involving the 6224, and will answer a ping when initiated from the 6224 CLI.

And what's with the route table in the 6224? I've been testing between vlan 1 and vlan 4 as shown in the config below. I never manually entered a static route definition yet these two appear in the route table. When I do try to create a manual route, the 6224 produces some error message that basically says it couldn't create the route, with no other useful information about why.

Here's the routing table as it appears with vlan 1 (1/g1) plugged into my main subnet, and a win7 laptop with a static ip plugged directly into vlan 4 (1/g4)

DPC6264-1#show ip route

Route Codes: R - RIP Derived, O - OSPF Derived, C - Connected, S - Static

      B - BGP Derived, IA - OSPF Inter Area

      E1 - OSPF External Type 1, E2 - OSPF External Type 2

      N1 - OSPF NSSA External Type 1, N2 - OSPF NSSA External Type 2

C      192.168.1.0/24 [0/1] directly connected,   vlan 1

C      192.168.4.0/24 [0/1] directly connected,   vlan 4

and here's the 6224 pinging that laptop:

DPC6264-1#ping 192.168.4.240

Pinging 192.168.4.240 with 0 bytes of data:

Reply From 192.168.4.240: icmp_seq = 0. time <10 msec.

Reply From 192.168.4.240: icmp_seq = 1. time <10 msec.

Reply From 192.168.4.240: icmp_seq = 2. time <10 msec.

Reply From 192.168.4.240: icmp_seq = 3. time <10 msec.

Here's the running config:

DPC6264-1#show running-config

!Current Configuration:

!System Description "PowerConnect 6224, 3.3.12.1, VxWorks 6.5"

!System Software Version 3.3.12.1

!Cut-through mode is configured as disabled

!

configure

vlan database

vlan 3-5,10,20,100

vlan routing 20 1

vlan routing 3 2

vlan routing 1 3

vlan routing 4 4

exit

snmp-server location "Exeter"

hostname "DPC6264-1"

clock timezone -5 minutes 0

stack

member 1 1

exit

ip address 192.168.10.1 255.255.255.0

ip address vlan 10

ip domain-name exeter.local

ip name-server 192.168.1.15

ip routing

interface vlan 1

routing

ip address 192.168.1.22 255.255.255.0

exit

interface vlan 3

name "SAN1"

routing

ip address 192.168.3.1 255.255.255.0

bandwidth 10000

ip mtu 1500

exit

interface vlan 4

name "SAN2"

routing

ip address 192.168.4.1 255.255.255.0

bandwidth 10000

exit

interface vlan 5

name "DMZ"

exit

interface vlan 10

name "internal management"

exit

interface vlan 20

name "vsphere"

routing

ip address 192.168.2.1 255.255.255.0

bandwidth 10000

ip mtu 1500

exit

interface vlan 100

name "internal user"

exit

!

interface ethernet 1/g2

switchport mode general

switchport general pvid 20

got some more progress here. I read somewhere that someone thought that vlan 1 was totally non routable. I thought that was kinda crazy, but I started up another 6224 from an empty config, set it up with vlan 1 and vlan 4, got no routing just like the first one, and then I replaced vlan 1 with a new vlan 100 on the same physical port (1/g1). All interfaces were Access mode.

This got me good routing from a device on vlan 100 to a device on vlan 4. Strangely though vlan 4 will still not route back to vlan 1.

So it appears that there is something magic about vlan 1. Maybe the OP was right, it's not routable. But I'm baffled now as to why the route won't go the other way.

This test configuration is starting to get fairly hacked up with multiple laptops hanging off various switch ports, mismatched vlans connected to each other, etc. All of that could still explain the no reverse route issue.

Any thoughts on the vlan1 no-routing idea?

By default VLAN 1 is the management VLAN and is not routable. If you use the command console(config)# ip address vlan 99

You can move the management VLAN and VLAN 1 will then be a normally routable VLAN.

Hi Josh, this is Chris, actually the original poster but under a different login. Something happened to my original account and it's broken now. Someone changed my user name or whatever its called that shows up on these posts to "csailinstyle", and now I can't create new posts or reply to existing ones under that login. WTF? So I created a new account and here I am.

Anyways,I foolishly failed to make clear in my last post that I had in fact moved the management interface off of vlan 1 as part of the intial configuration. I already knew that the management vlan is blocked from routing. But having moved it, and configured vlans 1 and 4 for routing, there was no routing action.

Second step, I created a new vlan 100 and did nothing but change my 1/g1 port config from vlan 1 to vlan 100 and voila routing worked from vlan 100 to vlan 4 with the same physical ports, same subnets, and same connected equipment.

So I have to conclude that either vlan 1 is never routable even though the switch allows you to enable routing on it, or there is a bug in the firmware that causes it to falsely remember something about having the management interface on vlan 1 even after you reassign it.

I was just looking through this KB articles:

www.dell.com/.../SLN285593

And it seems like the config is correct. So I am not sure why VLAN 1 is still not routable for you. If simply not using VLAN 1 at all, is producing positive results, I would continue down that path.

On a side note, sorry about the frustrations you have encountered on the forums. I have some moderator abilities, but it doesn't show me enough information to know why it has given you the issues it has.

Let us know if you run into any other issues with the switch.

I found that KB myself the other day... what I just realized after looking again to see what you had linked to me, is that the article's example leaves the management interface with no ip address at all. 0.0.0.0. and of course assigned to some vlan other than 1. In my tests I had been moving the mgt intf off to another vlan but also giving it a valid ip (completely separate subnet) for that interface. this may be the key. I'll test this when I have time and post results .If anything I hope this helps the next guy out. There is a disproportionate amount of discussion and confusion on several forums regarding routing and vlan 1 on the 62xx series switches. Whether this is a bug or just remarkably poor documentation, it has rendered what could have been a very easy-to-use and cost effective product into, well, something else entirely...

At this point, after numerous factory-resets and reloads of the configuration, the vlan 1 no routing issue won't reproduce. There are still other configuration issues but this thread was about vlan 1 routing so it's time to close it. Dan and Josh, thank you for your input.

hello, 

should all ports be in access mode or it can be trunked and assigned to many vlans ?