Q-in-Q On Single Switch

[mparham6]

Hi all,

I'm wondering if it's possible to tunnel VLAN's across a single switch?  I made a quick drawing of what I'm working with in my environment.  The two radios are networked together via an Over The Air (OTA) link.  I'm using an Ixia traffic generation tool to push traffic over the network.  I'm using a Cisco 3850 as my switching device.  Essentially, I need to force the solid green VLAN 20, 30 and 40 traffic coming into my switch to only exit the switch on the respective egress ports connected to Radio 1, and the same for the dotted line traffic.  The VLAN numbers need to remain the same across the channels, otherwise they won't be able to communicate OTA.  How do I ensure that the VLAN 20 traffic coming into my switch intended for Radio 1 doesn't get flooded out to Radio 2 as well?  I researched possible tunnel configurations but I don't think configuring access ports along with tunnels to segregate traffic will work in this scenario.  Is there some other Cisco layer 2 capability that I'm unaware of that can accomplish this for me?  

Thank you for your time!

[pieterh]

you are talking about Q-in-Q, t's not clear to me where the Q-in-Q trunk is connected. to the Ixia test tool?

does this test tool recognizes q-in-q connections? and is able to separate this?

If so you mean the packets are already VLAN-tagged before they enter the switch?

and you regard data from one radio as a trunk, and two (q-in-q)trunked connections to the test tool?

you can reseach if the Cisco Private VLANs do the job for you.  (I would not call this Q-in-Q)

you have control over what ports can communicate with each other, it will not flood this to other vlans

create a private vlan for each radio connected to the test tool,

you may need a separate connection to the test tool for each radio, but each vlan20 will be separated

[Georg Pauwen · Accepted solution]

Hello,

my first thought was a MAC ACL. It might be a bit tedious because you will have to find the MAC addresses for all devices in your network, but it should work...

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/security/configuration_guide/b_sec_3se_3850_cg/b_sec_3se_3850_cg_chapter_01010.html#ID1832

[mparham6]

This is what I'm thinking as well. Only issue is that all three interfaces on the individual radios have the same MAC. For example:
Radio 1 - Channel 1 - xx.xx.xx.xx
Radio 1 - Channel 2 - xx.xx.xx.xx
Radio 1 - Channel 3 - xx.xx.xx.xx
Radio 2 - Channel 1 - yy.yy.yy.yy
Radio 2 - Channel 2 - yy.yy.yy.yy
Radio 2 - Channel 3 - yy.yy.yy.yy
All other MACs of the interfaces in this architecture are different, but with this I'm still not sure MAC ACL's will be the final solution.

[paul driver]

Hello

Do these radios devices connect to any switch at their own site for host connections for these vlans - if so you can apply L2 port protection ( switchport protect) -

With this applied no two ports with can speak to each but can speak to other ports that dont have it applied, so in theory you could apply this to say vlan 20 ports facing your ixia box and on vlan 20 ports on the backend of the radio devices that you dont wont to it speak to.

example
IXIA is able to speak to a radio 1 host in vlan 20 but not to a radio2 host in vlan 20:

IXIA port
switchport access vlan 20
switchport protect

Radio 2 host
switchport access vlan 20
switchport protect

Any alternative wold be vlan acls but then you need to know the hosts addressing witch could be administrative.

[pieterh]

I re-read your question, and I wonder if you have a problem at all?

if the test-tool can address the radio's individually it will be by L2 MAC address.

this is what a switch is made to do!!!!!

MAC-addresses are learned and saved in it's MAC-address / port-mapping table

and packets for radio 1 will be sent to port-1 and packets for radio-2 sent to port-2!

and even if a packet for radio2 is flooded to radio1, then radio1 should ignore it because it was not sent to it's mac-address?

(only if you are talking about broadcasts)

so are you looking to solve a problem that is not there?

no need for any tunnels or q-in-q.

[mparham6]

Thanks for the replies! Unfortunately the issue is that with the radios containing the same exact networking configs information generated by my test tool is being sent to both radios. Perhaps I'm not explaining it well enough, but I do believe there is a problem here. Your suggestion to use Prviate VLANs was a great one. As I was researching this it seems that it would do exactly what I need it to, but I would need the promiscuous ports to be trunks, as there is are several other VLANs (not pictured my diagram) that will be used simultaneously. From what I can read, this is only possible for 4500 switches and above.