“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:
- 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.
- 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.
- 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.
- 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:
- TIME, port 37
- TACACS, port 49
- DNS, port 53
- BOOTP/DHCP Server, port 67
- BOOTP/DHCP Client, port 68
- TFTP, port 69
- NetBIOS name service, port 137
- NetBIOS datagram service, port 138
- 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