Friday, July 29, 2011

Rate Limit Calculator AKA CAR (Committed Access Rate)

Recently I have been asked for quick method to calculate " CAR Parameters also known as Rate Limit ". 

So don't confuse this CAR with our well known CAR :-)

Anyways... here is a great work done by "Brian" on Cisco learning Network site for your help... awesome work I would say.

BTW.... In modern days we have QOS tool called " policing " which is essentially modern way of doing CAR using MQC (Moduler QOS CLI).

Deepak Arora

Monday, July 25, 2011

BGP Rule Of Synchronization

Recently I saw lots of discussions going around on Cisco Learning Network (CLN) about BGP Rule Of Synchronization. I feel the rule sounds quiet confusing to most of beginners. Following are the common confusions that people have:

Rule - " Route learned from One IBGP Peer cannot be advertised to another IBGP peer unless it's verified by the IGP Routing or IGP Routing table has match for same route in routing table."

Now to overcome this rule we have few options.

1. Run IGP.... hehe... Simple enough ? :-)

But problem with doing that is you need to redistributed BGP into IGP. If these are few BGP routes that not a big deal, but if we are talking about redistributing entire Global BGP Internet Routing Table... You gonna mess up with Your IGP, since IGPs are not designed to manage Route Tables this big.

2. Make BGP Peerings Full Mesh.

3. Route BGP updtes beteen EDGE BGP Devices of SP core using Tunnels such as GRE... of-course not a scalable solution though.

4. Run MPLS in the SP core and use concept of BGP free Core.

Common Confusions :

1. The Rule only applies to learned routes by IBGP peer from an EBGP Peer or also to it's locally Originated Routes ?

2. By IGP means do we have to run some sort of IGP like OSPF, EIGRP or RIP. Or it means IGP reach-ability in general which means static routing is valid solution too ?

Lets Bring Up the topology and see things in action.

So lets turn on "Synchronization"  and see how things are going.

BTW... In most of the modern IOS "Synchronization" is off by Default.

Now as discussed above to overcome " Synchronization" issue, we have few options:

1. Run IGP inside the domain.

2. Create Full Mesh Connectivity.

Since in our scenario, we don't have Full mesh connectivity, so lets turn of synchronization and Configure R3 as Route Reflectors(RR) first.

Route Reflectors and Confederations are two possible solutions BTW to overcome "BGP Rule of Split Horizon" which states that " One IBGP Learned Route Can not be advertised to another IBGP peer"

Lets Turn Sync off now and configure R3 as RR.

Ummm... Seems like we have some Next-Hop Issues. Lets fix those out.

What we have are two options:

1. Tell neighbor to use me as next hop ( nei x.x.x.x next-hop-self)
2. Configure a Route-Map, pointing myself as Next Hop IP  and configure it for  neighbor. ( nei x.x.x.x route-map out )

But it is important to Note that first options doesn't work if your local router is a RR :-)

See yourself....

Lets turn on "SYNC" back and this time instead of running an IGP, Lets see if I put static routes pointing to Null0 (IGP Reach-ability not IGP in itself) can help us.

Seems like the rule indeed talks about the IGP reach-ability and didn't specifically want us to run IGP Protocol.

Though all routes looks now valid and life looks all good, but when we try to ping R5's loopback from R1 with Source as loopback, the packets don't make through.

Reason being is that, static routes that we added are pointing to Null0. Which essentially is Black Holing all your packets.

Lets fix it :

Now Life Looks all good :-)

Deepak Arora

Saturday, July 16, 2011

Some More Troubleshooting Fun With EIGRP

Recently I got this request from a friend working on CCNP. He was looking for some troubleshooting labs. So I thought to help him out with couple of labs and to other people who are preparing for CCNP TS exam.

So to add some fun I created this small troubleshooting lab last night. Below is the topology :

R1 should be able to reach R4's loopback and vice versa. For verification point of view the command -  R4#ping so lo0 should have 100% success rate. Also R4 should be able to telnet R1 and get login prompt.

Here are the initial configuration files and GNS topology for you guys :

Also recently I saw a nice post from CCIE Anthony at which might help you along the way:

Again... Being a good network engineer, Avoid using "sh run" and instead try to find and fix the problem using other "show" commands.

Deepak Arora

Tuesday, July 5, 2011

MPLS VPN Troubleshooting - Bob Calling For Help !!!

Finally after a long gap I am back with my tutorials and labs for learning and fun. Few weeks back I posted MPLS VPN Lab topology, So before explaining it step by step I thought to bring it as challenge for people who already know MPLS from R&S lab prospective and are looking for some troubleshooting stuff on it. So I am going to bring today a MPLS VPN TS challenge for them.

So our old friend BOB was sitting free on monday after noon and then he received an email containing the following topology and two fault tickets.

The topology has got two different MPLS VPNs. One is VPN blue and another is VPN red. VPN blue site 1 should be able to reach VPN blue site 2 and vice versa and same case with VPN RED. But both VPNs shouldn't be able to talk to each other.

Below is the link to download initials for lab along with GNS topology and IOS version details to run it. See if you can help BOB with this problem.

BTW.... Avoid removing configurations completely. Also being a excellent engineer, don't use "sh run" to show your skills.

Deepak Arora