Logical Layer 3 VLAN Interfaces

The logical Layer 3 VLAN interfaces provide logical routing interfaces to VLANs on Layer 2 switches. A traditional network requires a physical interface from a router to a switch to perform inter-VLAN routing. The Catalyst 4500 series switch supports inter-VLAN routing by integrating the routing and bridging functions on a single Catalyst 4500 series switch.

Figure 36-1 shows how the routing and bridging functions in the three physical devices of the traditional network are performed logically on one Catalyst 4500 series switch.

Figure 36-1 Logical Layer 3 VLAN Interfaces for the Catalyst 4500 Series Switch

Physical Layer 3 Interfaces

The physical Layer 3 interfaces support capabilities equivalent to a traditional router. These Layer 3 interfaces provide hosts with physical routing interfaces to a Catalyst 4500 series switch.

Figure 36-2 shows how the Catalyst 4500 series switch functions as a traditional router.

Figure 36-2 Physical Layer 3 Interfaces for the Catalyst 4500 Series Switch

Understanding SVI Autostate Exclude

To be up/up, a router VLAN interface must fulfill the following general conditions:

• The VLAN exists and is active on the VLAN database of the switch.
• The VLAN interface exists on the router and is not administratively down.
• At least one Layer 2 (access port or trunk) port exists, has a link up on this VLAN, and is in spanning-tree forwarding state on the VLAN.

Note The protocol line state for the VLAN interfaces comes up when the first switch port belonging to the corresponding VLAN link comes up and is in spanning-tree forwarding state.

Ordinarily, when a VLAN interface has multiple ports in the VLAN, the SVI goes down when all the ports in the VLAN go down. The SVI Autostate Exclude feature provides a knob to mark a port so that it is not counted in the SVI up and down calculation and applies to all VLANs that are enabled on that port.

A VLAN interface is brought up after the Layer 2 port has had time to converge (that is, transition from listening-learning to forwarding). This prevents routing protocols and other features from using the VLAN interface as if it were fully operational. It also prevents other problems from occurring, such as routing black holes.

Understanding Layer 3 Interface Counters

Note Supervisor Engine 9-E, 8L-E, 8-E, 7-LE, 7-E, 6L-E, do not support Layer 2 interface counters. However, they do support Layer 3 (SVI) interface counters.

When you run IPv4 and IPv6 on Supervisor Engines 9-E, 8L-E, 8-E, 7-LE, 7-E, 6L-E, 6-E, packets are routed in hardware by the forwarding engine. They support the following statistics for counting routed packets with a maximum of 4092 interfaces:

• Input unicast
• Input multicast
• Output unicast
• Output multicast

For each counter type, both the number of packets and the total number of bytes received or transmitted are counted. You can collect these statistics uniquely for IPv4 and IPv6 traffic.

Because the total number of supported Layer 3 interfaces exceeds the number of counters supported by hardware, all Layer 3 interfaces might not have counters. You assign counters to Layer 3 interfaces; the default configuration for a Layer 3 interface has no counters.

You can configure collection statistics at an interface level in one of the four ways (see Table 36-1 ). The maximum number of interfaces applied to the configuration depends on the collection mode.

When mixing these configured modes, the rule is as follows:

(number of v4/v6/v4v6combined interfaces) + 2*(number of v4v6separate interfaces) <= 4092

Note To enable Layer 3 interface counters, you need to enter the counter command in interface mode. For instructions, see the “Configuring Layer 3 Interface Counters” section.

The hardware counters are displayed in the output of the show interface command, as shown in the following example. Counter fields that are updated when the counter configuration is present are highlighted.

The output of the previous configuration depends on the counter configuration ( Table 36-2 ).

Configuring SVI Autostate Exclude

Note The SVI Autostate Exclude feature is enabled by default and is synchronized with the STP state.

The SVI Autostate Exclude feature shuts down (or brings up) the Layer 3 interfaces of a switch when the following port configuration changes occur:

• When the last port on a VLAN goes down, the Layer 3 interface on that VLAN is shut down
  (SVI- autostated).
• When the first port on the VLAN is brought back up, the Layer 3 interface on the VLAN that was previously shut down is brought up.

SVI Autostate Exclude enables you to exclude the access ports and trunks in defining the status of the SVI (up or down) even if it belongs to the same VLAN. If the excluded access port and trunk is in up state and other ports are in down state in the VLAN, the SVI state is changed to down.

To make the SVI state up, at least one port in the VLAN should be up and not excluded. This action helps to exclude the monitoring port status when you are determining the status of the SVI.

To apply SVI Autostate Exclude, perform this task:

