Cisco: Control Traffic Between Switch Ports

Jan 20, 2026 by Andrew McMorgan 44 views

Hey guys, welcome back to Plastik Magazine! Today, we're diving deep into a super common but often tricky networking scenario: ensuring traffic only flows between a specific switch port and a trunk port on your Cisco Catalyst switches. This is crucial for security and performance, especially when you've got sensitive devices or need to isolate traffic. We're talking about how to lock down port Gi2/12 so it can only communicate with one specific VM, granting it direct internet access while keeping the rest of your VLAN isolated. This might sound complex, but trust me, by the end of this article, you'll be a pro at managing this kind of network traffic. We'll break down the concepts, the commands, and the reasoning behind it all, so you can confidently implement these controls on your own network. Whether you're an IT pro managing a business network or a tech enthusiast looking to level up your home setup, this guide is for you. Let's get started on making your network more secure and efficient!

Understanding the Scenario: Why Isolate a Switch Port?

So, why would you even want to do this, right? Imagine you have a server, maybe a firewall appliance, or even a specific virtual machine (VM) that needs direct, unhindered access to the internet. You want this device to be able to communicate freely with the outside world without being bogged down or potentially compromised by other devices on your internal network. This is where the need to isolate a specific port, like your Gi2/12, comes into play. You want this port to act as a dedicated gateway for that single VM, ensuring it gets the bandwidth it needs and is shielded from any unwanted traffic from other segments of your VLAN. Think of it like giving one special guest a private, direct path to the exit of a building, while everyone else uses the main hallways. This isolation is a fundamental security practice, often referred to as port security or access control, and it’s a cornerstone of robust network design. It prevents unauthorized access, limits the spread of malware, and ensures that critical devices have the resources they need without interference. We’ll explore how Cisco Catalyst switches provide the tools to achieve this level of granular control, making your network both more secure and more performant. It’s all about building layers of defense and ensuring that your network operates exactly as you intend it to.

The Problem with Standard VLANs

Now, let's talk about why a standard VLAN setup might not be enough for this specific need. VLANs (Virtual Local Area Networks) are fantastic for segmenting your network and broadcasting traffic efficiently within a specific group. They logically separate devices, even if they're physically connected to the same switch. However, by default, devices within the same VLAN can generally communicate with each other freely. If you have a server connected to Gi2/12 that needs direct internet access, and it's on a VLAN with other devices, those other devices could potentially send traffic to your server. This isn't ideal for security or for ensuring that your critical VM gets the dedicated bandwidth it requires. You might also have a situation where you want to protect your other VLAN devices from potentially malicious traffic that could originate from the internet-facing port. The goal here is to create a one-way street for certain types of traffic, or at least severely restrict what can reach your isolated VM and what your isolated VM can reach. The challenge is how to tell the switch, "Hey, this port (Gi2/12) is special. It should only talk to this specific destination (your VM) and potentially to the outside world, but nothing else on this VLAN." This is where more advanced configurations come into play, going beyond basic VLAN tagging and into the realm of access control lists (ACLs) and private VLANs (PVLANs), which we'll get into shortly. Understanding these limitations of basic VLANs is the first step to appreciating the power of the solutions we're about to explore. It’s all about fine-tuning your network for specific security and performance requirements.

Cisco Catalyst Features for Traffic Control

Alright, guys, let's get down to the nitty-gritty of how Cisco Catalyst switches handle this kind of traffic control. These powerful devices offer a suite of features that go way beyond just assigning ports to VLANs. For our scenario, where we need Gi2/12 to talk only to a specific VM and potentially the internet, we're primarily looking at two key technologies: Access Control Lists (ACLs) and Private VLANs (PVLANs). Each offers a different approach to achieving our goal, and sometimes, they can even be used in conjunction. ACLs are like the bouncers at a club, meticulously checking IDs and deciding who gets in and who doesn't, based on a set of rules. PVLANs, on the other hand, are more about creating exclusive social circles within the larger VLAN party, ensuring that members of one circle can't easily mingle with members of another, even if they're in the same main room. Understanding these tools is key to mastering traffic management on your Cisco gear. We'll explore how to configure them, what their strengths and weaknesses are, and when to use each one to best secure your network and optimize traffic flow. Get ready to flex those Cisco configuration muscles!

Access Control Lists (ACLs): The Network Bouncer

