With Wilson Bonilla
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about about issues in designing, planning, and implementing Layer 2 security in your LAN network with expert Wilson Bonilla.
Wilson will cover topics that network engineers face daily such as Spanning Tree Protocol security, private VLANs, IP source guard, protected ports, dynamic ARP inspection, virtual LAN access-control lists (VLAN ACLs), and Dynamic Host Configuration Protocol (DHCP) snooping over Cisco Catalyst platforms. With the fast growth of networks, Layer 2 security is even more critical in the LAN to help your network become more reliable, efficient, and secure. Wilson will answer your questions about LAN networks with Cisco Catalyst switches.
Wilson Bonilla is a technical networking trainer at the Learning and Development Department for Cisco Technical Assistance Center located in Costa Rica. Before joining the Training Department, he worked for the Cisco TAC as a customer support engineer focused on LAN Switching for more than two years. While working on LAN switching, Wilson also had roles such as technical leader and trainer, adding to his area of expertise in Cisco Catalyst Layer 2 switching. He has CCNP routing and switching certification and is currently studying to achieve his CCNA certification in data center.
Remember to use the rating system to let Wilson know if you've received an adequate response.
Because of the volume expected during this event, Wilson might not be able to answer every question. Remember that you can continue the conversation in the Network Infrastructure community, subcommunity, LAN, Switching and Routing, shortly after the event. This event lasts through November, 2013. Visit this forum often to view responses to your questions and those of other Cisco Support Community members.
Hello Alexey.
Please don't mix the concept of double-tag tunneling (QinQ) with Private vlans. QinQ adheres an outer tag to the frames to keep track of where the traffic is source and where is it going.
Your comment:
With primary vlan it removes the tag of secondary vlan from the frame and injects the tag of primary vlan. Am i right?
That's not really how it works. Take in consideration the following topology:
Where:
Primary vlan is 10
Isolated vlan is 101
Community vlan is 102
When traffic from the secondary isolated vlan is being forward to the promiscuous port the trunk port in the switch will encapsulate the frame with the source vlan(meaning the secondary vlan), so if it was sourced from the isolated secondary vlan, it will be vlan 100, (if, sourced from the community vlan it will be encapsulated with vlan 101), remember never never double tags the frame, only the secondary vlan is encapsulated. The de-encapsulation process takes place later on.
Now when the traffic comes back from the promiscuous port to the end host, the router will encapsulate the frame with the primary vlan (router or promiscuous port are not pvlan aware), finally is up to the switch to check out the cam table find out the mac address and it's vlan assignment to switch the traffic vlan to the correct secondary vlan. Later on the de-encapsulation process takes place.
Please let me know if the answer is satisfactory.
Regards.
Wilson B
Hello Daryl.
I also want to be honest with you I don't have too much experience with MacSec troubleshooting in real troubleshotting scenarios; but let me share my knowledge about what I have studied about it.
MacSec is the standard for authenticating and encrypting packets between two MacSec capable devices.
MacSec implementation:
- Basically and the main function of MacSec is in any scenario where you want to encrypt end user’s traffic to avoid a spoofing attack, In a large environment you need to make sure the access layer switch supports MacSec,
- 2960, 3550, 3750G and 3750E access layer switches do not support MacSec.
- 3750x and 3560x switches with the addition of C3KX-SM-10G module, notice that only interface in the module are the ones that support macsec, not the onboard interfaces.
- 4900m and 4948E switches don't support MacSec.
- Non 6500-e chassis don't support MacSec.
- 4500 switches only support MacSec with supervisor Sup7E, Sup7LE.
- 4500x does support MacSec.
- Only 6500e chassis with VS-S2T-10GE and in WS-X6908 supports MacSec.
NOTE: In a large environment it is very important that you have knowledge of the hardware capabilities, pay attention that not all the Catalyst series switches supports this feature so there is some limitations.
Where should you use MacSec?
- MacSec is often used in the access layer, where end users have direct access to the switchport itself, now it doesn’t mean that it cannot be used between the access and distribution/core layers. (See the picture above for reference)
What do you need to implement MacSec?
- A supplicant: who is end client, it must be running an application (cisco anyconnect) to manage encryption and MacSec negotiation.
- Authenticator/Switch: this is the intermediate device that relays the client credentials to the authentication server.
- Authentication server: Just like a ACS.
What protocols does MacSec run?
- EAP(Extensible authentication protocol): defines authentication between the supplicant and the Authenticator.
- EAP over LAN: Encapsulation to transport EAP messages.
- Key agreement / Security association protocol: Discovers peers and negotiates MacSec keys.
- Radius/Tacacs: for communication between the switch and the authentication server.
Here is another example of how it works
Best regards.
Wilson B.