This example shows how to apply SVI Autostate Exclude on interface g3/1:

Configuring IP MTU Sizes

You can set the protocol-specific maximum transmission unit (MTU) size of IPv4 or IPv6 packets that are sent on an interface.

For information on MTU limitations, refer to “Maximum Transmission Units” section.

Note To set the nonprotocol-specific MTU value for an interface, use the mtu interface configuration command. Changing the MTU value (with the mtu interface configuration command) can affect the IP MTU value. If the current IP MTU value matches the MTU value, and you change the MTU value, the IP MTU value is modified automatically to match the new MTU. However, the reverse is not true; changing the IP MTU value has no effect on the value for the mtu command.

For information on how to configure MTU size, refer to “Configuring MTU Sizes” section.

To set the protocol-specific maximum transmission unit (MTU) size of IPv4 or IPv6 packets sent on an interface, perform this task:

This example shows how to configure IPv4 MTU on an interface:

The following example shows how to configure IPv6 MTU on an interface:

This example shows how to verify the configuration

Note When IPv6 is enabled on an interface using any CLI command, you may see the following message:

% Hardware MTU table exhausted

In this situation, the IPv6 MTU value programmed in hardware differs from the IPv6 interface MTU value. This situation occurs if no room exists in the hardware MTU table to store additional values. You must free up some space in the table by unconfiguring some unused MTU values and subsequently disable and reenable IPv6 on the interface or reapply the MTU configuration.

Configuring Layer 3 Interface Counters

Note Supervisor Engine 9-E, 8L-E, 8-E, 7-LE, 7-E, 6L-E, 6-E, do not support Layer 2 interface counters.

To configure Layer 3 interface counters (assign counters to a Layer 3 interface), perform this task:

This example shows how to enable counters on interface VLAN 1:

Note To remove the counters, use the no counter command.

If you have already assigned the maximum number of counters, the counter command fails and displays an error message:

In this situation, you must release a counter from another interface for use by the new interface.

About Multipoint GRE

Point-to-Multipoint (P2MP) is a hub-n-spoke topology that uses Multipoint GRE protocol (mGRE). mGRE is built over IPv4 core/underlying network and allows multiple destinations to be grouped into a single multipoint interface. It supports Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing Protocol (EIGRP) protocols, IPv4 and IPv6 unicast payload, and IPv4 multicast payload. mGRE does static and dynamic Next Hop Resolution Protocol (NHRP) tunneling for hub-to-spoke and spoke-to-spoke technologies, providing scalability and also reducing configuration complexity. Spokes dynamically register themselves with the hub and individual spokes also dynamically learn about other spokes using the NHRP protocol forming a dynamic-mesh network, that is, a non-broadcast multi-access network (NBMA). In NBMA, all routing protocols send their updates to a physical NBMA address. mGRE in conjunction with IPSEC and NHRP can be used in Dynamic Multipoint VPN (DMVPN).

In this figure, each spoke acts as a Next Hop Client (NHC) and is configured with static mapping information (hub’s tunnel IP address and NBMA address) to reach hub which acts as Next Hop Server (NHS). NHCs send Next Hop Resolution Protocol (NHRP) registration request to NHS which allows NHS to learn mapping information of the spoke and form a tunnel (hub and spoke) dynamically.

In addition to NHRP registration of NHCs (spokes) with NHS (hub), NHRP provides the capability for NHC to dynamically discover another NHC on demand and form spoke-to-spoke tunnel. Without this discovery, IP packets traversing from hosts behind one spoke to hosts behind another spoke have to traverse by way of the NHS router. This increases the utilization of the hub's physical bandwidth and CPU to process these packets that come into the hub on the multipoint interface and go right back out the multipoint interface. This is often called hairpinning. With NHRP, systems attached to an NBMA network dynamically learn the NBMA address of the other systems that are part of that network, allowing these systems to directly communicate without requiring traffic to use an intermediate hop. This alleviates the load on the intermediate hop (NHS) and can increase the overall bandwidth of the NBMA network to be greater than the bandwidth of the hub router and effectively creates a full-mesh-capable network without having to discover all possible connections beforehand.

This is called a dynamic-mesh network, where there is a base hub-and-spoke network of NHCs and NHSs for transporting NHRP, dynamic routing protocol information, data traffic, and dynamic direct spoke-to-spoke links that are built when there is data traffic to use the link and torn down when the data traffic stops.

Configuring Unicast mGRE at Hub

Configuring Unicast mGRE at Spoke

Sample mGRE Configuration at Hub and Spokes

On SPOKE 1:

On SPOKE 2:

On HUB: