Multilayer Switching: Intro to SLA & DHCP on a Cisco MLS or Router


“With Cisco IOS IP SLAs, users can verify service guarantees, increase network reliability by validating network performance, proactively identify network issues, and increase Return on Investment (ROI) by easing the deployment of new IP services.”

“Cisco IOS IP SLAs use active monitoring to generate traffic in a continuous, reliable, and predictable manner, thus enabling the measurement of network performance and health.”

According to the same site, a typical SLA contains the following assurances:

  • Network availability percentage
  • Network performance (often measured by round-trip delay)
  • Latency, jitter, packet loss, DNS lookup time
  • Trouble notification response time
  • Resolution time
  • Reimbursement schedule when above assurances are not met

Cisco IOS IP SLA usage includes:

  • Performance visibility
  • SLA monitoring
  • IP service network health readiness
  • Edge-to-edge network availability monitoring
  • Business-critical app performance monitoring
  • Network operation troubleshooting

There are two parties involved in the overall SLA process, the self explanatory Source and Responder. Once we configure SLA, the source kicks off the process.

Control packets are sent to the Responder on UDP port 1967 in an attempt to create a control connection similar to that of FTP – it’s basically an agreement on the rules of communication. In this case, the rules sent to the Responder are the protocol and port number it should listen for and a time value indication how long it should listen.

If the Responder agrees to the rules, it will send a message back to the Source indicating its agreement, and will then start listening! (If the Responder doesn’t agree, it will indicate that as well, and our story ends here.)

We now go from controlling to probing, as the Source sends some test packets to the Responder. What’s the Source testing? The approximate length of time it take the Responder to – you guessed it – respond!

The Responder adds timestamps both as the packets are accepted and returned to the Sender. This gives the Sender a better idea of the overall time it took the Responder to process the packets.

Configuring SLA can be a bit tricky – I’ve seen the IOS commands vary more than usual between IOS version. While the basic process is the same..

  • Config the probe and send it
  • Config the object to be probed

… the commands to get you there vary. Here’s a Cisco PDF on the subject:


  1. The initial step has the DHCP client sending a broadcast packet, a DHCPDiscover packet, that allows the host to discover where the DHCP servers are.
  2. The DHCP servers that receive that DHCPDiscover packet will respond with a DHCPOffer packet. This packet contains an IP address, the time the host can keep the address (the “lease”), a default gateway, and other information as configured by the DHCP server admin.
  3. If the host receives DHCPOffer packets from multiple DHCP servers, the first DHCPOffer packet received is the one accepted. The host accepts this offer with a DHCPRequest packet, which is also a broadcast packet.
  4. The DHCP server whose offered IP address is being accepted sends a unicast DHCPAck (for “acknowledgement”) back to the host.

A Cisco router acting as a DHCP server will check for IP address conflicts before assigning an IP address. This check consists of the router sending two ping packets to an IP address before assigning that address; those pings will time out in 500 milliseconds.

If you want to change either the number of pings sent or the ping timeout value during this process, use the ip dhcp ping packets and ip dhcp ping timeout commands. Note that these are global commands as well. You can also disable this pinging by entering zero for the ping packets value.

IP Helper Address

By configuring the ip helper-address command on the router, UDP broadcasts such as this will be translated into a unicast by the router, making the communication possible.

A Cisco router running the ip helper-address command is said to be acting as a DHCP Relay Agent, but DHCP messages are not the only broadcasts being relayed to the correct destination. Nine common UDP service broadcasts are “helped” by default:

  1. TIME, port 37
  2. TACACS, port 49
  3. DNS, port 53
  4. BOOTP/DHCP Server, port 67
  5. BOOTP/DHCP Client, port 68
  6. TFTP, port 69
  7. NetBIOS name service, port 137
  8. NetBIOS datagram service, port 138
  9. IEN-116 name service, port 42

If you want a broadcast not covered by the above then you can manually add using:

‘ip forward-protocol’ command to add any UDP port number to the list.

DHCP Relay and Option 82

R1(config)#ip dhcp relay information ?

check Validate relay information in BOOTREPLY

option Insert relay information in BOOTREQUEST

policy Define reforwarding policy

R1(config)#ip dhcp relay information option

Multilayer Switching: More Routed Ports and Comparisons with SVIs

Remember the ‘follow the path’ technique with troubleshooting at Layer 3.

Router On A Stick is not scalable. (Doh!)

SVI Checklist

  • Create the VLAN before the SVI. The VLAN must be active when the SVI is created – that VLAN will not be dynamically created at that time.
  • Theoretically, you need to open the SVI with no shutdown just as you would open a physical interface after configuring an IP address
  • The SVI and VLAN have an association, but they’re not the same thing..
  • The only SVI on the switch by default is the SVI for VLAN 1, intended to allow remote switch administration and configuration.

SVIs are a great way to allow interVLAN communication, but you must have a routing protocol configured in addition to the SVIs.

Fallback Bridging – (Uncommon in the real world)

CEF has a limitation in that IPX, SNA, LAT, and AppleTalk are either not supported by CEF or, in the case of SNA and LAT, are nonroutable protocols. If you’re running any of these on an CEF-enabled switch, you’ll need fallback bridging to get this traffic from one VLAN to another.

Fallback bridging involves the creation of bridge groups, and the SVIs will have to be added to these bridge groups.

To create a bridge group:

MLS(config)# bridge-group 1

To join a SVI to a bridge group:

MLS(config)#interface vlan 10
MLS(config-if)#bridge-group 1

SVI Advantages

  • No single point of failure
  • Faster than ROAS
  • Don’t need to configure a trunk between the L2 switch and the router

If you have an L3 switch, you’re much better off using SVIs for inter-VLAN communication rather than ROAS.

A black hole in routing is the result of an SVI remaining up when there are actually no “up/up” interfaces in that VLAN except for those connected to network monitors or similar devices.

To avoid this, we can exclude such ports from the “up/up” calculation with the switchport autostate exclude command. Using that interface-level command on ports like the one previous described will exclude that port from the “up/up” determination.

Multilayer Switching: SVI + Routed Ports

Switched Virtual Interfaces

Create SVI and set access ports into relevant VLAN ID/SVI ID. Standard stuff.. Default gateway for hosts in the VLAN will be the SVI itself. Of course!

Don’t forget to enable ip routing on MLS, directly connected networks/VLANs will now be in routing table and InterVLAN routing will be possible without the requirement for a routing protocol.

When ip routing is enabled, a static route should always be used for default traffic. (Gateway of last resort)

Routed Ports

Routed ports are physical L3 switch ports, as opposed to SVIs, which are logical. Another difference – routed ports don’t represent a particular VLAN as does as SVI.

You configure a routed port with a routing protocol such as OSPF or EIGRP in the exact same manner as you would on a router. That goes for protocol-specific commands as well as interface-specific.

Port is converted from a L2 port to a L3 port using the ‘no switchport’ command.

(How good does it feel to already know a lot of this stuff very well? It feels good! This is the 1st recap topic where I am very happy as I do this kind of stuff on a day to day basis)

Multilayer Switching: MLS Fundamentals


Multilayer switches can perform packet switching up to ten times as fast as a pure L3 router.

When it comes to Cisco Catalyst switches, this hardware switching is performed by a router processor (or L3 engine). This processor must download routing information to the hardware itself. To make this hardware-based packet processing happen, Cat switches will run either the older Multilayer Switching (MLS), or the newer Cisco Express Forwarding (CEF).

Application-Specific Integrated Circuits (ASICs) will perform the L2 rewriting operation of these packets. With multilayer switching, it’s the ASICs that perform this L2 address overwriting.

in addition to the CAM table we have a TCAM table – Ternary Content Addressable Memory. Basically, the TCAM table stores everything the CAM table can’t, including info about ACLs and QoS.

Route Caching

Route caching devices have both a routing processor and a switching engine. The routing processor routes a flow’s first packet, the switching engine snoops in on that packet and the destination, and the switching engine takes over and forwards the rest of the packets in that flow. Route Caching can be effective, but there’s one slight drawback – the first packet in any flow will be switched by software.

CEF (Cisco Express Forwarding)

Cisco Express Forwarding (CEF) is a highly popular method of multilayer switching. Primarily designed for backbone switches, this topology-based switching method requires special hardware, so it’s not available on all L3 switches. CEF is highly scalable, and is also easier on a switch’s CPU than route caching.

CEF has two major components – the Forwarding Information Base and the Adjacency Table.

The Forwarding Information Base (FIB) that contains the usual routing information – the destination networks, their masks, the next-hop IP addresses, etc – and CEF will use the FIB to make L3 prefix-based decisions. The FIB’s contents will mirror that of the IP routing table. (show ip cef)

The routing information in the FIB is updated dynamically as change notifications are received from the L3 engine. Since the FIB is prepopulated with the information from the routing table, the MLS can find the routing information quickly.

*If the TCAM table ever was full, there is a wildcard entry that will redirect traffic to the routing engine.

The Adjacency Table (AT) As adjacent hosts are discovered via ARP, that next-hop L2 information is kept in this table for CEF switching.

  • Moving packets from the L3 engine to software = ‘punt adjacency’
  • Sending packets to nowhere = ‘null adjacency’

The Control Plane And The Data Plane

Control Plane

  • “CEF control plane”
  • “control plane”
  • “Layer 3 engine” or “Layer 3 forwarding engine”

The control plane’s job is to first build the ARP and IP routing tables.

Data Plane

  • “data plane”
  • “hardware engine”
  • “ASIC”

The data plane that places data in the L3 switch’s memory while the FIB and AT tables are consulted, and then performs any necessary encapsulation before forwarding the data to the next hop.

Exceptions To The Rule

Packets that CANNOT be hardware switched:

  • Packets with IP header options
  • Packets that will be fragmented before transmission (because they’re exceeding the MTU)
  • NAT packets
  • Packets that came to the MLS with an invalid encap type

Switching Speeds

Fastest to slowest as per Cisco best practice:

  • 1. Distributed CEF (DCEF). The name is the recipe – the CEF workload is distributed over multiple CPUs.
  • 2. CEF
  • 3. Fast Switching
  • 4. Process Switching (sometimes jokingly referred to as “slow switching” – it’s quite an involved process and is a real CPU hog)