Show run/copy run start on Cisco takes forever?

Are you frustrated that "Show run", "Show run interface <something>, "write mem" or "copy run start" is taking forever on Cisco routers or switches? Rest assure that you are not alone, there are many of us who feel your pain. It even takes longer to return these results on a system containing numerous lines in the running configuration. Why? Because the NVGEN process needs to query everything about your router and then output these results. It's painstakingly long especially when you are in the middle of troubleshooting something. 30 seconds may as well be 30 years. Not to mention that it almost results in a CPU spike sending false alerts everywhere and to everyone. To return the results of the aforementioned commands much faster enable the configuration performance enhancement by typing "parser config cache interface" in the global config mode.

Understanding TCP Window Size / Window Scaling

The easiest way to understand TCP Window size is to observe two people having a conversation. Every so often, the talker will wait for the listener to acknowledge that they have heard everything up to that point. Once the listener acknowledges then the talker begins to talk again. The amount of words spoken before waiting for an acknowledgement from the listener is much like the TCP window size. The official definition of the window size is "the amount of octets that can be transmitted without receiving an acknowledgement from the other side".

BGP - Maximum-path - hidden command

Two is better than one -- More is better or is it? Well I guess we can ruminate on semantics but I think we would rather see how we can implement equal cost multi-path (ECMP) routing using eBGP. By default BGP only installs THE BEST PATH after going through the BGP Bestpath selection algorithm (Cisco).

Consider the simple topology and let's dive in.

Complete config can be found here.

BGP - Configuring mBGP (Multicast BGP)

Do you influence or do you manipulate people to get what you want? What exactly is the difference? I mean in the end, you end up getting what you want right? Wrong, The difference lies in loyalty, if you influence someone then you get them to want to do what you want them to do. If you coerce or manipulate you may achieve short term success, however in the long term you will loose their trust and they will perceive you as someone who violated their trust rather than a leader. Therefore a great leader will influence others to achieve long term success. Although, sometimes you have no choice but to manipulate, for example my wife wants to influence me to do the dishes. Well that's just not going to happen -- she's never going to convince me that I want to do dishes, so she settles for manipulation :). Now that we've gotten my daily tidbit out of the way let's get into the topic at hand which is -- mBGP (Multicast BGP) not to be confused with Multi-protocol BGP which is used by MPLS, IPv6 etc.

Imagine you have Unicast Servers and Multicast Sources on the same network. Furthermore, imagine that you have 2 paths to reach that network, however you want to separate Unicast and Multicast traffic between different paths. How can we achieve this? Well there are a couple of options.

One, we can add static mroutes downstream or you could run mBGP and since the title of this blogtorial is configuring mBGP we'll choose the latter option. 

Consider this simple topology and let's get started. 

Complete configs can be found here.

BGP - Neighbor Allowas-in

My apologies -- It's been a while since I have posted, although I been pondering upon a few topics. I have been extremely busy with work, family, studies... -- Yes that's right I am going for my M.S in C.S :). In any case, enough about my boring personal life and excuses lets get into this action packed blogtorial. Here is a simple problem that I ran into the other night. I get a call from my colleague asking me if I would take a look and see why the routes from an eBGP neighbor are not being put into the routing table. After a couple of minutes of troubleshooting I pin-pointed the issue to a BGP loop prevention mechanism "called AS_Path: If you see your own AS in an update, drop it". Fortunately, there is a way to get around this in case we need to.

RFC 1771 

Section 9.3 states "If the local AS appears in the AS path of the new route being considered, then that new route cannot be viewed as better than any other route.  If such a route were ever used, a routing loop    would result."


To illustrate this in action, let's follow this simple topology.

Complete configurations can be found here.

Securing SSH - Tips & Tricks

Strong Usernames/Passwords
To most of us, this comes as a no-brainer.  To others, not so much...  Regardless, the strength of username/password combinations is extremely important.  If the password being used is a dictionary word or could be derived from the username, there may as well be no password at all...  Ideally, passphrases should be used.  A passphrase is just like a password except for instead of using a word, a phrase would be used.  Passwords and passphrases alike should also be mangled.

iPhone Home - Remote Access to iPhone

Often I have wanted a reliable way to access the contents of my phone remotely (incase I misplace my phone or if my phone gets stolen).  While there are other apps to determine the location of the phone, remotely lock or wipe, etc...  But I still want MORE!  So I decided to try this on my own.

Lets start by simply SSHing into the iPhone...  NOPE!  Wait, you mean to say that you can’t SSH directly into an iPhone connected only to mobile broadband? Yes, it’s sad but true.  Fortunately, we already know how to bypass those pesky firewalls using Reverse SSH!

By following the tutorial “Bypassing Firewalls - Reverse SSH Tunneling” the iPhone can be forced to phone home.  On jailbroken iPhones, this can be achieved manually by running the following command in the terminal or by running the script provided previously.  Currently, there is no way to accomplish such a task on a non-jailbroken device.

Configuring Cisco ZFW - Cisco Zone Based Firewall

The concept of Cisco Zone Based Firewall (ZFW) is very simple yet can quickly turn into a giant two headed dog if you don't understand how to design it. ZFW basically classifies interfaces into security zones and Intra-zone interfaces can pass traffic freely between each other however traffic between Inter-zone interfaces is restricted by default. A quick example can shed more light on this concept.

Consider the simple topology below and let's get started.
  

Configuring CBAC - Context Based Access Control

When it comes to security, I think you should always implement an actual firewall such as an ASA. However if you are a small business and you needed to get a stateful firewall up and running then Cisco Context Based Access Control is the way to go. It's lightweight, easy to configure and it gets the job done.

Consider this topology below and let's see how easily we can get it configured.

Configuring BGP - ORF (Outbound Route Filtering)

Outbound route filtering (ORF) in BGP reminds me of SPAM which I get in my mail everyday. Even though, I end up throwing (filtering) most of it away in the garbage, I still have to spend time looking at it, opening it and/or reading it which in turns wastes my time and my brain cycles. Wouldn't it be much more efficient if I can just tell the post office not to even send it? Well in BGP we can actually do this. We can tell our BGP neighbor what to filter-out before sending updates so we do not have to waste (CPU) time processing it. Ideally this would be implemented in ISPs peering so ISPs do not have to deal with customer requests on what needs to be advertised and what needs to be filtered.

For example, if you are BGP peered with an ISP and you had a route-map to filter all the routes except the default route, the ISP is still sending you the whole internet routing table and your CPU is processing the entire internet table before filtering it down to the default route.

Consider this topology and let's see how we can efficiently perform BGP filtering and conserve our router's resource.

Configuring BGP - Soft Reconfiguration Inbound

We live in a world filled with instant updates. Where you are going? What you are eating? What you did last night? Everything is instantly "updated", "tweeted", and "posted". So why is it that when we make a routing policy change to BGP we have to clear the entire state of the BGP neighbor and tear down BGP peering before it can take effect?

To keep up-to-date with the world we live in we can configure 'BGP Soft Reconfiguration' which will allow us to make routing policy changes to BGP without having to tear down the peering. 

Consider the simple topology below and let's get started. 

Configuring BGP - Local AS - One router multiple ASN

Wouldn't it be awesome if you had two first names and you had the choice to use whichever one you wanted based on some criteria? Well in BGP your first names are your ASN (Autonomous System Numbers). In BGP you can only spin up one instance of BGP with an ASN unlike OSPF or other routing protocols. For example, you will get this error message if you try to spin up more than one instance.

R2(config)#router bgp 200

R2(config-router)#exit

R2(config)#router bgp 201

BGP is already running; AS is 200

So what do you do when you need to have more than one ASN number on the same router? This is where local-as comes in handy. 

Consider this simple topology below and let's get started. 

Configuring MPLS - MPLS ttl-propagation

Would you disclose anything less than what you had to about your network? Certainly I follow the logic that the more I disclose the less secure my network becomes.

This post is a follow up from my 'Configuring MPLS - Easiest L3VPN Ever' and in that post I stated that when we do a traceroute from the CE (Customer Edge) router, we can see inside the MPLS cloud and all the next hop routers are exposed to the customers. Check out the screenshot below.

Configuring BGP - Remove Private AS

Most of you are familiar with private IP addresses. Right? Well the basic concept behind private IP address is that they should not be in the global ISP routing table. Private IP addresses were created to conserve IPv4 space and not to be routed globally. There is something very similar in the BGP world called Private ASN. Bascially, these ASNs should never be advertised from one ISP to another ISP. BGP Private ASNs are to be used within an organization for internal purposes only.

In this blogtorial we will see how we can remove these private AS before sending our update to an ISP.

Consider this simple topology below and let's begin.