Cisco IP SLA is a function of Cisco’s IOS

IP SLA is a function of Cisco’s IOS enabling you to analyze a Service Level Agreement (SLA) for an IP application or service. IP SLAs use active traffic-monitoring to continuously monitor traffic across the network. This is very different from SNMP or Netflow data which give you more volume oriented statistics. Many different metrics can be analyzed using IP SLA, here is a break down of a few.

• UDP Jitter – Probably the most used operation in all of IP SLA. This IP SLA generates UDP traffic and measures Round-trip Delay, One-way Delay, One-way Jitter, One-way Packet Loss, and overall Connectivity.
• ICMP Path Jitter – Hop-by-hop Jitter, Packet Loss, and Delay.
• UDP Jitter for VoIP – Enhanced test for VoIP monitoring. It can simulate various codecs and spits out voice quality scores (MOS, and ICPIF). Also shows us Round-trip Delay, One-way Delay, One-way Jitter, and One-way Packet Loss.
• UDP Echo – Round-trip Delay for UDP traffic.
• ICMP Echo – Round-trip Delay, full path.
• ICMP Path Echo – Round-trip Delay and Hop-by-hop round trip delay.
• HTTP – Round-trip time using simulated http traffic.
• TCP Connect – Allows us to sample the time to connect to a target using TCP.
• FTP – Round-trip time for file transfers.
• DHCP – Round-trip time for dynamic host configuration.
• Frame-Relay –Round-trip Delay, and the Frame Delivery Ratio. Mostly used for circuit availability.

IP SLA Configuration

There are 2 parts to the IP SLA configuration. Our testing source, and the responder. Typically our responder is a device local to the data center, while the test host is device at a remote site. The test host sends data to the responder and the responder sends a reply back. The configuration for the responder is nothing but really, really simple…

ip sla responder

Seriously. Now lets take a look at the configuration of the testing source. Any questions I don’t answer here should be easily available via IOS context help… Here is an example I’m using in production.

ip sla 10                                                        ! New IP SLA Instance #10
  udp-jitter 10.1.1.1 16800 source-ip 10.2.2.2 codec g711ulaw    ! udp jitter w/Voice codec
  tos 184                                                        ! TOS bit, using EF here
  frequency 300                                                  ! testing interval
ip sla schedule 10 life forever start-time now                   ! start now, never stop

So, what does this get us? Here are the stats output by our IP SLA source..

Router#sh ip sla statistics 10    ! Omit the # to view all SLA stats.
IPSLAs Latest Operation Statistics

IPSLA operation id: 10
Type of operation: udp-jitter
        Latest RTT: 42 milliseconds
Latest operation start time: 18:28:06.603 UTC Thu May 5 2011
Latest operation return code: OK
RTT Values:
        Number Of RTT: 1000             RTT Min/Avg/Max: 39/42/154 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 1000
        Source to Destination Latency one way Min/Avg/Max: 25/26/41 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 13/15/127 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 999
        Number of DS Jitter Samples: 999
        Source to Destination Jitter Min/Avg/Max: 0/2/15 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/2/90 milliseconds
Packet Loss Values:
        Loss Source to Destination: 0           Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0
        Packet Late Arrival: 0  Packet Skipped: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 1
MOS score: 4.34
Number of successes: 7
Number of failures: 0
Operation time to live: Forever

Conclusion

Cisco’s IP SLA features can be a huge benefit to any engineer trying to track down issues on the network. Using IP SLA in combination with a SNMP management suite, or even an EEM script can provide real time alerting for adverse network conditions, allowing you to respond faster and perform better.

Reff Cisco/  http://routerjockey.com/2011/05/06/ip-sla-basics/comment-page-1/#comment-27804

Cisco Load balancing with CEF for IP

Load balancing with CEF for IP

In IOS software 11.1CC a new forwarding mechanism for IP packets was introduced: Cisco Express Forwarding (CEF). The design of Cisco Express Forwarding includes enhancements that allow to use load balancing without sacrificing forwarding performance even when using per packet load balancing. Previously per packet load balancing required disabling of route-caching mechanisms like fast switching or optimum switching . CEF is available in IOS software version 11.1CC for Cisco 7200 and 7500 series routers only. CEF currently supports the following encapsulations: ATM/AAL5snap, ATM/AAL5mux, ATM/AAL5nlpid, Frame Relay, Ethernet, FDDI, PPP, HDLC, and tunnels. 

 How CEF load balancing works

