Routing Between VLANs

Routing Between VLANs

Routing is the process of determining where to send data packets destined for addresses outside of the local network. Routers gather and maintain routing information to enable the transmission and receipt of data packets. For traffic to cross from one VLAN to another, a Layer 3 process is necessary.

This section describes the operation of inter-VLAN routing using a router on a stick.

Understanding Inter-VLAN Routing

Inter-VLAN communication occurs between broadcast domains via a Layer 3 device. In a VLAN environment, frames are switched only between ports within the same broadcast domain. VLANs perform network partitioning and traffic separation at Layer 2. InterVLAN communication cannot occur without a Layer 3 device, such as a router. Use IEEE 802.1Q to enable trunking on a router subinterface.

Example: Router on a Stick

Figure 2-31 illustrates a router attached to a core switch. The configuration between a router and a core switch is sometimes referred to as a router on a stick.

Figure 2-31 Router on a Stick

The router can receive packets on one VLAN and forward them to another VLAN. To perform inter-VLAN routing functions, the router must know how to reach all VLANs being interconnected. Each VLAN must have a separate connection on the router, and you must enable 802.1Q trunking on those connections. The router already knows about directly connected networks. The router must learn routes to networks to which it is not directly connected.

To support 802.1Q trunking, you must subdivide the physical FastEthernet interface of the router into multiple, logical, addressable interfaces, one per VLAN. The resulting logical interfaces are called subinterfaces. This is illustrated in Figure 2-32.

Figure 2-32 Subinterfaces

Without this subdivision, you would have to dedicate a separate physical interface to each VLAN.

Example: Subinterfaces

In the figure, the FastEthernet 0/0 interface is divided into multiple subinterfaces:
FastEthernet 0/0.1, FastEthernet 0/0.2, and FastEthernet 0/0.3.

Configuring Inter-VLAN Routing
To be able to route between VLANs on a switch, you will need to be able to configure interVLAN routing.

In Figure 2-33, the FastEthernet 0/0 interface is divided into multiple subinterfaces: FastEthernet 0/0.1 and FastEthernet 0/0.2. Each subinterface represents the router in each of the VLANs for which it routes.

Figure 2-33 Inter-VLAN Routing Configuration

Use the encapsulation dot1q vlan identifier command (where vlan identifier is the VLAN number) on each subinterface to enable 802.1Q encapsulation trunking. The subinterface number does not have to be the same as the dot1Q VLAN number. However, management is easier when the two numbers are the same.

The native VLAN frames in 802.1Q do not carry a tag. Therefore, the native VLAN subinterface is configured with the encapsulation dot1Q vlan identifier native command. Ensure that the VLAN assigned to the native VLAN subinterface matches the native VLAN on the switch it connects to. Each subinterface will have a unique IP address for the VLAN it is associated with. This address will be used as the gateway address for workstations in that VLAN.

Securing the Expanded Network

Routers and switches that are internal to an organization often have minimal security configurations, which render them targets for malicious attacks. If an attack is launched at Layer 2 on an internal campus device, the rest of the network can be quickly compromised, often without detection.

This section discusses security features that exist to protect switches and Layer 2 operations.

Overview of Switch Security Concerns

Much industry attention surrounds security attacks from outside the walls of an organization and at the upper Open Systems Interconnection (OSI) layers. Network security often focuses on edge routing devices and the filtering of packets based on Layer 3 and Layer 4 headers, ports, stateful packet inspection, and so on. This focus includes all issues surrounding Layer 3 and above, as traffic makes its way into the campus network from the Internet. Campus access devices and Layer 2 communication are largely unconsidered in most security discussions.

Routers and switches that are internal to an organization and designed to accommodate communication by delivering campus traffic have a default operational mode that forwards all traffic unless it is configured otherwise. Their function as devices that facilitate communication often results in minimal security configuration and renders them targets for malicious attacks. If an attack is launched at Layer 2 on an internal campus device, the rest of the network can be quickly compromised, often without detection. Figure 2-34 shows a trend in the lack of security toward the user access layer.

