Private Vlan in a ROAS scenario - Not working

[tlxbx]

I am testing a PVLAN scenario in a lab environment. The goal is to implement it in production eventually. Please see attached topology I am working on. I read when implementing PVLAN in a ROAS situation we have to implement a Private VLAN trunk which my switch lacks the feature of(Cat9400) but I am testing the below scenario to understand why..

Scenario 1: When I ping from Host(192.168.100.6) to R1(192.168.100.1), the frame is tagged with dot1q VLAN 101 in the Trunk port & SW1 fwds the broadcast frame via its promiscuous port to R1 but R1 never responds. Why? Is it bcoz SW1 never re-writes the secondary VLAN 101 to primary VLAN 100 before sending it to R1? If so why it doesn't do it?

Scenario 2: When I initiate a ping from the R1(192.168.100.1) to the host(192.168.100.6), R1 sends ARP broadcast with tagged VLAN 100, SW then fwds the frame via its trunk port to Sw2 but keeps the dot1q VLAN 100, it reaches the Host & host replies the ARP request with tagged VLAN 101 and received by R1 but never responds. Why?

I did a PCAP so when I say it receives the packet I see it sending out on the wire at least but I assume R1 never processes the ARP. 

Any help to understand this would be highly appreciated. Thank you in advance.

@Peter Paluch I have seen your responses on this topic and have helped me gain clarity. Tagging to get your attention   

[tlxbx]

Bump. Anyone?

[Peter Paluch]

Hello @tlxbx ,

I'm honored!

For Scenario 1: I don't know how is the g0/0 on SW1 configured but I suspect it is a promisc port, right? If so, a promisc port is untagged. Every secondary VLAN (isolated or community) that is mapped with it can talk through a promisc port, but a promisc port itself behaves as an access port - with the device attached to the promisc port able to talk to anyone in the associated secondary VLANs. Hence, if the g0/0 on SW1 is truly configured as a promisc port then the traffic that leaves this port is always untagged. If the ROAS router expects tagged traffic to arrive on its g0/0 port, it won't see it - it only sees untagged traffic. So in this case, you would need to configure the ROAS to expect the traffic to be untagged, and obviously, to also respond without tags.

For Scenario 2: VLAN 100 is the primary VLAN here, and traffic tagged with the primary VLAN is an indication to all PVLAN-capable switches that the frame was received on a promisc port. Hence, this tag needs to be maintained because every receiving switch needs to understand that this frame comes from a promisc port, and so can be validly replicated to any port in any of the secondary VLANs. It does not in fact matter that the ROAS router sent out the frame tagged with VLAN 100; what matters is that this frame was received on a promisc port associated with primary VLAN 100 and a set of secondary VLANs, and so the switch would tag that frame with VLAN 100 anyway any time it forwards it out a trunk.

Please feel welcome to ask further, and apologies for a late response!

Best regards,
Peter

[tlxbx]

Thank you @Peter Paluch Your assumptions on connections are correct and it helps. One new scenario if you could explain the behavior 

Scenario: Two L3 switches. Uplink switch host the L3 SVI with private-VLAN mapping. An isolated PVLAN host downstream tries to ping the L3 GW .1 but when I do a pcap capture the switch never forwards the Broadcast request via it's trunk port to the upstream switch. Why is that? Is it bcoz an isolated port can ONLY talk to a promiscuous port? If L3 is hosted on a switch then where would be my Promiscuous port? Will it be the Port that connects the WAN device? Basically, how can my isolated host goes out to the internet?

[Peter Paluch]

Hello @tlxbx ,

This last scenario does not make sense. A frame received on a port in secondary isolated VLAN can be sent out of

• any classic trunk port where the secondary VLAN is permitted (to reach remote promisc ports)
• any local promisc port on the same switch

Here, I suspect that the trunk port on the downstream switch is not properly configured. The first thing I would be looking at is whether all VLANs are allowed on it. Perhaps now would be a good time to share your configurations from both switches to understand better how your lab is set up.

Best regards,
Peter

[tlxbx]

Thank you @Peter Paluch I re-created the lab and everything worked or didn't work as expected. So I believe there was some bug in my last lab. At this point, I am clear that private VLAN is the way to go for my enterprise. I have one last question: How do I configure pvlan for the below situations; what would be the equivalent pvlan config for these? user/phone interface and AP interface:

Int g0/1

Des user/phone

Switchport mode access

Switchport access vlan 5

Switchport voice vlan 10

Int g0/2

Des wifi

Switch mode trunk

Switchport trunk native van 20

Switch truck allowed van 30,40,50

[tlxbx]

@Peter Paluch  Hi Peter, did you had a chance to review the above questions? I am stuck on this step. Any advice would be a huge help for me to move to next step. 

[tlxbx]

While at it, what are your thoughts on switchport protected? If I have multiple switches over the Trunk port with VLAN spanned will this work? If host A on Sw1 Vlan 10 -->pings--> Host B on SW2 VLAN 10, since the trunk will probably have to be set unprotected how will this play out? Thank you  

[Peter Paluch]

Hi again,

Your thinking is correct. The "switchport protected" feature implements the same behavior as an isolated secondary VLAN, but only locally, on a single switch only. Since the connection to the other switch has to be a normal port (otherwise the protected ports would never be able to communicate with anyone), the isolation between the protected ports on different switches is lost. In fact, this is the deficiency that the isolated secondary VLAN solves - because on every switch, it is explicitly marked as an isolated VLAN, the switch knows that no matter where the frame was received, it can only go to local promisc ports and trunks.

Best regards,
Peter