Make Netgate XG-7100 and Cisco Mobility Express work together on 2nd WLAN
-
@stephenw10 said in Make Netgate XG-7100 and Cisco Mobility Express work together on 2nd WLAN:
My own theory is that it's actually cheaper now to use a switch chip that supports VLANs even if you don't expose the option to do so.
Given the frame expansion to support VLANs has been around for 20 years, any device compliant with the current spec will allow them. The only significant difference with a VLAN frame is the contents of the Ethertype field and the 4 extra bytes to hold the tag. Older gear, that supports only 1500 bytes, would fail, as the VLAN frame would be too big. In that case, just reduce the MTU on the network to 1496 and problem solved.
-
Here's some info about the Ethernet specs. Frame expansion to support VLANs came in with 802.3ac in 1999 and was incorporated into the base spec with 802.3-2002 in 2002. So, any gear compliant with 802.3-2002 or later must be able to pass VLANs, regardless of whether it's capable of being configured for VLANs.
-
Yup, that's all true. But if you set a 5 port switch chip in 802.1q mode and just put all the ports in VLAN1 it will appear as an unmanaged switch but won't pass VLANs. That's what you get in a SOHO device with a built in switch.
Steve
-
@stephenw10 said in Make Netgate XG-7100 and Cisco Mobility Express work together on 2nd WLAN:
Yup, that's all true. But if you set a 5 port switch chip in 802.1q mode and just put all the ports in VLAN1 it will appear as an unmanaged switch but won't pass VLANs. That's what you get in a SOHO device with a built in switch.
Steve
That would be QinQ, which became part of the VLAN spec with 802.1ad in 1998. Try an experiment with that 5 port switch you mentioned (Why does the number of ports have anything to do with this?). Ping with a VLAN tag and then try a file transfer spanning multiple frames. If the ping passes, but the full MTU frames the file transfer fail, then you're hitting a hard limit. If the switch complied with 802.3-2002, but not later, then you might run into that problem. However, later specs, providing for larger frames would not have that issue. 802.3as, which supports up to 2K bytes appeared in 2003. Since then supported frame sizes have increased significantly. 9K jumbo frames are commonly used now and some SOHO level switches support up to 16K.
-
The number of ports obviously has nothing to do with it. I only chose that because they are commonly built into soho routers which is where I have hit this most often.
It has nothing to do with frame size. If that is a problem it's something else I'm not referring to here.
If the switch chip is configured for .1q mode it will drop packets tagged for any VLAN it's not configured with.Anyway this is not helping the OP so that's all from me.
Steve
-
I apologize guys. We had to scramble a bit because of a 2-drive crash on a nas, incident reports, UGH.
etherswitchcfg output is:
===========================
etherswitch0: VLAN mode: DOT1Q
port1:
pvid: 4080
state=8<FORWARDING>
flags=0<>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
port2:
pvid: 4081
state=8<FORWARDING>
flags=0<>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
port3:
pvid: 4082
state=8<FORWARDING>
flags=0<>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
port4:
pvid: 4083
state=8<FORWARDING>
flags=0<>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
port5:
pvid: 3001
state=8<FORWARDING>
flags=0<>
media: Ethernet autoselect (none)
status: no carrier
port6:
pvid: 3001
state=8<FORWARDING>
flags=0<>
media: Ethernet autoselect (none)
status: no carrier
port7:
pvid: 3001
state=8<FORWARDING>
flags=0<>
media: Ethernet autoselect (none)
status: no carrier
port8:
pvid: 3001
state=8<FORWARDING>
flags=0<>
media: Ethernet autoselect (none)
status: no carrier
port9:
pvid: 1
state=8<FORWARDING>
flags=1<CPUPORT>
media: Ethernet 2500Base-KX <full-duplex>
status: active
port10:
pvid: 1
state=8<FORWARDING>
flags=1<CPUPORT>
media: Ethernet 2500Base-KX <full-duplex>
status: active
laggroup0:
members 9,10
vlangroup0:
vlan: 1
members none
vlangroup1:
vlan: 4080
members 1,9t,10t
vlangroup2:
vlan: 4081
members 2,9t,10t
vlangroup3:
vlan: 4082
members 3,9t,10t
vlangroup4:
vlan: 4083
members 4,9t,10t
vlangroup5:
vlan: 3001
members 5,6,7,8
vlangroup6:
vlan: 3003
members 9t,10t========================
-
I read that the ports in an unmanaged switch will just forward anything that is thrown at them which includes tagged and untagged traffic so this challenge I'm having is in the interaction between the virtual wireless controller and the XG-7100.
Guys, fyi, this thread has been very informative for me and made "read more to learn more". Thanks I appreciate this.
-
@noel-alanguilan said in Make Netgate XG-7100 and Cisco Mobility Express work together on 2nd WLAN:
I read that the ports in an unmanaged switch will just forward anything that is thrown at them which includes tagged and untagged traffic
Yep. That's the point I often have to make. You'd be surprised at the number of people who don't understand that. They seem to think there's something magic about VLANs that cause an unmanaged switch to choke on them.
Incidentally, my experience with Ethernet goes back almost 35 years, to the days of DECNet over 10Base5. My LAN experience goes back to 1978, with a proprietary Rockwell Collins system that used time slots, rather than packets. As I came up as a tech, working hands on with the hardware, I tend to get fussy with the details. Also, I'm probably the only one here who has actually hand wired an Ethernet controller, built on a prototyping board with discrete logic ICs.
-
Ok there are several problems there.
Which port on the XG-7100 is connected to Unmanagedswitch1? It looks like it's probably on LAN so that would be port 2 only.
That is the port you need VLAN3003 to be tagged out on.
The switch config for vlan 3003 should read:
vlangroup6: vlan: 3003 members 2t,9t,10tThe actual VLAN group number there is not relevant. VLAN 3001 appears to be something else there.
EDIT: Moved out of wireless, this isn't a wifi issue.
Steve
-
I must apologize to everyone who replied to this thread for being absent. The XG-7100 just stopped responding via web on all interfaces one Sunday and I just had to take care of that issue first before proceeding to this thread. fyi, the XG-7100 was throwing filesystem full messages via console and everything slowed down to a crawl. I was able to do a reset to factory, restore from backup and all is well again but under observation. this is for another thread.
Yes, the XG-7100 is connected to Unmanagedswitch1 via LAN (port2). Okay, i'll try that switch config in a bit and report back.
Thanks for moving this to the proper area, Steve.