Figure 2-34 Security Decreases Near the Access Layer

Like Layer 3, where security traditionally has had to be tightened on devices within the campus as malicious activity that compromised this layer has increased, Layer 2 requires that security measures be taken to guard against attacks that are launched by maliciously leveraging normal Layer 2 switch operations. Many security features are available for switches and routers, but you must enable them to make them effective. In the same way that you implement access control lists (ACL) for upper-layer security, you must establish a policy and configure appropriate features to protect against potential malicious acts while maintaining daily network operations.

Network security vulnerabilities include loss of privacy, data theft, impersonation, and loss of data integrity. You should take basic security measures on every network to mitigate adverse effects of user negligence or acts of malicious intent. Recommended practices dictate that you should follow these general steps whenever placing new equipment in service:
Step 1 Consider or establish organizational security policies.
Step 2 Secure switch devices by securing switch access and switch protocols and mitigating compromises launched through a switch.
You should consider the policies of an organization when determining what level and type of security you want to implement. You must balance the goal of reasonable network security against the administrative overhead that is clearly associated with extremely restrictive security measures.
A well-established security policy has these characteristics:

• Provides a process for auditing existing network security
• Provides a general security framework for implementing network security
• Defines behaviors toward electronic data that is not allowed
• Determines which tools and procedures are needed for the organization
• Communicates consensus among a group of key decision makers and defines responsibilities of users and administrators
• Defines a process for handling network security incidents
• Enables an enterprise-wide, all-site security implementation and enforcement plan Securing Switch Devices You should use your security policy to determine how to configure security on your various network devices. Best practices for securing these devices also exist. Follow these recommended practices for secure switch access:
• Set system passwords: Use the enable secret command to set the password that grants privileged access to the Cisco IOS system. Because the enable secret command simply implements a Message Digest 5 (MD5) hash on the configured password, that password remains vulnerable to dictionary attacks. Therefore, apply standard practices in selecting a feasible password.
•  Try to pick passwords that contain both letters and numbers in addition to special characters: For example, choose “$pecia1$” instead of “specials,” in which the “s” has been replaced with “$,” and the “l” has been replaced with “1” (one).
• Secure access to the console: Console access requires a minimum level of security both physically and logically. An individual who gains console access to a system is able to recover or reset the system-enable password, thus allowing that person to bypass all other security implemented on that system. Consequently, it is imperative to secure physical access to the console.
•  Secure access to vty lines: These are the minimum recommended steps for securing Telnet access:
  • Apply a basic ACL for in-band access to all vty lines.
  • Configure a line password for all configured vty lines.
  • If the installed Cisco IOS Software permits, use the Secure Shell (SSH) protocol instead of Telnet to access the device remotely.
• Use SSH: The SSH protocol and application provide a secure remote connection to a router. Two versions of SSH are available: SSH version 1 (SSHv1) and SSH version 2 (SSHv2). Cisco IOS Software implements SSHv1. It encrypts all traffic, including passwords, between a remote console and a network router across a Telnet session. Because SSH sends no traffic in plaintext, network administrators can conduct remote access sessions that casual observers will not be able to view. The SSH server in the Cisco IOS Software works with publicly and commercially available SSH clients.
  • Disable the integrated HTTP daemon if not in use: Although Cisco IOS Software provides an integrated HTTP server for management, it is highly recommended that you disable it to minimize overall exposure. If HTTP access to the switch is required, use basic ACLs to permit access only from trusted subnets.
  • Configure system-warning banners: For both legal and administrative purposes, configuring a system-warning banner to display before login is a convenient and effective way to reinforce security and general usage policies. By clearly stating the ownership, usage, access, and protection policies before a login, you provide better support for potential prosecution.
  • Disable unneeded services: By default, Cisco devices implement multiple TCP and User Datagram Protocol (UDP) servers to facilitate management and integration into existing environments. For most installations, these services are not required, and disabling them can greatly reduce overall security exposure. These commands disable the services not typically used:

    no service tcp-small-servers
    no service finger
    no service config

  • Configure basic logging: To assist and simplify both problem troubleshooting and security investigations, monitor the switch subsystem information received from the logging facility. View the output in the on-system logging buffer memory. To render the on-system logging useful, increase the default buffer size.
  • Encrypt passwords: The configuration file contains many passwords in plaintext. Using the service password-encryption command in global configuration mode will provide a simple encryption algorithm to help secure these passwords.

