Cisco and NASA this week said they are collaborating on an online global monitoring platform to capture, collect, analyze and report data on environmental conditions around the world.
Called “Planetary Skin,” the project will involve NASA and Cisco working to develop the online platform to capture and analyze data from satellite, airborne, sea- and land-based sensors across the globe. This data will be made available for the general public, governments and businesses to measure, report and verify environmental data to help detect and adapt to global climate change.
Please read the full article on NetworkWorld.com…
Before we begin let’s see what is this SLA term, for those of us who are not very familiar with the Service Provider terms. IP Service Level Agreements (SLAs) enable customers to assure new business-critical IP applications, as well as IP services that utilize data, voice, and video, in an IP network. With Cisco IOS IP SLAs, users can verify service guarantees, increase network reliability by validating network performance, pro actively identify network issues assure an easy way to deploy new IP services. Cisco IOS IP SLAs use active monitoring, enabling the measurement of network performance and health.
For the following how-to please have a quick look into the topology. As you can see I have a basic routing topology, imported from another tutorial from FirstDigest, and let’s assume that we want to monitor the line between R1 and TEST-RT. For this we will configure a very simple IP SLA monitor, based on icmp echo packets, which will measure our RTT (Round Trip Time) or latency and provide us with valuable informations. For example in case of VoIP problems we can check the latency and in case of a value bigger than 200 ms (220 ms maximum accepted for the voice service to function properly) we will know from where are the problems generated. Of course IP SLA can have more complex configuration under Cisco IOS (e.g. http or ftp transfer to check if the service provider assure us the bandwidth specified in the contract).
One personal advice from my experience. Even if all the data and information provided by IOS IP SLA monitor can be checked with “show…” commands, I would advice you to get a third party software that can interpret this data for you and draw nice graphs or store them in an archive for you. This kind of software are MRTG, Weathermap, Nagios, RRDtool and others (I put here only the free ones).
Please check the how-to by clicking the image below:
The official term of Cisco for Packet sniffing is SPAN ( Switched Port Analyzer ) also called sometimes port mirroring or port monitoring and it’s purpose is to select traffic from a source and send to a destination with a network analyzer tool. You can find out there terms like RSPAN, PSPAN, VSPAN, ESPAN, but this are at their basic functionality nothing more than SPAN with some enhanced features ( e.g. ESPAN – Enhanced SPAN ) or describing their primary functionality ( e.g. VSPAN – Vlan SPAN – used to monitor vlans ).
Now, depending on you Cisco platform some of this xSPAN can be supported or not. A list with them you can find here.
On the high-class products, like 6500, you can find another device called NAM ( Network Analysis Module ) which enhance SPAN by providing a web interface and a local embedded traffic analyzer. Maybe someday, if I have a spare device I will make a short tutorial about NAM module.
For the basic SPAN configuration purpose I will use a c3750 as this method is supported on many more devices ( e.g. 3550, 3560, 2950, 2900XL). One notice before we begin. On the port where you redirect your SPAN traffic and where you connect your device with traffic analyzer, you don’t need a Layer 3 address. So, just let that port with plain Layer 2 configuration.
Please see the tutorial below: