February, 2009 | IPNET

Network-based protection against denial-of-service-attacks

NetworkWorld News

A recent announcement by Verizon Business concerning an expanded suite of protection “in the cloud” from denial-of-service-attacks is a great example of services that should be provided within the service providers’ networks – something that we’ve been advocating for years.

Of course, there’s nothing new about denial-of-service-attacks. These attacks, which started primarily as “TCP SYN” attacks, basically are designed to disable a site – or even an entire network – by using up critical network resources with bogus traffic of some form.

Read the full article on networkworld.com…

Cisco: How to configure Frame-Relay Hub and Spoke in simple steps

Some days ago, during my preparation for CCIE RS I had to configure Frame-Relay Hub and Spoke environment. Since I already did it, I said that is good to have it here also, maybe somebody will find it useful. Even if it sounds quite complicate as title, FR hub and spoke. This post assume that you are somehow familiar with Frame-Relay concept and you know basic stuff. If you need to refresh your knowledge there is good topic about Frame-Relay on Ciscopress page.

So, what is this FR hub and spoke anyway? A basic example is with 3 device (can be more) in which on of them connect the other ones in a central point. This is the opposite to (full or circular) mesh in which every router is connected with at least another 2 devices. For things to be more clear please have a look to this topology file.

As you can see in the topology provided, R1 is connecting the other 2 routers in a central point. R1 device is the Hub and R2, R3 are the Spokes. Like explained in the topology, the green lines represent PVC circuit and red ones the physical connection. The communication between R2 and R3 will be done only through R1 since there is no PVC that connect this 2 devices. You can be tempted to say that the communication is direct, because red lines have a common point in the FR switch, but the things are not like this. This is not Ethernet, so for L3 to work you need a map from L2 to L3. Since there is no PVC define in FR switch for R2 to R3 communication, everything is passing through R1.

To configure Frame-Relay Hub and Spoke is not very difficult. The most hard part is regarding FR switch, but luckily you don’t have to deal with it, as this is usually a provider equipment, and they will do the L2 to L3 frame-relay routing, providing you with the need DLCI information. From this point you only have to be careful to details (IP, DLCI, interface) when configuring frame-relay map on your devices.

In a future post I will extend this topic and show how you can configure OSPF in a Frame-Relay Hub and Spoke environment. For now please check this topic presented in the tutorial below:

If Flash movie is not available for you, then please check this text file which contains the configuration.

Cisco: Quick IOS check in 4 simple steps

This post is rather for the beginners in Cisco’s world than for advance professionals, but still I encounter situation when IOS image was corrupted even if it was uploaded to the device by a network guru. Why? It’s quite simple! Because you can be the master of the Cisco networking, but still sometime you cannot control the device behavior or the transport of the packets to destination.

The problems is that in case of a corrupted IOS image being uploaded on a Cisco device, and having that device reloaded you can run into situation when it will not boot up anymore. When the device is in front of you, or on your desk, there is not a problem, because you can troubleshoot, find the issue (e.g wrong or corrupted IOS image) and solve it! But, what if your device is at 5000 km distance, it is 3:00 AM and you have no professional help on that location?! That’s one ugly situation and the reason for which I always insist to verify the IOS image after it is uploaded and ready to go into production.

For those of you who are dealing with this stuff everyday, this post may seem like a joke, but I bet that there are out there IT’s which never check this stuff or they are beginners and don’t know how to do it. It’s more simple that you may think it is, make you spend about 4-5 minutes for a full check, but can spare you for bigger problems in the future.

So, what are the 4 steps:
1. Check what Cisco device you have (to know what IOS image you need)
2. Check what IOS image Cisco device has (to know what IOS release to download)
3. Verify the IOS image
4. Check the results of your verification
As simplest as it can get.

Please check the tutorial by clicking the image below:

For those who cannot see a Flash movie, please read this text file, that consist of the command you should perform for IOS checking.

Cisco: How-to get notifications for IP SLA monitor using EEM

In some previous post, I explained how to configure a basic IP SLA monitor for checking the round-trip time between two Cisco routers. Because in the comments of that post I have been asked how you can get e-mail notification for IP SLA monitor, I have decided to write another post to extend a little bit this topic.

To accomplish e-mail notification for IP SLA monitors we will use Embedded Event Manager (EEM) and some SNMP knowledge.Cisco IOS EEM is a powerful device and system management technology integrated into specific Cisco switches and routers. EEM gives us the ability to customize Cisco IOS behavior based on network events as they happen.

EEM will use a SNMP event to report anomalies in regarding the RTT threshold value. For SNMP to work we need to know and Object name and the OID associated with it. In my example I will use the SNMP Object name: rttMonCtrlOperOverThresholdOccurred (OID: 1.3.6.1.4.1.9.9.42.1.2.9.1.7). On Cisco website you can find more about this SNMP Object and I advice you to read it before going on with this tutorial.

Below you have a basic example about how to get e-mail notification when the threshold of the RTT IP SLA monitor is reached. More examples you can find on Ivan Pepelnjak’s blog: blog.ioshints.info . It’s a good idea to check them also.

The topology remains the same like in the previous post about IP SLA. You can check it here. Please click below to check the tutorial:

If you cannot check the tutorial above, please read this text file, as it contains all the information from the video presentation.

Cisco: FWSM CPU stress test how-to

Sometime ago I had to do a stress test for a Cisco FWSM (Firewall Service Module) to see how the resources are consumed and if some potential traffic can temporarly affect the behavior of this device. For those of you who have don’t know what is a Cisco FWSM, here comes the definition: “Cisco Firewall Services Module (FWSM)—a high-speed, integrated firewall module for Cisco Catalyst 6500 switches and Cisco 7600 Series routers—provides the fastest firewall data rates in the industry: 5-Gbps throughput, 100,000 CPS, and 1M concurrent connections”.

Since I didn’t had a hardware packets generator, I had to use a software one: IPerf . This is a tool that measure the maximum TCP or UDP bandwidth performance. Iperf allows the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.Also it can run under Linux, Mac and Windows so the platform shouldn’t be a problem for you. As i said before, I used for testing my notebook as packet generator and a Linux server with DNS service enable as destination. Every packet from source (notebook) to destination (DNS server) was passing through FWSM, where it was inspect at OSI Layer 7 (DNS Application). Please check the topology file to have an idea about the configuration. Please be aware that if the packets (in our case DNS) are not to be inspected by FWSM, than the resource utilization of the FWSM is not so high, even in case of big traffic flow.

Please have a look below for the video presentation of the tutorial:

If you cannot see the video tutorial above, please check this text file which present in text mode everything needed to configure to do a stress test tool.