CEF is an advanced Layer 3 switching technology inside a router. Usually a router uses a route cache to speed up packet forwarding. The route cache is filled on demand when the first packet for a specific destination needs to be forwarded. If the destination is on a remote network reachable via a next hop router, the entry in the route cache is consisting of the destination network. If parallel paths exist this does not provide load balancing, as only one path would be used. Therefor the entry in the route cache now relates to a specific destination address, or host. If multiple hosts on the destination network are receiving traffic a route cache entry for each individual host is made, balancing the hosts over the available paths. This provides per destination load balancing. The problem that arises is that for a backbone router carrying traffic for several thousands of destination hosts a respective number of cache entries is needed. This consumes memory and makes cache maintenance a demanding task. In addition the decision about which path to use is done at the time the route-cache is filled, and it is based on the utilization of the individual links at that point in time. However the amount of traffic on individual connections can change over time, possibly leading to a situation where some links carry mostly idle connections and others are congested. CEF takes a different approach as it calculates all information necessary for the forwarding task in advance and decouples the forwarding information from the next hop adjacency, which allows for effective load balancing.

The two main components of CEF operation are the 

• Forwarding Information Base
• Adjacency Tables

Forwarding Information Base

CEF uses a Forwarding Information Base (FIB) to make IP destination prefix-based switching decisions. The FIB is conceptually similar to a routing table or information base. It maintains a mirror image of the forwarding information contained in the IP routing table. When routing or topology changes occur in the network, the IP routing table is updated, and those changes are reflected in the FIB. The FIB maintains next-hop address information based on the information in the IP routing table. Because there is a one-to-one correlation between FIB entries and routing table entries, the FIB contains all known routes and eliminates the need for route cache maintenance that is associated with earlier switching paths such as fast switching and optimum switching.

Adjacency Tables

Network nodes in the network are said to be adjacent if they can reach each other with a single hop across a link layer. In addition to the FIB, CEF uses adjacency tables to prepend Layer 2 addressing information. The adjacency table maintains Layer 2 next-hop addresses for all FIB entries.

The adjacency table is populated as adjacencies are discovered. Each time an adjacency entry is created (such as through the ARP protocol), a link-layer header for that adjacent node is precomputed and stored in the adjacency table. Once a route is determined, it points to a next hop and corresponding adjacency entry. It is subsequently used for encapsulation during CEF switching of packets. A route might have several paths to a destination prefix, such as when a router is configured for simultaneous load balancing and redundancy. For each resolved path a pointer is added for the adjacency corresponding to the next-hop interface for that path. This mechanism is used for load balancing across several paths. For per destination load balancing a hash is computed out of the source and destination IP address. This hash points to exactly one of the adjacency entries in the adjacency table, providing that the same path is used for all packets with this source/destination address pair. If per packet load balancing is used the packets are distributed round robin over the available paths. In either case the information in the FIB and adjacency tables provide all the necessary forwarding information, just like for non-load balancing operation. The additional task for load balancing is to select one of the multiple adjacency entries for each forwarded packet.

Juniper : - coming soon 

Bridge aggriation group with Lacp

Core switch : 

1.   Create the bridge aggriation group

2.   Apply the link aggregation settings (link-aggregation mode dynamic &
mad enable)

3.   Then log into the switch interface where you are going to construct the LACP.On plain interface shutdown and add the interface the to the LACP group

eg: link-aggregation group 1. once you add all the interface into the group individually un-shut the ports.

4.   Execute the command : disp link-aggregation verbose bridge-aggregation <group no.> to see whether the ports are selected.

5.   Once the Switch end configuration of the above steps are completed you have to convert the bridge to trunk by executing the command

: Int br 1

:port link-type trunk

: port trunk per vl <Vlan ID>

Access Switch :

1.   Create the bridge aggriation group

2.   Apply the link aggregation settings (link-aggregation mode dynamic )

3.   Then log into the switch interface where you are going to construct the LACP.On plain interface shutdown and add the interface the to the LACP group

eg: link-aggregation group 1. once you add all the interface into the group individually un-shut the ports.

4.   Execute the command : disp link-aggregation verbose bridge-aggregation <group no.> to see whether the ports are selected.

5.   Excecute the below command on the bridge to conver the link to trunk ans allow the vlan for accessibility.

: Int br 1

:port link-type trunk

: port trunk per vl <Vlan ID>

Core devices

interface                                                                                               
description ****CONNECTED TO ****
port link-type trunk
port trunk permit vlan 1 300
link-aggregation mode dynamic
mad enable
============================

Access devices Configuration

interface Bridge-Aggregation1
port link-type trunk
port trunk permit vlan 1 300
link-aggregation mode dynamic

Configuring a combo interface

Introduction to Combo interfaces

A Combo interface is a logical interface that comprises one optical (fiber) port and one electrical (copper) port. The two ports share one forwarding interface, so they cannot work simultaneously. When you enable either port, the other port is automatically disabled.

The optical and electrical ports of a Combo interface share one interface view, in which you activate the optical or electrical port, and configure other port attributes, such as the interface rate and duplex mode.


Configuration sample 


interface interface-type interface-number
combo enable { copper | fiber }