Securing Switch Protocols

Follow these recommended practices to secure the switch protocols:

• Manage Cisco Discovery Protocol: Cisco Discovery Protocol does not reveal security-specific information, but it is possible for an attacker to exploit this information in a reconnaissance attack, whereby an attacker learns device and IP address information to launch other types of attacks. You should follow two practical guidelines for Cisco Discovery Protocol:
  • If Cisco Discovery Protocol is not required, or if the device is located in an unsecured environment, disable Cisco Discovery Protocol globally on the device.
  • If Cisco Discovery Protocol is required, disable it on a per-interface basis on ports connected to untrusted networks. Because Cisco
• Discovery Protocol is a link-level protocol, it is not transient across a network, unless a Layer 2 tunneling mechanism is in place. Limit it to run only between trusted devices and disable it everywhere else. However, Cisco Discovery Protocol is required on any access port where you are attaching a Cisco IP phone to establish a trust relationship.
• Secure the Spanning-Tree Topology: It is important to protect the STP process of the switches that form the infrastructure. Inadvertent or malicious introduction of STP BPDUs could overwhelm a device or pose a denial of service (DoS) attack. The first step in stabilizing a spanning-tree installation is to identify the intended root bridge in the design and hard set the STP bridge priority of that bridge to an acceptable root value. Do the same for the designated backup root bridge. These actions protect against inadvertent shifts in STP that are caused by an uncontrolled introduction of a new switch.
  • On some platforms, the BPDU guard feature may be available. If so, enable it on access ports in conjunction with the PortFast feature to protect the network from unwanted BPDU traffic injection. Upon receipt of a BPDU, the BPDU guard feature automatically disables the port. Mitigating Compromises Launched Through a Switch Follow these recommended practices to mitigate compromises through a switch:
  • Proactively configure unused router and switch ports:
    • Execute the shut command on all unused ports and interfaces.
    • Place all unused ports in a “parking-lot” VLAN, which is dedicated to grouping unused ports until they are proactively placed into service.
    • Configure all unused ports as access ports, disallowing automatic trunk negotiation.
• Consider trunk links: By default, Cisco Catalyst switches that are running Cisco IOS Software are configured to automatically negotiate trunking capabilities. This situation poses a serious hazard to the infrastructure because an unsecured third-party device can be introduced to the network as a valid infrastructure component. Potential attacks include interception of traffic, redirection of traffic, DoS, and more. To avoid this risk, disable automatic negotiation of trunking and manually enable it on links that require it. Ensure that trunks use a native VLAN that is dedicated exclusively to trunk links. Consider using a password for VTP to prevent someone from adding a switch that could overwrite the VLAN database.
• Monitor physical device access: You should closely monitor physical access to the switch to avoid rogue device placement in wiring closets with direct access to switch ports.
• Ensure access port–based security: Take specific measures on every access port of every switch placed into service. Ensure that a policy is in place outlining the configuration of unused and used switch ports. For ports that will connect to end devices, you can use a macro called switchport host. When you execute this command on a specific switch port, the switch port mode is set to access, spanning-tree PortFast is enabled, and channel grouping is disabled.

The switchport host command is a macro that executes several configuration commands. You cannot revoke the effect of the switchport host command by using the no form of the command because it does not exist. To return an interface to its default configuration, use the default interface interface-id global configuration command. This command returns all interface configurations to their defaults.

Describing Port Security

Port security is a feature supported on Cisco Catalyst switches that restricts a switch port to a specific set or number of MAC addresses. The switch can learn these addresses dynamically, or you can configure them statically. Figure 2-35 shows how the switch interacts with port security.

Figure 2-35 Port Security

A port that is configured with port security accepts frames only from those addresses that it has learned or that you have configured. Port security has several implementations:

• Dynamic: You specify how many different MAC addresses are permitted to use a port at one time. You use the dynamic approach when you care only about how many rather than which specific MAC addresses are permitted. Depending on how you configure the switch, these dynamically learned addresses age out after a certain period, and new addresses are learned, up to the maximum that you have defined.
• Static: You statically configure which specific MAC addresses are permitted to use a port. Any source MAC addresses that you do not specifically permit are not allowed to source frames to the port.
• A combination of static and dynamic learning: You can choose to specify some of the permitted MAC addresses and let the switch learn the rest of the permitted MAC addresses. For example, if the number of MAC addresses is limited to four, and you statically configure two MAC addresses, the switch dynamically learns the next two MAC addresses that it receives on that port. Port access is limited to these four addresses: two static and two dynamically learned addresses. The two statically configured addresses do not age out, but the two dynamically learned addresses can, depending on the switch configuration.
• Dynamic “sticky learning”: When this feature is configured on an interface, the interface converts dynamically learned addresses to “sticky secure” addresses. This feature adds the dynamically learned addresses to the running configuration as if they were statically configured using the switchport port-security mac-address command. “Sticky learned” addresses do not age out.

Scenario for Using Port Security

Imagine five individuals whose laptops are allowed to connect to a specific switch port when they visit an area of the building. You want to restrict switch port access to the MAC addresses of those five laptops and allow no addresses to be learned dynamically on that port.

Process for Configuring Port Security

Table 2-14 describes the process that can achieve the desired results for this scenario.

Table 2-14 Port Security

802.X Port-Based Authentication

The IEEE 802.1X standard defines a port-based access control and authentication protocol that restricts unauthorized workstations from connecting to a LAN through publicly accessible switch ports. The authentication server authenticates each workstation that is connected to a switch port before making available any services offered by the switch or the LAN. Figure 2-36 shows the roles of each device in port-based authentication.

Figure 2-36 802.1X Port-Based Authentication

Until the workstation is authenticated, 802.1x access control allows only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to which the workstation is connected. After authentication succeeds, normal traffic can pass through the port. With 802.1X port-based authentication, the devices in the network have specific roles, as follows:

• Client: The device (workstation) that requests access to the LAN and switch services and responds to requests from the switch. The workstation must be running 802.1Xcompliant client software, such as that offered in the Microsoft Windows XP operating system. The port to which the client is attached is the supplicant (client) in the IEEE 802.1X specification.
• Authentication server: Performs the actual authentication of the client. The authentication server validates the identity of the client and notifies the switch whether the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client. The RADIUS security system with Extensible Authentication Protocol (EAP) extensions is the only supported authentication server.

• Switch (also called the authenticator): Controls physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client (supplicant) and the authentication server, requesting identifying information from the client, verifying that information with the authentication server, and relaying a response to the client. The switch uses a RADIUS software agent, which is responsible for encapsulating and decapsulating the EAP frames and interacting with the authentication server.

The switch port state determines whether the client is granted access to the network. The port starts in the unauthorized state. While in this state, the port disallows all ingress and egress traffic except for 802.1X protocol packets. When a client is successfully authenticated, the port transitions to the authorized state, allowing all traffic for the client to flow normally.

If the switch requests the client identity (authenticator initiation) and the client does not support 802.1X, the port remains in the unauthorized state, and the client is not granted access to the network.

When an 802.1X-enabled client connects to a port and initiates the authentication process (supplicant initiation) by sending an EAPOL-start frame to a switch that is not running 802.1X, and no response is received, the client begins sending frames as if the port is in the authorized state.

If the client is successfully authenticated (receives an Accept frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are allowed through the port.

If the authentication fails, the port remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the switch can retransmit the request. If no response is received from the server after the specified number of attempts, authentication fails, and network access is not granted.
When a client logs out, it sends an EAPOL-logout message, causing the switch port to transition to the unauthorized state.

More Resources

• Interconnecting Cisco Network Devices (ICND2)
• CCNP Switch Exam Certification Guide