Access Control Lists (ACLs) are incredibly powerful tools in Cisco networking, acting like a set of filters on your switch ports. Think of them as super-specific security guards for your network traffic. They allow you to define rules that permit or deny traffic based on various criteria, such as source IP address, destination IP address, protocols (like TCP or UDP), and port numbers. For our specific problem – ensuring Gi2/12 only talks to a particular VM – ACLs are a prime candidate. You can create an ACL that explicitly permits traffic from Gi2/12 to the IP address of your target VM, and perhaps from Gi2/12 to the internet (if that's a requirement). Crucially, you can also deny all other traffic originating from Gi2/12 to any other device on the VLAN. This creates a very strict boundary. You can even apply an ACL in the inbound direction on Gi2/12 to ensure that only traffic from the specific VM is allowed onto that port, further tightening security. The beauty of ACLs lies in their granularity. You can get really specific. For example, you could allow Gi2/12 to only communicate with your VM on TCP port 80 (HTTP) and TCP port 443 (HTTPS) if that’s all the VM needs. Anything else? Denied! This is a fundamental security concept, and mastering ACLs will open up a whole new world of network control for you, guys. They are the workhorses for micro-segmentation and access control within your Cisco environment.

How they work: ACLs are configured on the switch and applied to interfaces (ports) or VLAN interfaces. When traffic hits an interface with an ACL applied, the switch checks each rule in the ACL sequentially. If a rule matches the traffic, the action specified (permit or deny) is taken. If no rule matches, the traffic is typically denied by default (depending on the ACL type).
Key commands: You'll be using commands like access-list <number> permit/deny <source> <destination> <protocol> <port> to define your rules, and then interface <interface_id> followed by ip access-group <acl_number> in/out to apply them.
Use case for Gi2/12: To allow Gi2/12 to talk only to VM1 (e.g., 192.168.1.100) and the internet, you might create an ACL that permits traffic from Gi2/12's IP (if it has one, or its source MAC if acting as a simple L2 port) to 192.168.1.100, and then permits traffic to a default gateway for internet access. All other traffic from Gi2/12 would be implicitly or explicitly denied. You could also apply an inbound ACL on Gi2/12 to only allow traffic from the specific VM's IP address. This level of control is invaluable for network hardening.

Private VLANs (PVLANs): Exclusive Social Circles

Private VLANs (PVLANs) offer a different, yet often complementary, approach to traffic isolation. While standard VLANs segment the network broadly, PVLANs provide a more granular segmentation within a single VLAN. Think of a standard VLAN as a ballroom. Everyone in the ballroom can see and talk to each other. Now, imagine that ballroom has several private booths. PVLANs create these private booths within the ballroom. The core idea behind PVLANs is to break down a primary VLAN into smaller, isolated segments called secondary VLANs. These secondary VLANs come in three flavors: isolated, community, and promiscuous. For our goal of having Gi2/12 talk to only one specific VM, the isolated type is your best bet. An isolated PVLAN port can only communicate with promiscuous ports and cannot communicate with any other isolated or community ports within the same primary VLAN. A promiscuous port, on the other hand, can communicate with all other ports (isolated, community, and other promiscuous ports) and typically serves as the uplink to a router or firewall, giving access to the outside world. Community PVLANs allow ports within the same community to communicate with each other, but not with ports in other communities or isolated ports. So, if you configure Gi2/12 as an isolated port, and your VM is connected to an isolated port that can reach a promiscuous port (likely your uplink to the router), you achieve exactly the isolation you need. This prevents devices on other isolated or community ports within the same primary VLAN from seeing or interacting with your VM or the device on Gi2/12. It's a powerful way to create truly isolated environments for sensitive devices or specific applications.

How they work: PVLANs require a primary VLAN and one or more secondary VLANs. Ports are configured as either isolated, community, or promiscuous. The switch enforces communication rules based on these classifications and the type of secondary VLAN.
Key concepts:
- Primary VLAN: The main VLAN that encompasses all PVLANs.
- Isolated VLAN: Ports in an isolated VLAN can only communicate with promiscuous ports.
- Community VLAN: Ports in a community VLAN can communicate with other ports in the same community VLAN and with promiscuous ports.
- Promiscuous Port: A port that can communicate with all other ports (isolated, community, and other promiscuous ports). Typically assigned to routers or firewalls.
Use case for Gi2/12: You would typically configure Gi2/12 as an isolated port. You'd then configure the port connected to your VM also as an isolated port within the same PVLAN configuration. A promiscuous port would be configured on the uplink to your router or firewall. This setup ensures that Gi2/12 and the VM port can only talk to the promiscuous port (and thus the internet/router), and cannot talk to each other or any other devices on the same primary VLAN that are not also promiscuous. This is a very effective way to segment traffic and prevent lateral movement.

Implementing the Solution: Step-by-Step

Alright, you've got the theory down, now let's get practical. We're going to walk through how you might implement this, focusing on using ACLs as they are often more straightforward for this specific use case of direct internet access for one port. Remember, the exact commands can vary slightly depending on your Cisco IOS version and switch model, so always consult your specific device documentation. But the principles remain the same. We want Gi2/12 to talk only to our specific VM, let's say its IP is 192.168.1.100, and to the internet via a default gateway, say 192.168.1.1. The rest of the devices on its VLAN should not be able to communicate with Gi2/12 or the VM connected to it. We’ll apply an ACL to the inbound direction of Gi2/12 to control what traffic is allowed onto that port, and potentially an outbound ACL if we want to strictly control what traffic Gi2/12 can initiate. For simplicity and to meet the core requirement of protecting the VLAN from traffic on Gi2/12 and vice-versa, we'll focus on an inbound ACL on Gi2/12.

Scenario: Isolating Gi2/12 with ACLs

Let's assume Gi2/12 is configured as an access port for VLAN 10. We want to ensure that only traffic originating from the VM (192.168.1.100) is permitted onto Gi2/12. This prevents any other device on VLAN 10 from sending unwanted traffic to the VM. We also want the VM to be able to reach the internet. For this to work, Gi2/12 will need an IP address within the same subnet as the VM and the gateway, or it will need to be configured in a way that allows it to pass traffic from the VM without directly routing it itself. A common approach is to assign Gi2/12 an IP address from the same subnet as the VM and then apply the ACL. So, let's say Gi2/12 is configured with IP address 192.168.1.2 and is part of VLAN 10. The VM is 192.168.1.100 and the default gateway is 192.168.1.1.

Step 1: Define the Access Control List (ACL)

We'll create a standard or extended ACL. An extended ACL gives us more control over source and destination IPs, protocols, and ports. Let's use an extended ACL. We want to permit traffic from our specific VM (192.168.1.100) to our isolated port (192.168.1.2), and we want to allow traffic from our isolated port (192.168.1.2) to the default gateway (192.168.1.1).

configure terminal
access-list 110 permit ip host 192.168.1.100 host 192.168.1.2
access-list 110 permit ip host 192.168.1.2 host 192.168.1.1
access-list 110 deny ip any any log
end

access-list 110 permit ip host 192.168.1.100 host 192.168.1.2: This line permits any IP traffic originating from the VM (192.168.1.100) to our specific port's IP address (192.168.1.2). This is crucial for allowing the VM to send data.
access-list 110 permit ip host 192.168.1.2 host 192.168.1.1: This line permits IP traffic originating from our specific port (192.168.1.2) to the default gateway (192.168.1.1). This allows the VM (via this port) to reach the internet.
access-list 110 deny ip any any log: This is the implicit deny statement turned explicit and with logging. It denies all other IP traffic that doesn't match the above permit statements. The log keyword is super useful for troubleshooting, as it will generate log messages when this rule is hit, letting you know if something unexpected is being blocked. The any any covers all sources and destinations.

Step 2: Apply the ACL to the Interface

Now we need to apply this ACL to the Gi2/12 interface in the inbound direction. This means the ACL will examine traffic as it enters the interface.

configure terminal
interface GigabitEthernet2/12
ip address 192.168.1.2 255.255.255.0
ip access-group 110 in
switchport mode access
switchport access vlan 10
end

interface GigabitEthernet2/12: Selects the interface.
ip address 192.168.1.2 255.255.255.0: Assigns an IP address to the interface. For an ACL to work effectively with IP traffic, the interface often needs an IP address in the same subnet.
ip access-group 110 in: This is the magic command that applies ACL 110 to traffic entering the Gi2/12 interface. Remember, in is for inbound traffic.
switchport mode access: Configures the port as an access port.
switchport access vlan 10: Assigns the port to VLAN 10.

Step 3: Configure the Default Gateway

Ensure your default gateway (192.168.1.1) is correctly configured on your router or Layer 3 switch to route traffic from VLAN 10 to the internet.

Step 4: Verification

Now, for the fun part: testing! Connect your VM to Gi2/12. Try to ping the default gateway from the VM. Try to ping an external website (e.g., google.com). Then, try to ping Gi2/12 or the VM from another device on VLAN 10. You should find that:

The VM can ping the gateway and access the internet.
Other devices on VLAN 10 cannot ping the VM or Gi2/12.

If the