cyc-01
asked on
Migrating to a layer 3 network -- have it working but confused.
Hello,
This is a 2 part question and is a bit complex (at least to me).
Our situation:
We currently have a flat network and we are moving to a layer 3 network (obviously with multiple vlans.
Our equipment consists of:
2xDell 6248 (stacked and fully layer 3)
1x2824 (layer 2 "managed" w/ vlan support). Managed is in quotes because it is very basic. Most configuration has to be done via the web interface -- as the cli is missing many of the commands that the 6248 would have. For example: Vlan creation can only occur via the web interface.
This is uplinked to the 6248 over a single copper connection
1x2848 (same as the 2824 but with 48 ports). This will be connected via LAG (4 ports) to the 6248. This is not done yet and not part of the equation (yet).
The first 48 ports of the 6248 are set to access mode for Vlan 100 (untagged). On stack member 2, port 40 is connected to the 2824. The port is set to general mode and the settings are as follows:
pvid 100. My understanding is that this will actually forward the untagged packets as Vlan 100.
All packets are admitted and ingress filtering is enabled.
Additionally, this port is a member of Vlan 500 (Tagged)
On the 2848:
All ports except for 23 and 24 are members of Vlan 100 (untagged). However, it does not seem to matter if I make these ports members or not. As, any connection that is vlan 100 works on these ports. IE the ports can be members of the Vlan 1 (default) and a vlan 100 (untagged) client can still communicate.
Port 23 (Uplink port)
Is a member of Vlan 1, can admit all and Ingress filtering is enabled.
Port 24 is a member of Vlan 500, can admit all and Ingress filtering is enabled.
This all works. I can place members of vlan 100 on the 2824 and they can communicate with the rest of the network. These connections are untagged. I can place a vlan 500 member (untagged as well) on port 24 and it can communicate with all of the other vlans.
Now for my problems:
My understanding is that trunk connection is the usual way of connecting switches. However, this does not work --- I can only communicate with the 2824 when set to general with the configuration above. I am assuming that this is because of the limitations of the 2824 -- as it has no explicit way to set the access mode of the ports. It appears that all of the ports are set to access. Is this the reason or is there something else I am missing?
Additionally, it seems that general mode is more flexible in trunking. Should I just use general anyway when connecting to switches/firewalls etc?
Now for my other question:
I have all of this working but I am confused by how it works. Meaning, how can the 2824 operate correctly for Vlan 100, 500. My problems:
Ports 1-22 will work properly for vlan 100 regards if they are to Vlan 100 or Vlan 1. Why is this?
Port 23 (uplink) is set to Vlan 1 and it works. Any other setting seems to cause problems. As such, Vlan 100 and Vlan 500 pass through. This is very confusing -- as I would think, that the Ingress filtering would discard the frames that don't match vlan 1.
My best guess is that I am not actually passing tagged vlans from the 6248 (though the settings would seem otherwise). However, if this is the case then how exactly can vlan 100 and vlan 500 work correctly?
I hope all of this makes sense --- feel free to ask for clarification etc.
______
Added by _alias99 per author's request:
NOTE: despite what I wrote above, the uplink ports on both switches are tagged for 100 and 500. I misread my notes and typed in something that was clearly wrong (engage autopilot).
This is a 2 part question and is a bit complex (at least to me).
Our situation:
We currently have a flat network and we are moving to a layer 3 network (obviously with multiple vlans.
Our equipment consists of:
2xDell 6248 (stacked and fully layer 3)
1x2824 (layer 2 "managed" w/ vlan support). Managed is in quotes because it is very basic. Most configuration has to be done via the web interface -- as the cli is missing many of the commands that the 6248 would have. For example: Vlan creation can only occur via the web interface.
This is uplinked to the 6248 over a single copper connection
1x2848 (same as the 2824 but with 48 ports). This will be connected via LAG (4 ports) to the 6248. This is not done yet and not part of the equation (yet).
The first 48 ports of the 6248 are set to access mode for Vlan 100 (untagged). On stack member 2, port 40 is connected to the 2824. The port is set to general mode and the settings are as follows:
pvid 100. My understanding is that this will actually forward the untagged packets as Vlan 100.
All packets are admitted and ingress filtering is enabled.
Additionally, this port is a member of Vlan 500 (Tagged)
On the 2848:
All ports except for 23 and 24 are members of Vlan 100 (untagged). However, it does not seem to matter if I make these ports members or not. As, any connection that is vlan 100 works on these ports. IE the ports can be members of the Vlan 1 (default) and a vlan 100 (untagged) client can still communicate.
Port 23 (Uplink port)
Is a member of Vlan 1, can admit all and Ingress filtering is enabled.
Port 24 is a member of Vlan 500, can admit all and Ingress filtering is enabled.
This all works. I can place members of vlan 100 on the 2824 and they can communicate with the rest of the network. These connections are untagged. I can place a vlan 500 member (untagged as well) on port 24 and it can communicate with all of the other vlans.
Now for my problems:
My understanding is that trunk connection is the usual way of connecting switches. However, this does not work --- I can only communicate with the 2824 when set to general with the configuration above. I am assuming that this is because of the limitations of the 2824 -- as it has no explicit way to set the access mode of the ports. It appears that all of the ports are set to access. Is this the reason or is there something else I am missing?
Additionally, it seems that general mode is more flexible in trunking. Should I just use general anyway when connecting to switches/firewalls etc?
Now for my other question:
I have all of this working but I am confused by how it works. Meaning, how can the 2824 operate correctly for Vlan 100, 500. My problems:
Ports 1-22 will work properly for vlan 100 regards if they are to Vlan 100 or Vlan 1. Why is this?
Port 23 (uplink) is set to Vlan 1 and it works. Any other setting seems to cause problems. As such, Vlan 100 and Vlan 500 pass through. This is very confusing -- as I would think, that the Ingress filtering would discard the frames that don't match vlan 1.
My best guess is that I am not actually passing tagged vlans from the 6248 (though the settings would seem otherwise). However, if this is the case then how exactly can vlan 100 and vlan 500 work correctly?
I hope all of this makes sense --- feel free to ask for clarification etc.
______
Added by _alias99 per author's request:
NOTE: despite what I wrote above, the uplink ports on both switches are tagged for 100 and 500. I misread my notes and typed in something that was clearly wrong (engage autopilot).
ASKER
The uplink ports on the 6248 and 2848 are tagged. I am just using general mode and not trunking. My issue is not with the uplink (other than I could not use trunking)*. My issues are with how the 2848's ports are configured. Example: The ports can be set to vlan 100 or vlan 1 and the effect is the same: vlan 100 works. Plus there additional issues with the setup (other than the uplink) on the 2848 (see above).
*I got confused and omitted that port 23 is tagged for vlans 500 and 100. I will try to edit the question and fix.
*I got confused and omitted that port 23 is tagged for vlans 500 and 100. I will try to edit the question and fix.
ASKER
A very large correction to my original question:
I don't know how I managed not to write this:
Port 23 on the 2848 (the uplink) is tagged for vlan 100 and Vlan 500. I misread my notes and typed in something that was clearly wrong.
I don't know how I managed not to write this:
Port 23 on the 2848 (the uplink) is tagged for vlan 100 and Vlan 500. I misread my notes and typed in something that was clearly wrong.
I can't be sure on the specifics without a diagram, but I can clarify some things:
pvid is the default vlan ID of the port. so whatever device is plugged into that port, the packets are assigned (not tagged) that vlan id.
So lets call it pvid 100 (like your example). Whichever port those packets go out, if that port is set as T vlan 100, they are tagged vlan 100. If those packets go out a port that is U vlan 100, they are untagged. If they are going to another switch and they are untagged, they get assigned (not tagged) the pvid of that port.
So when you use vlan1 and it leaves the switch untagged (becuase you only tagged vlan 100 and vlan 500, it gets to the other switch and assumes the pvid of that port which I think is 100 but again, without a diagram its hard to be sure.
pvid is the default vlan ID of the port. so whatever device is plugged into that port, the packets are assigned (not tagged) that vlan id.
So lets call it pvid 100 (like your example). Whichever port those packets go out, if that port is set as T vlan 100, they are tagged vlan 100. If those packets go out a port that is U vlan 100, they are untagged. If they are going to another switch and they are untagged, they get assigned (not tagged) the pvid of that port.
So when you use vlan1 and it leaves the switch untagged (becuase you only tagged vlan 100 and vlan 500, it gets to the other switch and assumes the pvid of that port which I think is 100 but again, without a diagram its hard to be sure.
ASKER
pvid issue:
My understanding is that Dell handles this different when set to general access mode. The dell forums seem to indicate general access actually tags with the pvid*. So there is no way for the pvid ever to be utagged (even if you specifically say it is). Of course, this is in the forums and has to be taken with a grain of salt. I assume it is true, otherwise I would think the connectivity would fail (unless 2848 is tagging).
*How I found this is that when I configured the port as tagged the connectivity would fail. I searched the forums and someone had the same problem. The solution was that general mode pvid already tags and you should just leave it as untagged (otherwise it will fail). Sounds odd to me but there are other oddities like the default vlan on the 6248 does not route and is not meant to be used for anything other than management.
My understanding is that Dell handles this different when set to general access mode. The dell forums seem to indicate general access actually tags with the pvid*. So there is no way for the pvid ever to be utagged (even if you specifically say it is). Of course, this is in the forums and has to be taken with a grain of salt. I assume it is true, otherwise I would think the connectivity would fail (unless 2848 is tagging).
*How I found this is that when I configured the port as tagged the connectivity would fail. I searched the forums and someone had the same problem. The solution was that general mode pvid already tags and you should just leave it as untagged (otherwise it will fail). Sounds odd to me but there are other oddities like the default vlan on the 6248 does not route and is not meant to be used for anything other than management.
I have not used these switches specifically so I can't comment on any oddities with them. I personally don't use the default vlan except for some management computers to admin the switches.
The confusing part for me when learning this stuff was the difference between actually tagging the packet and just assigning the vlan internal to the switch. usually it's only tagged internally if the pvid of the source port is not the pvid of the destination port. But even then the tag is stripped on leaving the port if the destination port has the source pvid vlan as untagged.
The confusing part for me when learning this stuff was the difference between actually tagging the packet and just assigning the vlan internal to the switch. usually it's only tagged internally if the pvid of the source port is not the pvid of the destination port. But even then the tag is stripped on leaving the port if the destination port has the source pvid vlan as untagged.
ASKER
So I dug some more and not surprisingly, the dell forum is incorrect.
I do know why it is working though: any untagged frames the 6248 receives from the uplink are classified into vlan100. Otherwise it is working because the 2824 is doing the tagging. My suspicion is that it is the former (as the 2824 implementation of vlans is barely there).
It is still odd that setting the port to tagged on the 6248 breaks the whole thing. IE If you set it to tagged, then you can no longer ping/connect to any of the clients on the 2824 (regardless of vlan).
I know this is working but my fear is that this is only cosmetic. That something underneath is broken and I am going to introduce something very bad into our network.
I do know why it is working though: any untagged frames the 6248 receives from the uplink are classified into vlan100. Otherwise it is working because the 2824 is doing the tagging. My suspicion is that it is the former (as the 2824 implementation of vlans is barely there).
It is still odd that setting the port to tagged on the 6248 breaks the whole thing. IE If you set it to tagged, then you can no longer ping/connect to any of the clients on the 2824 (regardless of vlan).
I know this is working but my fear is that this is only cosmetic. That something underneath is broken and I am going to introduce something very bad into our network.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
aarontomosky: I think I understand what you are saying and why it works. In other words, it looks like this configuration will not have any unnecessary consequences.
Before I close this out, do you have any idea why it does not matter what vlan is assigned to the ports on the 2824 (other than port 24 and port 25)? Like I said, I can just assign the default vlan (1) to the other ports (with ingress filtering on) and any vlan 100 client on those ports still works.
Before I close this out, do you have any idea why it does not matter what vlan is assigned to the ports on the 2824 (other than port 24 and port 25)? Like I said, I can just assign the default vlan (1) to the other ports (with ingress filtering on) and any vlan 100 client on those ports still works.
I don't understand how you have a vlan 100 client on a pvid 1 port
ASKER
I did figure out why it is working with pvid 1 port (at least I think it did).
The 2824 is barely a managed switch and is missing a lot of what is standard in other switches. Example: cannot set trunk ports, CLI is crippled, no way to associate ips with a vlan etc.
What is happening is that the uplink port is set to pvid 100 and it has ingress filter enabled (it is also set to allow vlan 500 (tagged). Which means, if it receives something from vlan 1 (untagged) then it simply sets it to pvid 100. I think this would even work if vlan 1 was tagged -- as the ingress filter would strip that away.
This stuff can make your head hurt.
Either way, this oddness is because we have to use the 2824 intermixed with real layer 3 switches. Our budget does not allow otherwise.
The 2824 is barely a managed switch and is missing a lot of what is standard in other switches. Example: cannot set trunk ports, CLI is crippled, no way to associate ips with a vlan etc.
What is happening is that the uplink port is set to pvid 100 and it has ingress filter enabled (it is also set to allow vlan 500 (tagged). Which means, if it receives something from vlan 1 (untagged) then it simply sets it to pvid 100. I think this would even work if vlan 1 was tagged -- as the ingress filter would strip that away.
This stuff can make your head hurt.
Either way, this oddness is because we have to use the 2824 intermixed with real layer 3 switches. Our budget does not allow otherwise.
ASKER
Your info allowed me to work out the question/problems we are having. IE. your info on tagging and pvids pointed me in the right direction. Without that, I would still be wondering if what we are doing is "correct" or not.
Untaged anything on an uplink tO another switch will make your brain hurt.