Tag: cisco

Useful documentation sheets at packetlife.net

Packetlife.net offers some “cheat sheets” with useful information. This are like very small handbooks with the most useful informations about BGP, EIGRP, IPsec, Multicast, IS-IS, OSPF, Spanning-Three, TCPdump and more. I found this very useful during my preparations for Cisco exams and not only, so I want to share them here. Of course any copyrights goes to the owner of packetlife.net. And if you are worry about the “cheat” word, look what the owner of packetlife.net is saying:

“Are these for cheating?

No. The term “cheat sheet” is a slang term for a small collection of notes or a quick reference guide (my apologies if this isn’t a familiar term in your locale). I don’t condone cheating of any sort, and you’re only doing yourself a disservice if you decide to take that path.”

You can check this materials at: http://packetlife.net/cheatsheets/

Posted on by Calin 2

Cisco: How to use CEF for load-balancing

According to Cisco’s website, Cisco Express Forwarding (CEF) is advanced, Layer 3 IP switching technology. CEF optimizes network performance and scalability for networks with large and dynamic traffic patterns, such as the Internet, on networks characterized by intensive Web-based applications, or interactive sessions.

The term Load balancing describes a functionality in a router that distributes packets across multiple links based on layer 3 routing information.

Now, putting this two terms together we obtain Load balancing with CEF. Cisco IOS software basically supports two modes of load balancing: On per-destination or per-packet basis.
In per-destination mode all packets for a given destination are forwarded along the same path. Usage of only one path will lead to a unequal usage of the lines, as the packets to the same destination will use only one line, leaving the other unused. This can be a problem in a small environment where let’s say that a location is having 2 x E1 connection. In per-destination mode, all the packets to one destination will use one E1 connection, and the other line will remain unused. In addition to this, if this one destination is a server on which most on the site’s users will connect to, the per-destination mode will lead to an exhaust of the bandwidth available on one E1 line leaving the other one empty. On the other hand, on more developed location, where there are more destination available, the per-destination method will not have too much impact about the usage of the lines, as in this case the traffic will be split for the multiple destinations over multiple paths.

The per-packet mode guarantees equal load across all links because the forwarding process determines the outgoing interface for each packet by looking up the route table and picking the least used interface. If you read until now, than most probably you will say that this method is the best and then why the per-destination mode is the default one. Some issues with the per-packet mode would be that this method will almost always result in out-of-order packets, as advised by Ivan Pepelnjak, on his blog. What I can tell you is that this out-of-order packets has not a big impact on low-speed environment where TCP stack can deal with this problem. On the other hand on high-speed environment where video or voice traffic is expected, you can have big problems and it’s better to avoid the usage of per-packet load-balancing. Also, Cisco is advising that this ensures equal utilization of the links, but is a processor intensive task and impacts the overall forwarding performance. How much will impact on the CPU / resources usage? I cannot tell exactly because this depend on the task and traffic that the device has to handle.

OK, so if this per-packet mode is not so great, than why we should use it? The answer is that in some particular topologies or environments you cannot use other method of load-balancing and you are in desperate need of such mechanism. Below you will see an example of what kind of topology can force us to use per-packet load-balancing.

Before you configure load-balancing, you have to be sure that IP CEF is enabled on your router. In case that it is disabled, please enable it:

configure terminal
ip cef

If you want to fine tune the IP CEF load-balancing algorithm you can do this with the command:

configure terminal
ip cef load-balancing algorithm “name parameter”

where for “name” you have 3 choices:
original – Sets the load sharing algorithm to the original based on a source and destination hash.
tunnel – Sets the load sharing algorithm for use in tunnel environments or in environments where there are only a few IP source and destination address pairs.
universal – Sets the load sharing algorithm to the universal algorithm that uses a source and destination, and ID hash.
Skipping the tunnel option which you should use only if you are sure that you need it, the other choices would be universal and original. Original algorithm use IP addresses to generate the 4-bit hash. On the other hand universal algorithm add a router specific information to the hash leading to a more complex development of the hash value. Since universal option is the default one, exception the case where you know what you are doing, you should not change this value.

To enable IP CEF load-balancing on per-destination base, you don’t have to modify anything, as it’s enabled by default. For per-packet mode, you have to use the following commands:

configure terminal
interface FastEthernet x/y
ip load-balancing per-packet

ip-cef-load-balancingOne scenario where I had to use per-packet load-balancing is the one below.
Let’s assume that we have client (c-ubuntu-1, 10.10.20.100) which is sending traffic to one server (s-ubuntu-1,10.10.10.100). The routing protocol is already configured in such way that CE1 and CE2 routers are announcing, through OSPF, 2 default routes (equal cost) to SC device. The rest of the routing part is assure by BGP towards PE routers and another IGP protocols, but this has no importance for the topic discussed here.

SC1#sh ip route | i 110/1
O*E2 0.0.0.0/0 [110/1] via 172.29.190.237, 02:35:46, Vlan23
[110/1] via 172.29.190.229, 02:35:46, Vlan13

On the SC devices I used L3 interface vlan 23 to connect to CE2 and vlan 13 to connect to CE1. With the CEF enabled and per-destination load-balancing mechanism, only one  path (either vlan 23 or vlan 13) was used, leading to only one WAN serial connections to be used. Since this was client to server traffic, and quite a lot, from time to time one WAN connection was exhausted while the other one  remains unused. You can see this, in the excerpt below:

SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100    -> 10.10.10.100   : Vlan23 (next hop 172.29.190.237)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100    -> 10.10.10.100   : Vlan23 (next hop 172.29.190.237)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100    -> 10.10.10.100   : Vlan23 (next hop 172.29.190.237)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100    -> 10.10.10.100   : Vlan23 (next hop 172.29.190.237)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100    -> 10.10.10.100   : Vlan23 (next hop 172.29.190.237)

After I enabled the per-packet load-balancing, the situation has changed since both lines to CE routers where used, leading to a equal utilization of the WAN lines:

SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan23 (next hop 172.29.190.237)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan13 (next hop 172.29.190.229)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan13 (next hop 172.29.190.229)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan23 (next hop 172.29.190.237)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan23 (next hop 172.29.190.237)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan13 (next hop 172.29.190.229)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan23 (next hop 172.29.190.237)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan13 (next hop 172.29.190.229)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan13 (next hop 172.29.190.229)
SC#sh ip cef exact-route 10.10.20.100 10.10.10.100
10.10.20.100 -> 10.10.10.100 : Vlan23 (next hop 172.29.190.237)

I had to choose this method to force the equal usage of the WAN links and I rely on TCP stack to solve the out-of-order packets as there is not so high traffic over this interfaces.

Posted on by Calin 5

3G Solutions for Cisco Integrated Services Routers

[flashvideo filename=https://ipnet.xyz/vid/archive/2009/06/3GforCiscoIntegratedServicesRouters.flv image=https://ipnet.xyz/vid/archive/2009/06/3GforCiscoIntegratedServicesRouters.jpg /]

Posted on by Calin 0

Cisco: OSPF conditional inject of a Default Route

I believe most of you are familiar how OSPF is injecting a default route in a normal area. If not, you can find here all the documentation that you need. Please be familiar with this concept before reading this article.

Now, let’s assume that we have the following topology (click on image to have a more detailed view) :cisco-ospf-conditional-default-route

As you can see we have a BGP peering between PE and CE router, with CE router having and OSPF connection with the Core. CE router is injecting a default route to Core:

router ospf 1
default-information originate always

This configuration is OK, but we can run into the following issue. Imagine that for some reason the BGP peering between PE and CE is broken (e.g. line being down), the CE router will have no clue about this and will still propagate the default route to the Core. In this situation, the Core will still forward all the packets without specific route to CE where it will have no further route to reach the destination, as the CE does not receive any route from the BGP peer. As you can imagine is better to avoid this situation, especially if for some reasons you are not monitoring the connection between PE and CE and you cannot react to change manually the route in case of a failure. We are lucky because some smart engineers have developed a solution to avoid this problem, called Conditional inject of a default route in OSPF.

With this solution, OSPF is monitoring the reachability of the point-to-point IP connection between PE and CE. When OSPF process on CE router notice that the IP connection is not available anymore, it automatically retract the propagation of the default route to the Core. The solution is simple an assume use of  an ACL or prefix-list then match this on a route-map and finally use this route-map under “router ospf” process. For step-by-step configuration check below.

First we will create and ACL matching the IP subnet between PE and CE. In this example I’m using a p2p subnet 10.10.10.0 /30:

access-list 1 permit 10.10.10.0 0.0.0.3

Then I will match this into a route-map as follow:

route-map WAN-LINK permit 10
match ip address 1

Finall, we will use this route-map to implement the OSPF conditional injection of default route to Core router (192.168.0.0 /30 is the p2p IP subnet between CE and Core):

router ospf 1
log-adjacency-changes
network 192.168.10.2 0.0.0.0 area 0
default-information originate always route-map WAN-LINK

Now, the OSPF process on CE will inject a default route to the Core as long as the IP subnet between CE and PE is reachable.
IMPORTANT NOTE: This solution might not work if your connection from CE to PE is Ethernet and not Serial like in the example. I will explain why on the next post, when I’ll achieve the same behavior but using EEM together with an Ethernet based connection instead of a Serial one.

Please check below to see a small presentation how this is working on a test environment:

cisco-ospf-conditional-default-route-post

Posted on by Calin 7

Cisco Hosts Investor Webcast: Consumer Strategy

Source: http://newsroom.cisco.com

June 15, 2009 – Cisco will host a webcast for the financial community with a corresponding slide presentation to discuss the company’s Consumer strategy, highlighting its consumer vision, market opportunity and expansion of its portfolio.

Who: co-hosted by Cisco executives, Ned Hooper, senior vice president of Corporate Development and Consumer, and Guido Jouret, vice president, chief technology officer of the Emerging Technologies Group. Following a brief presentation, a question & answer session will be held.

No previously unannounced issues will be discussed in this webcast.

Date: Tuesday, June 16, 2009

Time: 2:00pm PT

Listen and watch via the Internet:
Please listen to the webcast online at http://www.cisco.com/go/investors. We will offer live and replay audio broadcast of the conference call, with synchronized slides, on this website.

RSVP:
No RSVP is necessary

Posted on by Calin 0