CISCO Dreamer

First Attempt: Failed

2012-01-22T19:49:00.000+08:00

I did my attempt first week of November 2011. Sad to say I failed and ran out of time. The topics where not that difficult but one needs to be quick to finish the entire lab. I passed the troubleshooting section but failed in the configuration part.

I am on my way back to my second attempt and I will develop more speed in the configuration part.

Video Blogs

2011-06-15T13:50:00.002+08:00

I am quite busy with my studies now that I don't have time to blog. I am thinking of using Camtasia and instead do a Video blog, saves a lot of time and the explanation will be real time. I want to get active in posting again as the visits in this site seems to be increasing.

Let me know if this is a good idea. Thanks!

Using TCL to Prepare Configuration

2011-01-11T23:24:00.023+08:00

If you have worked as a network engineer for an enterprise or even a telco, you would notice that the best practice to have a standard configuration template. Sometimes, you are stuck in a situation wherein you need to prepare configuration let's say for around 20 routers and time is not on your side. My approach for this when I was starting my networking career was to get that standard template and start filing up the necessary configuration in notepad for the 20 routers and save one file after another. Believe me it was not an easy task and it was prone to having typo's.

It is for sure a tedious task but using TCL, it will pretty much make your life easier. I have researched for a way to automate the config preparation provided you have all the necessary data required. I am not a programmer but somehow I managed to find some TCL software and commands to make this possible. Before we begin we would need to have TCLKIT which can be downloaded here.

Now for this example, let us only try to create configs for 10 routers. Our standard config is as shown below. (not so long so make things easier)


hostname (hostname)
!
interface Serial1/1 
ip address (ip address)(mask)  
!
router ospf 1
network (network) (wildcard) area (ospf area)

The first step is to create our variables, quite much work required for this especially for long standard configs. We will create variables for those with () in the standard config above. These are the parts in the configuration wherein the data will be placed. Standard configuration with variables shown below.


hostname $hostname
!
interface Serial1/1
ip address $ipaddress $ipmask
!
router ospf 1
network $network $wildcard area $ospfarea

Now we have created our variables. Let us use the multivariable "foreach" TCL command to create a looping script. We put in our variables next to the "foreach" statement. The "$" is not required. If you are not familiar with this, please visit this post.


foreach {hostname ipaddress ipmask network wildcard ospfarea}

The next line of this script will now contain the data. Prepare the data in excel spreadsheet and the sequence of the columns should be the same as the one listed in the "foreach" statement. Then add that to the second line of the script. Put an open { before the data and } after the data.
Add also the important commands below that will make auto text file generation for each config file. The final script will look like something below. Then save this as a text file.


foreach {hostname ipaddress ipmask network wildcard ospfarea} {
Router1    1.1.1.1    255.255.255.0    1.1.1.1    0.0.0.0    1
Router2    1.1.1.2    255.255.255.0    1.1.1.2    0.0.0.0    2
Router3    1.1.1.3    255.255.255.0    1.1.1.3    0.0.0.0    3
Router4    1.1.1.4    255.255.255.0    1.1.1.4    0.0.0.0    4
Router5    1.1.1.5    255.255.255.0    1.1.1.5    0.0.0.0    5
Router6    1.1.1.6    255.255.255.0    1.1.1.6    0.0.0.0    6
Router7    1.1.1.7    255.255.255.0    1.1.1.7    0.0.0.0    7
Router8    1.1.1.8    255.255.255.0    1.1.1.8    0.0.0.0    8
Router9    1.1.1.9    255.255.255.0    1.1.1.9    0.0.0.0    9
Router10    1.1.1.10    255.255.255.0    1.1.1.10    0.0.0.0    10

} {set data "

hostname $hostname
!
interface Serial1/1
ip address $ipaddress $ipmask
!
router ospf 1
network $network $wildcard area $ospfarea

"
      set filename "${hostname}.txt"
      set fileId [open $filename "w"]
      puts -nonewline $fileId $data
      close $fileId

}

Now its time to auto generate the configs. What this looping script does is take the first line on the data, do the variable substitution and then at the end it will save the text file with the hostname as the filename. It does this until the last line of the data. The files will be auto generated where the TCLKIT software is saved.

Open TCLKIT, two windows will appear big and small. Click on File -> Source ->Go to the directory where you saved the script as text file -> Change "Files of Type to "All Files" -> Select the Script. Then viola, your configurations appear and all variables substituted. It makes life easier for a network engineer.

Merry Christmas and a Happy New Year to All

2010-12-27T13:23:00.002+08:00

It's been a while since I touched any materials and listened to Scott Morris' Audio bootcamp. My current job really demands a lot of my time. After 3 months of inactivity I promised myself that I will bounce back. I only have 11 months left to take the lab so I'll be studying full force when the new year arrives.

Anyways have a Merry Christmas and Happy New Year to be everybody. Let us overcome any hindrances that tries to stop us from getting our dreams fulfilled. Expect new posts coming when the new year comes. Enjoy!

It's Been A While

2010-10-21T21:59:00.003+08:00

Again, its been a while since I posted something here. I miss the technical stuff I was doing and I could say I was 70% ready for the CCIE exam now I am back to mere 1%. I have a lot more things to share and once again I'll try to find time. Whatever happens my dream to be a CCIE still stands. Hope to hear good news from guys reading my posts.

New Job

2010-08-26T16:31:00.002+08:00

It's just today that I have posted something here and the reason behind this is that I am moving to Singapore for a new job on first week of September. I have been very busy with employment passes and other things required for the transfer. My new job involves lesser technical job than what I did in Hewlett Packard but its around 50/50 similar to my current job in a bank. 50 percent for technical and 50 percent for network project management. Even though I lost the other half to project management :), its still related as I will be handling network projects specifically MPLS migrations. Will my pursuit for CCIE still continue? The answer is yes. I love the technical stuff and its still useful with my current job position. My studies for now is in a standstill though I have finished all the topics I need a round or two to go through again all of them.

I will be posting here topics from time to time since there are people who requested from me. I never thought there are people interested with my blog. :) I have created a Facebook page for those who view my blog entries and those who like to be my friends. Please join/like I WANT TO BE A CCIE in Facebook. See you there and keep in touch.

Answer: Reload Router By Telnet

2010-08-26T16:03:00.010+08:00

Configure a default route from R1 pointing to R2's ip address. The challenge is to reboot R1
from a telnet command from R3 without typing the command "reload".  R3 should not telnet
directly to 12.12.12.1 but instead it should telnet 23.23.23.2 port 3000 to get to 12.12.12.1
port 3005. R1 should automatically ask to proceed to reboot and not ask for username/password
once the telnet from R3 is executed.

Solution is pretty simple. First we need to configure NATing on R2 to translate 23.23.23.2 port 3000 to 12.12.12.1 port 3005.

R2#
!
ip nat inside source static tcp 12.12.12.1 3005 23.23.23.2 3000 extendable
!
interface Serial1/3
 ip nat outside
interface Serial1/1
 ip nat inside

Lets also configure telnet password in R2 for testing.

line vty 0 4
password cisco
login

Now we have solved the first problem. There are 3 issues left on R1, how to make telnet not ask for a password, how to use port 3005 for telnet and how to make the reload automatic. Here's how the configuration should look like.

R1#
!
line vty 0 4
privilege level 15
no login
rotary 5
autocommand  reload

Setting the vty to "privilege level 15" and configuring "no login" by passes user authentication. By default if there is no password set the device will refuse connections. "Rotary 5" command lets you use port 2005, 3005, 4005 and so on for telnet. The "autocommand" feature executes whatever command after the telnet.

Let's test first telneting to 23.23.23.2 using default telnet port.

R3#telnet 23.23.23.2
Trying 23.23.23.2 ... Open


User Access Verification

Password:
R2>

We see it doesn't go to R1 but to R2 instead. Now to test using port 3000.

R3#telnet 23.23.23.2 3000
Trying 23.23.23.2, 3000 ... Open


System configuration has been modified. Save? [yes/no]:

Debug on R1
R1#debug ip packet
*Aug 26 15:47:43.299: IP: tableid=0, s=23.23.23.3 (Serial1/2), d=12.12.12.1 (Serial1/2), routed via RIB
*Aug 26 15:47:43.299: IP: s=23.23.23.3 (Serial1/2), d=12.12.12.1 (Serial1/2), len 44, rcvd 3
*Aug 26 15:47:43.307: IP: tableid=0, s=12.12.12.1 (local), d=23.23.23.3 (Serial1/2), routed via FIB
*Aug 26 15:47:43.307: IP: s=12.12.12.1 (local), d=23.23.23.3 (Serial1/2), len 44, sending

The debug clearly shows that the telnet came from R3. The telnet due to NAT redirected the traffic towards 12.12.12.1. Some people call this NAT redirection. Obviously this is not a practical way to reload routers but this is just for fun and to demonstrate how can be used to redirect traffic. I haven't seen any enterprise using this way to reload and will not see in the future. LOLS!

Lab Challenge: Reload Router By Telnet

2010-06-02T21:55:00.005+08:00

Here's a little challenge, I thought of this during my train trip when I was going home this evening. This should be pretty easy. Consider the diagram below and the scenario.

Configure a default route from R1 pointing to R2's ip address. The challenge is to reboot R1
from a telnet command from R3 without typing the command "reload".  R3 should not telnet
directly to 12.12.12.1 but instead it should telnet 23.23.23.2 port 3000 to get to 12.12.12.1
port 3005. R1 should automatically ask to proceed to reboot and not ask for username/password
once the telnet from R3 is executed.

I believe this should be pretty easy for everyone. Let me know your thoughts on how to solve this challenge. I will post a blog entry regarding this for the next post. For now I need to get back to the belly of the IOS beast. Cheers!

Broadcast/Network Ping

2010-05-29T18:25:00.006+08:00

If there is a need to ping several devices in one same subnet and broadcast domain, you can do several commands or ping like the one below.


R1#ping 10.1.1.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.255, timeout is 2 seconds:

Reply to request 0 from 10.1.1.2, 80 ms
Reply to request 0 from 10.1.1.3, 80 ms
Reply to request 0 from 10.1.1.4, 80 ms
Reply to request 1 from 10.1.1.4, 52 ms
Reply to request 1 from 10.1.1.2, 52 ms
Reply to request 1 from 10.1.1.3, 52 ms
Reply to request 2 from 10.1.1.3, 84 ms
Reply to request 2 from 10.1.1.4, 84 ms
Reply to request 2 from 10.1.1.2, 84 ms
Reply to request 3 from 10.1.1.2, 20 ms
Reply to request 3 from 10.1.1.4, 20 ms
Reply to request 3 from 10.1.1.3, 20 ms
Reply to request 4 from 10.1.1.3, 16 ms
Reply to request 4 from 10.1.1.4, 16 ms
Reply to request 4 from 10.1.1.2, 16 ms

You can also use the Network Address.

R1#ping 10.1.1.0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:

Reply to request 0 from 10.1.1.4, 84 ms
Reply to request 0 from 10.1.1.2, 112 ms
Reply to request 0 from 10.1.1.3, 84 ms
Reply to request 1 from 10.1.1.2, 72 ms
Reply to request 1 from 10.1.1.3, 72 ms
Reply to request 1 from 10.1.1.4, 72 ms
Reply to request 2 from 10.1.1.4, 68 ms
Reply to request 2 from 10.1.1.2, 68 ms
Reply to request 2 from 10.1.1.3, 68 ms
Reply to request 3 from 10.1.1.3, 64 ms
Reply to request 3 from 10.1.1.4, 64 ms
Reply to request 3 from 10.1.1.2, 64 ms
Reply to request 4 from 10.1.1.4, 72 ms
Reply to request 4 from 10.1.1.3, 72 ms
Reply to request 4 from 10.1.1.2, 72 ms

You can also do a single ping command to check if all links in the routers are up or not. You can the following below. This works on all kinds of WAN interfaces connected to the router.


R1#ping 255.255.255.255 rep 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:

Reply to request 0 from 15.15.15.5, 16 ms
Reply to request 0 from 10.1.1.4, 16 ms
Reply to request 0 from 10.1.1.3, 16 ms
Reply to request 0 from 10.1.1.2, 16 ms

This command can be helpful during the CCIE lab exam to verify if interfaces are working. I assume that all who read this already knew this from their CCNA studies but I guess there are exceptions. Even the smartest Cisco Engineers forget basic commands sometimes. Let me know if you are one of those who didn't know this one.

Free Troubleshooting Lab

2010-05-29T14:54:00.005+08:00

If you want to check out Narbik's troubleshooting workbook and want to get an idea of it, you can visit Dan's blog. This contains around 12 trouble tickets and 1 full TS lab challenge consisting of 10 trouble tickets. Good news is that these are Dynamips ready for those who don't have a real home labs.

If I am not mistaken, Dan is Narbik's partner in creating the Micronics Troubleshooting Workbooks. You can also find a free Narbik troubleshooting workbook in this link. Go check it out and have some fun!

Flag Counter

2010-05-29T13:21:00.002+08:00

I have added a flag counter. I haven't realize I need to track from which countries readers are coming from. It's only after I got 25,000 visits based on the counter below the blog, I realized this. Thanks for the people who are visiting this blog.

If you have any topics you wish to request, please do. Despite of my busy schedules for work and study, I'll find time to blog the request.

NAT Stateful Failover

2010-05-28T23:33:00.007+08:00

When the word "stateful" is mentioned in the networking world, it usually means that the router or a firewall keeps records of the sessions created. Stateful failover means that whatever sessions that have been recorded in one device the other backup device has a knowledge of it and can act as a backup without those sessions torn down in case the main device fails. It will function as the same as the primary one. NAT has also the failover functionality. This lab will focus on configuring Dynamic NAT failover.

R3 and R4 are NAT routers. R3 is the primary and R4 is the back up NAT router. These must be configured so that 
R4 will provide stateful failover. Subnets in R1 1.1.1.1/32 - 1.1.1.5/32 should be translated to 
123.123.123.1 - .5 /24. The host side ip address must match e.g. 1.1.1.1/32 = 123.123.123.1/32.

These have been preconfigured:
1. OSPF on all routers.
2. Default route and floating static default route in R5.(for 123.123.123.0/24 reachability)
3. Ip OSPF cost in the links from R2 to R3 and R3 to R5 to disable equal cost path load balancing.

1. First let's configure which is the inside and outside part in the NAT configuration.


R3(config)#int se0/2
R3(config-if)#description connected to R2
R3(config-if)#ip nat inside
R3(config-if)#int se0/3
R3(config-if)#description connected to R5
R3(config-if)#ip nat outside

R4(config)#int se0/2
R4(config-if)#description connected to R2
R4(config-if)#ip nat inside
R4(config-if)#int se0/0
R4(config-if)#description connected to R5
R4(config-if)#ip nat outside

2. Configure an access-list list that will match the IP addresses of Loopback0 in R1 and configure a NAT pool where we will get the translations.


Note: The "match-host" keyword makes it possible for exact host to host translation 1.1.1.1/32 = 123.123.123.1/32, .5 = .5 the 
last octet in the ip address will be the same value. It will match the host portion of the IP address.

R3(config)#access-list 1 permit 1.1.1.0 0.0.0.255
R3(config)#ip nat pool LOOPBACK 123.123.123.1 123.123.123.5 prefix-length 24 type match-host

R4(config)#access-list 1 permit 1.1.1.0 0.0.0.255
R4(config)#ip nat pool LOOPBACK 123.123.123.1 123.123.123.5 prefix-length 24 type match-host

3. Configure a NAT stateful ID. This is what makes the stateful failover possible. This configuration will determine which is the primary NAT router and the backup.


R3(config)#ip nat stateful id 1      ----------> This is locally significant.
R3(config-ipnat-snat)#primary 23.23.23.3
R3(config-ipnat-snat-pri)#peer 24.24.24.4
R3(config-ipnat-snat-pri)#mapping-id 1   ---------> This should match on the routers.
R3(config-ipnat-snat-pri)#exit


R4(config)#ip nat stateful id 1        ----------> This is locally significant.
R4(config-ipnat-snat)#backup 24.24.24.4
R4(config-ipnat-snat-pri)#peer 23.23.23.3
R4(config-ipnat-snat-pri)#mapping-id 1  ---------> This should match on the routers.
R4(config-ipnat-snat-pri)#exit

The "peer" keyword here will do that trick on making the 2 routers related. The ip addresses configured on the "primary" and "backup" parameters should be one of the IP addresses in the router which is configured with the "ip nat inside" command. Otherwise, you will get an error message that its not a match.If 2 backups are configured and they are peer with each other, they won't establish a relationship. A router can be configured as a primary for one mapping-id and back up for another.

After configuring these commands, let's see the logs created by the routers.



R3#
*Mar  1 01:36:33.783: %SNAT-5-PROCESS: Id 1, System start converging
*Mar  1 01:36:45.871: SNAT (Receive): CONVERGENCE Message for Router-Id: 1 from Peer Router-Id: 1's entries
*Mar  1 01:36:45.871: %SNAT-5-PROCESS: Id 1, System fully converged

R4#
*Mar  1 01:34:11.803: %SNAT-5-PROCESS: Id 1, System start converging
*Mar  1 01:34:11.811: %SNAT-5-PROCESS: Id 1, System fully converged
*Mar  1 01:34:48.767: %SNAT-5-PROCESS: Id 1, System start converging
*Mar  1 01:34:50.791: SNAT (Receive): CONVERGENCE Message for Router-Id: 1 from Peer Router-Id: 1's entries
*Mar  1 01:34:50.795: %SNAT-5-PROCESS: Id 1, System fully converged

Let's do a show command that will check the status of the Stateful Failover NAT.


R3#show ip snat distributed

Stateful NAT Connected Peers

SNAT: Mode PRIMARY
  : State READY
  : Local Address 23.23.23.3
  : Local NAT id 1
  : Peer Address 24.24.24.4
  : Peer NAT id 1
  : Mapping List 1

R4#show ip snat distributed

Stateful NAT Connected Peers

SNAT: Mode BACKUP
  : State READY
  : Local Address 24.24.24.4
  : Local NAT id 1
  : Peer Address 23.23.23.3
  : Peer NAT id 1
  : Mapping List 1

4. Configure the IP NAT translation statement mapping access-list 1 and the NAT pool created.


R3(config)#ip nat inside source list 1 pool LOOPBACK mapping-id 1

R4(config)#ip nat inside source list 1 pool LOOPBACK mapping-id 1

5. Now let's test NATing by pingin 5.5.5.5 sourcing from the IP's on Loopback0 on R1. (Will not be shown) We can do "debug ip nat" on R3 and R4, but will only see output in R3 since the traffic passes there. For the sake of a shorter post I will not display the output.

6. Let's check the translation on R3, our main NAT router and afterwards check if R4 is getting the information from the NATing table.


R3#sh ip nat tran
Pro Inside global      Inside local       Outside local      Outside global
icmp 123.123.123.1:20  1.1.1.1:20         5.5.5.5:20         5.5.5.5:20
--- 123.123.123.1      1.1.1.1            ---                ---
icmp 123.123.123.2:19  1.1.1.2:19         5.5.5.5:19         5.5.5.5:19
--- 123.123.123.2      1.1.1.2            ---                ---
icmp 123.123.123.3:18  1.1.1.3:18         5.5.5.5:18         5.5.5.5:18
--- 123.123.123.3      1.1.1.3            ---                ---
icmp 123.123.123.4:17  1.1.1.4:17         5.5.5.5:17         5.5.5.5:17
--- 123.123.123.4      1.1.1.4            ---                ---
icmp 123.123.123.5:16  1.1.1.5:16         5.5.5.5:16         5.5.5.5:16
--- 123.123.123.5      1.1.1.5            ---                ---

R4#sh ip nat tran
Pro Inside global      Inside local       Outside local      Outside global
icmp 123.123.123.1:20  1.1.1.1:20         5.5.5.5:20         5.5.5.5:20
--- 123.123.123.1      1.1.1.1            ---                ---
icmp 123.123.123.2:19  1.1.1.2:19         5.5.5.5:19         5.5.5.5:19
--- 123.123.123.2      1.1.1.2            ---                ---
icmp 123.123.123.3:18  1.1.1.3:18         5.5.5.5:18         5.5.5.5:18
--- 123.123.123.3      1.1.1.3            ---                ---
icmp 123.123.123.4:17  1.1.1.4:17         5.5.5.5:17         5.5.5.5:17
--- 123.123.123.4      1.1.1.4            ---                ---
icmp 123.123.123.5:16  1.1.1.5:16         5.5.5.5:16         5.5.5.5:16
--- 123.123.123.5      1.1.1.5            ---                ---

Though the traffic did not pass through R4, it knows the translation. Notice that the host part of the original ip address and the translated ip address is the same. This is the result of the "match=host" keyword.
Let's see if the failover information by R3 is passed to R4 by a show command.


R4#sh ip snat peer 23.23.23.3

Show NAT Entries created by peer: 23.23.23.3

Pro Inside global      Inside local       Outside local      Outside global
--- 123.123.123.1      1.1.1.1            ---                ---
--- 123.123.123.2      1.1.1.2            ---                ---
--- 123.123.123.3      1.1.1.3            ---                ---
--- 123.123.123.4      1.1.1.4            ---                ---
--- 123.123.123.5      1.1.1.5            ---                ---
icmp 123.123.123.5:16  1.1.1.5:16         5.5.5.5:16         5.5.5.5:16
icmp 123.123.123.4:17  1.1.1.4:17         5.5.5.5:17         5.5.5.5:17
icmp 123.123.123.3:18  1.1.1.3:18         5.5.5.5:18         5.5.5.5:18
icmp 123.123.123.2:19  1.1.1.2:19         5.5.5.5:19         5.5.5.5:19
icmp 123.123.123.1:20  1.1.1.1:20         5.5.5.5:20         5.5.5.5:20

In the even that R3 and the traffic goes to R4, the sessions need not to be restarted as there are already existing translations on R4 which have been passed by R3. Let's shut down the interface in R3 and lets show how R4 reacts.


R4#
*Mar  1 02:11:15.819: %SNAT-5-ALERT: BACKUP staging recovery, replacing Primary
*Mar  1 02:11:15.819: %SNAT-5-PROCESS: Id 1, System start converging
*Mar  1 02:11:15.827: %SNAT-5-PROCESS: Id 1, System fully converged

It places itself as the primary NAT router but the translations that its learned from R3 will continue to be in place. Once R3 goes back up, it will put itself again the backup NAT router.

CCIE Written Cleared

2010-05-22T23:53:00.004+08:00

Finally, I have cleared the written exam last week. This doesn't mean I will stop with the theory stuff, in fact I am reading again the certification guide and some QoS books. I am currently doing Narbik Kocharian's Labs Workbook "The Gap from CCNP to CCIE". Though this might be considered an old workbook by some, but the topics here still apply to the current blueprint. I don't have my own rack so I basically do the labs that can be done in GNS3. I am skipping some topics that can only be done in 3550/3650 switches which I will do in a free community lab that I know of. I am halfway through the topics after this I will do the latest Kocharian's workbook. I might as well consider purchasing Kocharian's troubleshooting labs as I find the sample lab very amusing.

I am not promoting Micronics Training in any way. I really like Narbik's approach: Study the technology one at a time and do as much exploration on one topic. This kind of approach IMHO can really make the candidate understand the topic thoroughly. Many candidates fall into the mistake of doing right away the mock labs like crazy but never really explored the topic one after another. Understanding (again IMHO) what you are configuring is a key to passing the lab.

I have not enrolled in any bootcamp but would love to. My primary reason is MONEY, I don't have tons of it. I am a self paying CCIE candidate. Since I can't attend a bootcamp, I read books and visit Cisco Univercd. We have a saying back home and I paraphrase, "If you can't buy a longer blanket, better learn to fit yourself into the blanket", and this is exactly what I am doing.

My plans for doing the lab will be on January 2011, probably take it in Hong Kong. If I feel that I am ready before that, might consider the mobile lab in Singapore by November. I am spending at least 3 hours a night, and a few hours in the office (if not busy) studying and doing some labs on GNS3. For the next 8 months, I will have little to no social life (I never had one before anyways :D). Good day mates and hold on to the Cisco Dream!

QoS: Classification and Marking

2010-05-08T21:33:00.020+08:00

Classification and Marking is pretty much a self explanatory term. Classify the packet/frame based on number of things such as ip source subnet, protocol, tags, L2/L3 header markings and etc. The fields can be marked are IP header, LAN trunking headers, Frame Relay and ATM headers. This lab will focus on IP precedence and DSCP values on IP packet.


In R1, IP precendence 0,1,2 markings should be marked on packets from 1.1.1.1/32, 11.11.11.11/32 and
111.111.111.111/32 respectively. R2 should check for IP prec packets 0,1,2 and replace them with DSCP markings
AF11, 12 and 13 respectively. R3 should have an inbound policy-map with no action just to keep track of how many
packets have been marked as AF11,12 and 13.

Click on the diagram to resize.

Relevant configurations.


R1:

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
 ip address 11.11.11.11 255.255.255.255
!
interface Loopback2
 ip address 111.111.111.111 255.255.255.255
!
interface Serial0/2
 ip address 12.12.12.1 255.255.255.0
 serial restart-delay 0
!
ip route 0.0.0.0 0.0.0.0 12.12.12.2

R2:

!
interface Serial0/1
 ip address 12.12.12.2 255.255.255.0
 serial restart-delay 0
!
interface Serial0/3
 ip address 23.23.23.2 255.255.255.0
 serial restart-delay 0
!
ip route 1.1.1.1 255.255.255.255 12.12.12.1
ip route 11.11.11.11 255.255.255.255 12.12.12.1
ip route 111.111.111.111 255.255.255 12.12.12.1

R3:

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Serial0/2
 ip address 23.23.23.3 255.255.255.0
 serial restart-delay 0
 service-policy input DSCP
!
ip route 0.0.0.0 0.0.0.0 23.23.23.2

First we need to configure access-list on R1 for every loopback addresses. After which, create a class-map to match the access-groups and policy-map to put the corresponding IP precendence marking per class-map. Apply the policy-map to the interface Se0/2 on an outbound direction.


On R1, configure:
!
access-list 10 permit 1.1.1.1
access-list 11 permit 11.11.11.11
access-list 12 permit 111.111.111.111
!
class-map match-all Loopback2
 match access-group 12
class-map match-all Loopback1
 match access-group 11
class-map match-all Loopback0
 match access-group 10
!
interface Serial0/2
  service-policy output Loopback

Let's proceed configuring R2. Let's match IP precedence and then replace them with DSCP values indicated.


On R2:
!
class-map match-all PREC0
 match  precedence 0
class-map match-all PREC1
 match  precedence 1
class-map match-all PREC2
 match  precedence 2
!
policy-map CHECKER
 class PREC1
  set dscp af12
 class PREC0
  set dscp af11
 class PREC2
  set dscp af13
!
interface Serial0/3
service-policy output CHECKER

On to configuring R3 to match the DSCP values and serve as a inbound counter.


R3:
!
class-map match-all AF12
 match  dscp af12
class-map match-all AF13
 match  dscp af13
class-map match-all AF11
 match  dscp af11
!
policy-map DSCP
 class AF11
 class AF12
 class AF13
!
interface Serial0/2
  service-policy input DSCP

Let's generate some traffic and check the policy-maps later. 100, 200 and 300 packets from Lo0, Lo1 and Lo2 respectively.


R1#ping 3.3.3.3 source lo0 rep 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/12/64 ms
R1#ping 3.3.3.3 source lo1 rep 200

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (200/200), round-trip min/avg/max = 1/13/108 ms
R1#ping 3.3.3.3 source lo2 rep 300

Type escape sequence to abort.
Sending 300, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 111.111.111.111
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (300/300), round-trip min/avg/max = 1/11/92 ms

Let's check the policy-map hits.


R1#sh policy-map int
 Serial0/2

  Service-policy output: Loopback

    Class-map: Loopback0 (match-all)
      100 packets, 10400 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 10
      QoS Set
        precedence 0
          Packets marked 100

    Class-map: Loopback1 (match-all)
      200 packets, 20800 bytes
      5 minute offered rate 1000 bps, drop rate 0 bps
      Match: access-group 11
      QoS Set
        precedence 1
          Packets marked 200

    Class-map: Loopback2 (match-all)
      300 packets, 31200 bytes
      5 minute offered rate 4000 bps, drop rate 0 bps
      Match: access-group 12
      QoS Set
        precedence 2
          Packets marked 300

    Class-map: class-default (match-any)
      11 packets, 876 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

R2#sh policy-map int
 Serial0/1

  Service-policy input: CHECKER

    Class-map: PREC1 (match-all)
      200 packets, 20800 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match:  precedence 1
      QoS Set
        dscp af12
          Packets marked 200

    Class-map: PREC0 (match-all)
      100 packets, 10400 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match:  precedence 0
      QoS Set
        dscp af11
          Packets marked 100

    Class-map: PREC2 (match-all)
      300 packets, 31200 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match:  precedence 2
      QoS Set
        dscp af13
          Packets marked 300

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

R3#
*Mar  1 00:54:36.683: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console
R3#sh policy-map int
 Serial0/2

  Service-policy input: DSCP

    Class-map: AF11 (match-all)
      100 packets, 10400 bytes
      5 minute offered rate 0 bps
      Match:  dscp af11 (10)

    Class-map: AF12 (match-all)
      200 packets, 20800 bytes
      5 minute offered rate 0 bps
      Match:  dscp af12 (12)

    Class-map: AF13 (match-all)
      300 packets, 31200 bytes
      5 minute offered rate 0 bps
      Match:  dscp af13 (14)

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Checking on the show output, we can see that from a normal packet without a marking, it was marked by R1 with IP precedence values and then classified by R2 and remarked again now with DSCP values. We can see we have the same number of packets on the corresponding IP Prec and DSCP values. 0 to AF11 = 100, 1 to AF12 = 200 and 2 to AF13 = 300.


Layer 2 markings such ash CoS, DE, CLP and EXP can only be classified in the ingress
direction and can only be marked in the egress direction only.

No Updates, Yet!!!

2010-02-03T14:11:00.002+08:00

I have no time to write a technical blog as of now as I am currently in transition moving from my current company to a new one. I have to do all the necessary stuff needed for this move. Currently I am reading CCIE Routing and Switching Exam Certification Guide, 4th Edition as preparation for my CCIE written mid this year. I don't have much lab time yet but I do have time reading the concepts I have studied when I took my CCNP. My target is Written this year and probably late this year or early to mid next year for my lab attempt. Will be posting something technical here probably 2 weeks from now.

Study Tip: Gathering Configurations

2010-01-08T10:01:00.005+08:00

I am fond of checking Cisco website and other blogs. Whenever I come across a configuration I am interested whether its something familiar or unfamiliar, I copy that config, save it on a notepad. Though I might not understand some of the configuration files I gather, I find time researching what those config lines mean, try it in Dynamips and read more about it.

If you work doing network configuration changes, doing configs line by line will really get in your nerves. One best practice is to prepare yourself a template config per technology or per setup and save this in a notepad. Network configs in an enterprise environment usually have standard format so this will really save time and you can use time reviewing the config you prepared using the template. In the future the configs you have gathered will surely come in handy.

New Year, New Challenges

2010-01-08T09:42:00.002+08:00

It's been a month since I last posted something and 2 months since I posted something technical. I have been on break from studying since the holiday season started and I am again picking up the momentum on my studies. I am determined to finish my Multicast studies but it seems just reading theories won't satisfy me. Though I am still aiming for my written doing the mini labs sure does help when it comes to understading the topic more.

Before the New Year started, I landed a new job with a multinational banking firm. This will be a new challenge for me because its a new network environment, new setup, new people, everything is new. To be familiar with the network environment takes a few months of study and support. I am pretty excited with that new position and I am sure I will learn and experience more.

As for this blog, it really helps writing something here for my studies. Blogging keeps me on focus and keeps me motivated to study more. I noticed that when I don't blog my motivation for my CCIE diminishes. So for the regular readers ( I don't know if there are even any :)) expect technical posts here regularly. I will be sharing what I have learned from my current environment and the new environment I will be in by February.

Busy with CCIE Written Preparation

2009-12-06T21:13:00.003+08:00

I haven't been able to post lately since I am busy with theory and will be back on the labs once I finish my written exam. For the meantime, I will be posting some notes from time to time. I have several books to read and need to finish them and make sure the theory sinks in. My plan is to take my written exam first quarter next year. I can feel the Christmas season in the air and this chilly air makes me wanna sleep and not study :). For all those of you who celebrate Christmas, happy tidings to you and enjoy your holidays.

IGMP Version 2

2009-11-18T16:08:00.008+08:00

IGMP Version 2 was developed as a solution for the first version's weaknesses. One of which was the inability to detect if there are still hosts which are still members of a multicast group. It will take 3 minutes before the router knows that there are no more members in version 1. The enhancements in Version 2 is shown below.


Group-Specific Query messages – enables the router to do a query operation on specific multicast groups

Leave Group messages – hosts sends a Leave message to the router that they are leaving the multicast group.

Querier election process – can elect the router that will do that query without relying on multicast routing protocols.

Maximum Response Time field - permits the Query Router to specify the maximum Query-Response time. This field
permits the tuning of the Query-Response process to control response burstiness and to fine-tune leave latencies.

The first 2 enhancements above, really helps in saving bandwidth. What happens is, if a host leaves the multicast group, it sends a Leave message. When the router receives this Leave message, it will send out a Group Specific query to that group of which the Leave message indicated and within 10 secs (default) if no host replies a Membership Report the router removes the entry in its IGMP membership table. The router doesn't have to wait 3 minutes like in Version 1.

Below is the Message types.


IGMP Version 2 Message Types

Membership Query (Type code = 0x11)

Two Subtypes:
       General Query – operates the same way like in the
       Group-Specific Query - enables the router to do a query operation on specific multicast groups.

Version 1 Membership Report (Type code = 0x12) - This is for backwards compatibility with version 1.

Version 2 Membership Report (Type code = 0x16)

Leave Group (Type code = 0x17)

Now let’s try this in the lab. I have set up the lab like before using Ubuntu and MINT. To start off, let's configure the router the same way in the IGMP Version 1 post. The command "ip multicast-routing" should be configured under global config mode. Commands "ip igmp version 2" and "ip pim sparse-dense-mode" should be configured on the FastEthernet interface. Let’s see the screenshots on Wireshark. Firstly I have generated the traffic in MINT for the Ubuntu VM to join multicast group 239.10.10.10 port 4321.

The screenshot above shows the Membership report which has a Type code of 0x16. Since in the lab that I made, there are no valid multicast sources, the host immediately sends a Leave message.

We see that the host sends the leave message to a multicast group 224.0.0.2 which means “all routers” in the local subnet. Its clear that they Type code is 0x17. Right below the Leave group message, immediately the router sends a Group Specific Query to check if there are still hosts who are still members on the same multicast group. Also it sends a General Query. Check the screenshots below to spot the difference.

Group Specific Query

General Query

The similarities between both is the Type Code which is 0x11. General Queries send it out to a well known multicast group 224.0.0.1 which is all hosts in the segment. Group Specific queries shows that it sends to the group address. In the Multicast address field, General Queries will have 0.0.0.0 which Group Specific will have the group address.

Finally let’s see the router debug output.

Router>
*Nov 18 15:41:32.759: IGMP(0): Received v2 Report on FastEthernet0/0 from 192.168.59.128 for 239.10.10.10
*Nov 18 15:41:32.759: IGMP(0): Received Group record for group 239.10.10.10, mode 2 from 192.168.59.128 for 0 sources
*Nov 18 15:41:32.763: IGMP(0): WAVL Insert group: 239.10.10.10 interface: FastEthernet0/0Successful
*Nov 18 15:41:32.763: IGMP(0): Switching to EXCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Nov 18 15:41:32.763: IGMP(0): Updating EXCLUDE group timer for 239.10.10.10
*Nov 18 15:41:32.767: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.10.10.10) by 0
*Nov 18 15:41:33.975: IGMP(0): Received Leave from 192.168.59.128 (FastEthernet0/0) for 239.10.10.10
*Nov 18 15:41:33.975: IGMP(0): Received Group record for group 239.10.10.10, mode 3 from 192.168.59.128 for 0 sources
*Nov 18 15:41:33.979: IGMP(0): Lower expiration timer to 2000 msec for 239.10.10.10 on FastEthernet0/0
*Nov 18 15:41:33.979: IGMP(0): Send v2 Query on FastEthernet0/0 for group 239.10.10.10
*Nov 18 15:41:34.979: IGMP(0): Send v2 Query on FastEthernet0/0 for group 239.10.10.10
*Nov 18 15:41:35.979: IGMP(0): Switching to INCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Nov 18 15:41:35.979: IGMP(0): MRT delete FastEthernet0/0 for (*,239.10.10.10) by 0

Why did the router send 2 Group Specific Queries on the debug above? The router in this case used a “Last Member Query Interval” in the range of 10 -1 second in between the Group Specific queries. What it did in our case, was to send on Group Specific query and wait for 1 second and then sends another so by the 2nd time it sent the queries and there is no reply, we see now that it did remove the group from its MRT as the last line of the debug indicated. It should take around 3 seconds as shown above for the router to stop sending traffic for a group if there are no more members. Should there were other hosts in the same multicast group 239.10.10.10 the router will continue forwarding traffic.

Study Tip: Audio Recordings

2009-11-12T10:49:00.004+08:00

I take 2 trains and the company bus going to work each day so I spend around 1.5 to 2 hours travel from my house to my work vice-versa. It's really a waste of time just standing there and looking at the scenery which I have been looking at everyday for almost 2 years. I need to study and make most of my time even when traveling, so what I did is record some of my Cisco notes in audio and convert it to mp3. With my cheap Creative Zen Stone mp3 player, I am able to review even in the train and I am amazed how effective this is for core knowledge. I'll bet if you do this you will even laugh listening at your own voice. An audio class from a reputable vendor is also a great way to study if you don't have time to record your own notes. Listening to audio notes will become one of my daily habits.

IGMP Version 1

2009-10-30T11:17:00.022+08:00

This protocol's version might be old but its very important how to learn the differences between IGMP V1, V2 and V3. It's important to start learning about how the protocol evolved into what it is now. Learning IGMP V1 will give us a foundational knowledge of what IGMP does and how it functions.


What is IGMP?

IGMP is used for hosts who wish to join a multicast address/group, to inform their nearest 
multicast router on which group they wish to be a member of.

Used by routers to maintain a table of multicast group membership per interface. Multicast 
group membership is active on an interface, if the router receives a Membership 
Report from that interface.

It is only needed on IPV4 networks as IPV6 has a different way to handle multicast.

In this entry, I will focus on how the router forms the multicast membership table and what are the most commonly used multicast addresses used to discover multicast members. I will also do some debugs to check how IGMP Version 1 removes a multicast address from the IGMP membership table. The simple diagram is shown below, instructions on how I set up MINT, Wireshark and Ubuntu can be found on the previous blog entry.


Scenario: Ubuntu VM wishes to receive multicast traffic from 239.10.10.10, 239.20.20.20 and 
239.30.30.30. Observe through Wireshark and debug commands how IGMP Version 1 works.

First thing is to configure the router to make multicast work.


R0(config)#ip multicast-routing
R0(config)#int fa0/0
R0(config-if)#ip pim sparse-dense-mode
R0(config-if)#ip igmp version 1

Router#sh ip igmp interface
FastEthernet0/0 is up, line protocol is up
 Internet address is 192.168.18.10/24
 IGMP is enabled on interface
  Current IGMP host version is 1
  Current IGMP router version is 1
 IGMP query interval is 60 seconds
 Inbound IGMP access group is not set
 IGMP activity: 6 joins, 4 leaves
 Multicast routing is enabled on interface
 Multicast TTL threshold is 0
 Multicast designated router (DR) is 192.168.18.10 (this system)
 IGMP querying router is 192.168.18.10 (this system)
 Multicast groups joined by this system (number of users):
     224.0.1.40(1)

These commands are needed to make multicast operate on the router. PIM sparse-dense mode will be discussed on the other entries. I doubt if any aspiring CCIE candidates who already took their CCNP will know nothing about PIM.:)

Then, Wireshark should already be ready to sniff packets on the VMware interface towards Ubuntu VM. From Ubuntu VM Terminal, generate the commands below for the virtual machine to receive traffic for multicast groups 239.10.10.10, 239.20.20.20 and 239.30.30.30. There are no real multicast sources though so don't expect a continous multicast traffic flow. This commands on MINT will only send Membership Report to the router informing that this host is interested joining these 3 multicast groups.


pete@pete-desktop:~/mint-1.2$ mint -r 239.10.10.10 -p 4321
pete@pete-desktop:~/mint-1.2$ mint -r 239.20.20.20 -p 4321
pete@pete-desktop:~/mint-1.2$ mint -r 239.20.20.20 -p 4321

I filtered the output on Wireshark to only show igmp packets and the first 3 outputs are shown below in the red box. My Ubuntu VM's ip address is 192.168.18.129. Click on the picture below to enlarge...

We can see the lines numbered 2, 4 and 7 with the red box that the Info part specifies a V1 Membership Report. Let's see how the router sees the debug.


*Oct 30 13:39:35.783: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.10.10.10
*Oct 30 13:39:35.783: IGMP(0): Received Group record for group 239.10.10.10, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:35.787: IGMP(0): WAVL Insert group: 239.10.10.10 interface: FastEthernet0/0Successful
*Oct 30 13:39:35.787: IGMP(0): Switching to EXCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Oct 30 13:39:35.787: IGMP(0): Updating EXCLUDE group timer for 239.10.10.10
*Oct 30 13:39:35.791: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.10.10.10) by 0
*Oct 30 13:39:41.083: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.20.20.20
*Oct 30 13:39:41.087: IGMP(0): Received Group record for group 239.20.20.20, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:41.087: IGMP(0): WAVL Insert group: 239.20.20.20 interface: FastEthernet0/0Successful
*Oct 30 13:39:41.087: IGMP(0): Switching to EXCLUDE mode for 239.20.20.20 on FastEthernet0/0
*Oct 30 13:39:41.091: IGMP(0): Updating EXCLUDE group timer for 239.20.20.20
*Oct 30 13:39:41.091: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.20.20.20) by 0
*Oct 30 13:39:42.275: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.20.20.20
*Oct 30 13:39:42.275: IGMP(0): Received Group record for group 239.20.20.20, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:42.279: IGMP(0): Updating EXCLUDE group timer for 239.20.20.20
*Oct 30 13:39:42.279: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.20.20.20) by 0
*Oct 30 13:39:44.651: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.30.30.30
*Oct 30 13:39:44.651: IGMP(0): Received Group record for group 239.30.30.30, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:44.655: IGMP(0): WAVL Insert group: 239.30.30.30 interface: FastEthernet0/0Successful
*Oct 30 13:39:44.655: IGMP(0): Switching to EXCLUDE mode for 239.30.30.30 on FastEthernet0/0
*Oct 30 13:39:44.655: IGMP(0): Updating EXCLUDE group timer for 239.30.30.30
*Oct 30 13:39:44.655: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.30.30.30) by 0

We can see there the statements "MRT Add/Update FastEthernet0/0" which means it mapped the specific multicast address to the MRT (multicast routing table) for a specific interface. This will be also added to the IGMP membership. Lets check the MROUTE and IGMP memberships.


Router#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
     L - Local, P - Pruned, R - RP-bit set, F - Register flag,
     T - SPT-bit set, J - Join SPT, M - MSDP created entry,
     X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
     U - URD, I - Received Source Specific Host Report,
     Z - Multicast Tunnel, z - MDT-data group sender,
     Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 00:00:44/00:02:15, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
  FastEthernet0/0, Forward/Sparse-Dense, 00:00:44/00:00:00

(*, 239.10.10.10), 00:00:08/00:02:51, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
  FastEthernet0/0, Forward/Sparse-Dense, 00:00:08/00:00:00 ######### Added to MRT

(*, 224.0.1.40), 00:00:49/00:02:52, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
  FastEthernet0/0, Forward/Sparse-Dense, 00:00:49/00:00:00

Router#sh ip igmp member
Flags: A  - aggregate, T - tracked
  L  - Local, S - static, V - virtual, R - Reported through v3
  I - v3lite, U - Urd, M - SSM (S,G) channel
  1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
  / - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
   - last reporter if group is not explicitly tracked
/      -  reporter in include mode,  reporter in exclude

Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
*,239.255.255.250              192.168.18.1    00:03:32 02:59 1A     Fa0/0
*,239.20.20.20                 192.168.18.129  00:02:38 00:22 1A     Fa0/0
*,239.10.10.10                 192.168.18.129  00:02:43 00:16 1A     Fa0/0
*,239.30.30.30                 192.168.18.129  00:02:34 00:25 1A     Fa0/0
*,224.0.1.40                   192.168.18.10   00:03:34 02:50 1LA    Fa0/0

What are these other groups here? We are these for? Check the Wireshark screenshot above for the blue and green boxes. 239.255.255.250 is used by SSDP (Simple Service Discovery Protocol) used for Universal Plug and Play and from the output above its REPORTER is my Host OS which is Windows (192.168.18.1). 224.0.1.40 is a well known IANA assigned address for RP discovery while its counter part 224.0.1.39 is for RP announcement. This is reported by the router itself.


Multicast Routers use the IANA allocated Multicast address 224.0.0.1 for Membership Queries.
This multicast address is  reserved for all hosts in the LAN segment.

Leave Group

What happens when a host no longer wants to receive multicast traffic? How does the router know that there are no more interested hosts for that multicast group. For version 1, IGMP by default does Membership query every 60 seconds. It sends the multicast to 224.0.0.1 which means all host in the subnet. If by 3 tries which would be 180 secs or 3 mins and there are no Membership Report for a certain address, the router removes the entry from the IGMP membership table. Let's again generate traffic for 239.10.10.10 in MINT and lets see after 3 mins what the router does if there are no more Membership Reports.


pete@pete-desktop:~/mint-1.2$ mint -r 239.20.20.20 -p 4321

Router#debug ip igmp 239.10.10.10
IGMP debugging is on
Router#
*Oct 30 13:53:33.727: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.10.10.10
*Oct 30 13:53:33.731: IGMP(0): Received Group record for group 239.10.10.10, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:53:33.731: IGMP(0): WAVL Insert group: 239.10.10.10 interface: FastEthernet0/0Successful
*Oct 30 13:53:33.731: IGMP(0): Switching to EXCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Oct 30 13:53:33.735: IGMP(0): Updating EXCLUDE group timer for 239.10.10.10
*Oct 30 13:53:33.735: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.10.10.10) by 0
*Oct 30 13:54:09.335: IGMP(0): Send v1 general Query on FastEthernet0/0
*Oct 30 13:54:14.815: IGMP(0): Report has illegal group address 224.0.0.251
*Oct 30 13:55:09.335: IGMP(0): Send v1 general Query on FastEthernet0/0
*Oct 30 13:55:14.095: IGMP(0): Report has illegal group address 224.0.0.251
Router#sh ip igmp member
Flags: A  - aggregate, T - tracked
L  - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
 - last reporter if group is not explicitly tracked
/      -  reporter in include mode,  reporter in exclude

Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
*,239.255.255.250              192.168.18.1    00:17:14 02:13 1A     Fa0/0
*,239.10.10.10                 192.168.18.129  00:02:27 00:32 1A     Fa0/0
*,224.0.1.40                   192.168.18.10   00:17:16 02:08 1LA    Fa0/0
Router#
*Oct 30 13:56:09.335: IGMP(0): Send v1 general Query on FastEthernet0/0
*Oct 30 13:56:15.155: IGMP(0): Report has illegal group address 224.0.0.251
*Oct 30 13:56:34.335: IGMP(0): Switching to INCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Oct 30 13:56:34.335: IGMP(0): MRT delete FastEthernet0/0 for (*,239.10.10.10) by 0

The one highlighted in red is timestamped 13:53:33.735 when the router added 239.10.10.10 in the IGMP membership and when it did not receive a Membership report it removed the entry in its IGMP Membership timestamped 13:56:34.335, thats almost exactly 3 minutes! The command "show ip igmp membership" shows above that in 00:32 secs the multicast group will be removed from the IGMP Membership if it doesn't hear a Membership Report. If there was a real multicast source in this lab, R0 would have been wasting bandwidth for 3 minutes sending multicast traffic out of Fa0/0 with no receivers. IGMP version 1 doesn't have mechanism for hosts to inform the router that they are leaving the group. The host "quietly leaves" the multicast group. This lead to the development of IGMP V2.

Multicast Lab Preparation

2009-10-29T14:31:00.011+08:00

My idea of studying the CCIE topics includes sniffing the packets using Wireshark and study the contents of the packet. This I think, is a good way to understand how a protocol works and what components/ fields make up a packet of a certain protocol. I also will continue making use of VMware to host operating systems to be used for my studies of Multicast, QoS and other topics. Here I will show I set up my Guest OS and install the Multicast Traffic Generator I will be using.

Requirements:

VMware Server Installer
MINT software for Linux (Multicast Application)
GNS3
Ubuntu image
Wireshark

Steps:

1. Install VMware software. After installation, create a new virtual machine. For steps, on how to create a virtual machine in VMware click here. Use the Ubuntu ISO image downloaded as the ISO for the virtual CD drive in the virtual machine. This would automatically boot the live cd. It will display a menu and choose "Try Ubuntu without any change to your computer." Screenshot from Ubuntu site seen below.

2. Let the Live CD run and when it fully boots up and shows the desktop, click Install Icon as seen below.

3. Once Ubuntu is done installing on your VMware, run it and it should be ready to be used the first time. Make sure the virtual NIC is set to NAT or Bridge. If this is set to bridge, your internet router should lease an ip addresses to this virtual NIC and would be on the same subnet as your real NIC connected to your internet router.

4. Check if you can browse the internet using Firefox on your Ubuntu VM. Download the MINT from http://mc-mint.sourceforge.net/. Download the latest version 1.2.

5. Ubuntu might need an update to install or compile *.tar files so we would need to update and install those updates. Execute the commands below on the Applications -> Accessories ->Terminal, just make sure you have internet connectivity on your Ubuntu VM.

sudo apt-get update

sudo apt-get install build-essential

6. Now its time to install MINT. Copy the downloaded mint to your /home/username directory. Unzip the file using commands below.

gzip -d mint-1.2.tar.gz

tar -xvf mint-1.2.tar

7. Go to the new mint directory created and execute the command "make" to compile.

8. If you want to install it to /usr/local/bin execute "make install". Open the README file for more details on how to install and run MINT by going to the directory ./mint and execute "more README".

9. Integrate your Ubuntu VM to your GNS by dragging a cloud as seen below(Click on the image to enlarge). Click on the cloud and Choose the VMware NIC and click add. Connect your GNS3 routers ethernet interface to the cloud and then configure the interface with same subnet IP as your VMware interface. Mine defaulted to 192.168.18.0/24. Check your Ubuntu ip address by executing "ifconfig" on the terminal and then ping it from the router to test connectivity. This should be ready for the exercises I will do in my studies.

10. Download Wireshark, on your host Operating System, (I assume its Windows) then install it. It should be ready to sniff any traffic on the VMware virtual NIC's.

Now, I am ready to start my mini labs for Multicasting. :)

Multicast Studies Loading

2009-10-28T15:40:00.000+08:00

Its been a while since I posted something here. I have finished my BGP studies but will get back on that again after I have finished the other topics. Now I am into Multicasting and currently reading the book Developing IP Multicast Network s. The book might be a little old but the author is good at explaning what Multicast is and the other topics. I haven't even finished half of the book and yet the information it shares really helps. I have also setup VMware in my laptop and setup Ubuntu as a Guest Operating System on where I will run a multicast software to send and receive multicast traffic. Installed Wireshark for packet sniffing so I can see what's going on, on a multicast packet. I will post the instructions how I set up the lab I will be using and integrate it with Dynamips/GNS3. I am excited in this study because Multicast is one areas I have little to no experience with. I rarely encounter Multicast in the production networks in my present and previous jobs. This is one of weaknesses but the book I'm reading will greatly help me overcome this weakness.

BGP Attributes Categories

2009-10-19T13:59:00.004+08:00

A quick copy-and-paste summary on BGP attribute categorization.

WELL-KNOWN, MANDATORY

AS-path: A list of the Autonomous Systems (AS) numbers that a route passes through to reach the destination. As the update passes through an AS the AS number is inserted at the beginning of the list. The AS-path attribute has a reverse-order list of AS passed through to get to the destination.

Next-hop: The next-hop address that is used to reach the destination.

Origin: Indicates how BGP learned a particular route. There are three possible types -- IGP (route is internal to the AS), EGP (learned via EBGP), or Incomplete (origin unknown or learned in a different way).

WELL-KNOWN, DISCRETIONARY

Local Preference: Defines the preferred exit point from the local AS for a specific route.

Atomic Aggregate: Set if a router advertises an aggregate causes path attribute information to be lost.

OPTIONAL, TRANSITIVE

Aggregator: Specifies the router ID and AS of the router that originated an aggregate prefix. Used in conjunction with the atomic aggregate attribute.

Community: Used to group routes that share common properties so that policies can be applied at the group level.

OPTIONAL, NON-TRANSITIVE

Multi-exit-discriminator (MED): Indicates the preferred path into an AS to external neighbors when multiple paths exist.

A list of path attributes is contained in BGP update messages. The attribute is variable length and consists of three fields: Attribute type consisting of a 1-byte attribute flags field and a 1-byte attribute code field, Attribute length field that is 1 or 2 bytes, and a variable length attribute value field. The attribute type codes used by Cisco are: 1-origin, 2-AS-path, 3-Next-hop, 4-MED, 5-Local preference, 6-Atomic aggregate, 7-aggregator, 8-community, 9-originator-ID, and 10-cluster list.

BGP MED

2009-10-19T10:55:00.012+08:00

BGP MED is an optional non-transitive attribute meaning its not propagated throughout the whole internet but just to adjacent AS. The word "optional" means that this is not necessarily by default sent with the BGP updates. The purpose of MED is to influence how other autonomous systems enter your AS to reach a certain prefix. If the other attributes are set to default, MED will be the attribute used for path selection however, if Weight or Local preference is configured on the adjacent AS router, then MED will not be selected. The lower the MED the more preferred the path will be.


Acronym for Multi Exit Discriminator and otherwise known as "Metric" in the BGP table.
The lower the MED the more preferred.
It is an optional non-transitive attribute.
Can dictate how other AS enter your AS.

Configure R4 so that it will advertise a MED value of 30 to R3 and 20 to R2. Afterwards,
tweak the route map to set a MED of 10 for network 144.144.144.144/32 in R4 towards R3. The end
result should have traffic from AS123 to 4.4.4.4/32 and 44.44.44.44/32 take R2 but traffic for
144.144.144.144/32 should take R3. At the start BGP has been established on all routers.

To start lets configure 2 route maps and set the MED as required.


R4(config)#access-list 20 permit any
R4(config)#access-list 30 permit any
R4(config)#route-map R2SETMED20 permit 10
R4(config-route-map)#match ip address 20
R4(config-route-map)#set metric 20
R4(config-route-map)#route-map R3SETMED30 permit 10
R4(config-route-map)#match ip address 30         
R4(config-route-map)#set metric 30

Access-list matches all routes. Now, lets apply the route map to the neighbors.


R4(config-router)#neighbor 24.24.24.2 route-map R2SETMED20 out
R4(config-router)#neighbor 34.34.34.3 route-map R3SETMED30 out

Its in the "out" direction because R4 is the one advertising the routes. Let's check what R2 and R3 see in their BGP table.



R2#sh ip bgp
BGP table version is 31, local router ID is 24.24.24.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       24.24.24.4              20             0 4 i
*> 44.44.44.44/32   24.24.24.4              20             0 4 i
*> 144.144.144.144/32
                   24.24.24.4              20             0 4 i

R3#sh ip bgp
BGP table version is 10, local router ID is 34.34.34.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       34.34.34.4              30             0 4 i
*> 44.44.44.44/32   34.34.34.4              30             0 4 i
*> 144.144.144.144/32
                   34.34.34.4              30             0 4 i

Ok, its clear that the Metric now is changed to 20 and 30 for R2 and R3 respectively. Let's see how R1 sees the routes.



R1#sh ip bgp
BGP table version is 34, local router ID is 13.13.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
*>i4.4.4.4/32       24.24.24.4              20    100      0 4 i
* i                 34.34.34.4              30    100      0 4 i
*>i44.44.44.44/32   24.24.24.4              20    100      0 4 i
* i                 34.34.34.4              30    100      0 4 i
*>i144.144.144.144/32
                   24.24.24.4              20    100      0 4 i
* i                 34.34.34.4              30    100      0 4 i

R1 sees two paths, but notice that the paths with ">" are with those with lower MED. Therefore it is going to take those paths. Now, lets configure R4 so that the path R1 will take to 144.144.144.144/32 in R4 will be through R3 then clear the BGP session after.



R4(config)#access-list 33 permit 144.144.144.144 0.0.0.0
R4(config)#route-map R3SETMED30 permit 10
R4(config-route-map)#match ip address 33
R4(config-route-map)#set metric 10
R4(config-route-map)#route-map R3SETMED30 permit 20
R4(config-route-map)#match ip address 30
R4(config-route-map)#set metric 30
R4#clear ip bgp *

Now, lets see the outputs.



R2#sh ip bgp | beg Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       24.24.24.4              20             0 4 i
*> 44.44.44.44/32   24.24.24.4              20             0 4 i
*> 144.144.144.144/32
                   24.24.24.4              20             0 4 i

R3#sh ip bgp | beg Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       34.34.34.4              30             0 4 i
*> 44.44.44.44/32   34.34.34.4              30             0 4 i
*> 144.144.144.144/32
                    34.34.34.4              10             0 4 i

R1#sh ip bgp | beg Network
  Network          Next Hop            Metric LocPrf Weight Path
* i4.4.4.4/32       34.34.34.4              30    100      0 4 i
*>i                 24.24.24.4              20    100      0 4 i
* i44.44.44.44/32   34.34.34.4              30    100      0 4 i
*>i                 24.24.24.4              20    100      0 4 i
*>i144.144.144.144/32
                    34.34.34.4              10    100      0 4 i
* i                 24.24.24.4              20    100      0 4 i

We can see a change in R3 that shows a MED of 10 for 144.144.144.144/32, while R1 shows the same and will now take R3 to reach the subnet.

JNCIA-ER Finally

2009-10-16T13:59:00.003+08:00

After the whole year of inconsistent reading and studying, I passed the JNCIA-ER exam today with a good grade. I just focused on my studies last month and I found the exam easy because its similar to the principles in CCNA. I will finally get back to focus on the CCDA/CCDP track again while preparing for my CCIE Written exam early next year. JNCIS-ER exam will be taken on the last week of November.

I have updated my certification logos at the right hand side of the blog which now contains the JNCIA-ER logo. Hopefully I will see the CCDA and CCDP logo before this year ends. Next year, I hope to see the CCIE logo displayed there. These logos serve to remind me what I have accomplished and what should I be accomplishing. How nice would it be to see 5 CCIE logos there and even 1 JNCIE logo. Call me a certification monkey but I am more like a certification chimpanzee. :)

Juniper Configuration on the Mini Labs?

2009-10-15T10:34:00.005+08:00

I have been busy with my preparation for my Juniper JNCIA-ER exam tomorrow thats why I haven't been able to do any technical posts here. I often read an ebook and do Juniper emulator using "Olive" even at work. Doing Juniper configuration is pretty much like doing the CCNA but learning a different command language. Remember, any networking lessons and principles that applies to Cisco is pretty much the same with Juniper provided that its not vendor specific.

Something crossed my mind while I was doing the Juniper preparation. I have read many networking blogs but I haven't found anything that posts both Cisco and Juniper configs. My idea is to include one Juniper router on the Mini Labs and post Juniper basic configs here just for my reference and for those who read this blog. It's a good way to learn Juniper configs while mastering the Cisco IOS. I am not talking about very advanced Juniper configs. I rarely come across with a Juniper router here in the global network I support so including a Juniper router in the mini labs will really help with Juniper exposure.

What can you say about this? Would this be a good idea? After all, I am looking for some aspects that will make this blog different from the rest and this one I think will make it a unique one. Will this defeat the purpose of this blog? Let me know your thoughts.

For the time being, I have booked my Juniper JNCIS-ER exam on the last week of November so I have ample time to prepare (I have been reading from time to time about Juniper few months before.) My CCDA is underway too and my ARCH exam will be taken on December hopefully.

Focused Mini Labs or Mock Labs???

2009-10-03T11:13:00.003+08:00

I can't recall where I read it but I read some posts on which is better Focused Mini Labs or Mock Labs. I can't really say one is better than the other because in my opinion, these two should be equally useful for the CCIE lab exam preparation. I believe that a person preparing for the CCIE should focus first on the mini labs and understand the topics as clearly as possible and the mock lab a few months before the exam. What I am doing in this blog is doing the labs from the basic to the possibly more advanced topics. If you notice, I rarely jump from one topic to another but instead I focus more on one routing protocol/ subject at a time and divide it into smaller topics ( I wonder when I will finish blogging about BGP :) )

To tell you the truth, I don't have Mock Labs yet from those famous CCIE training vendors for two reasons, first I don't have money to purchase one for the moment (too bad for me ;) ) secondly I don't want to get tempted to get into the Mock Labs without first completing the mini labs I am doing. Gives me the study focus I need but its just me. There are people who the mock labs first and do mini labs later, its okay we have our own unique ways of doing things ;).

Currently, I am doing Kocharian labs but the labs I post here in my blog aren't copied from there or any source. I create my own topology for my own personal understanding and explanation. I can truly say I have understood something if I can explain it clearly and that is one purpose of this blog.

Juniper Fast Track 100% Discount on Exams

2009-09-25T15:08:00.003+08:00

Yesterday, I was visiting the Juniper Fast Track page to find out what happened to the voucher I got when I passed the pre-assessment exam. I found out that Juniper is making the exam free and you can use the previous voucher you had to avail the free exam.

This may be inappropriate to post in this blog which is all about Cisco, but I think this will be a good certification to get. Besides, JNCIA-ER and JNCIS-ER are the certifications I targetted to achieve this year. These certifications will not only make your list of cerfications longer :), but also boost your morale for aimed certifications like the CCIE. This will give a networking individual a higher market value than those who only has Cisco certs. I am not pro Juniper or something. I consider Scott Morris my example for multi vendor certified experts and I think he has a wider market than those CCIE's who only have Cisco certifications. It's like having a coat of many colors! My opinion though, but my proof is there are a lot of companies out there looking for Juniper Certified individuals. You can check the job sites if you want to see for yourself.

As for me, I have booked my free JNCIA-ER exam by October and will be booking my JNCIS-ER by December. I am looking forward to passing these exams but I still don't neglect my aim for the CCDA/CCDP this year and ultimately the CCIE next year. Don't miss this chance to get a good and acknowledged certification for free! This will only be available throughout the rest of 2009. You have nothing to lose! :) Check the link below for more details.

https://learningportal.juniper.net/juniper/user_fasttrack_home.aspx

Anyone Reading?

2009-09-24T13:48:00.003+08:00

I have been pretty busy this month. Not only I was sidetracked from my studies but also I tend to relax this month because, I just turned a year older. My counter shows people have been reading this blog but I am not sure if these are just one time visitor or there are people actually reading and learning something from this. Like I said first and foremost, I created this blog for my own personal reference and for others also who likes to learn from blogs.

If there are people out there who are following my entries, please comment and let me know how much more I can improve this blog for the benefit of us all. I know this blog can't even compare to other blogs but your comments can really help improve. If you have topics you want to be covered let me know cause, my way is I am covering mini focused labs per topic and per protocol.

BGP Local Preference

2009-09-23T14:37:00.007+08:00

Local Preference is one of the ways to alter the path taken by one AS to reach another AS. The difference between Local Preference and Weight is that Weight is just locally signifant in the router while Local Preference is what I call "Local AS significant". What I mean by that is that Local Preference is being propagated Intra AS but not outside the AS.


Local preference is to influence your own AS how to get or exit to another AS.
MED is to influence other AS how to enter your AS.
The higher the local preference, the more preferred.

In this lab, local preference will be configured and will be using route map for more flexibility. Check the diagram below for details.

R1, R2 and R3 belongs to AS 123. R4 is in AS4 and is advertising 4.4.4.4/32, 44.44.44.44/32 and 144.144.144.144/32
subnets.We need to set all routes learned from R3 to have local preference value of 300. After which, configure a
route-map that will assign a local preference of 500 in R2 for the network 144.144.144.144/32.

Here are the initial BGP configurations on the routers.


R1#
!
router bgp 123
no synchronization
bgp log-neighbor-changes
neighbor 12.12.12.2 remote-as 123
neighbor 13.13.13.3 remote-as 123
no auto-summary

R2#
!
router bgp 123
no synchronization
bgp log-neighbor-changes
neighbor 12.12.12.1 remote-as 123
neighbor 12.12.12.1 next-hop-self
neighbor 24.24.24.4 remote-as 4
no auto-summary

R3#
!
router bgp 123
no synchronization
bgp log-neighbor-changes
neighbor 13.13.13.1 remote-as 123
neighbor 13.13.13.1 next-hop-self
neighbor 34.34.34.4 remote-as 4
no auto-summary

R4#
!
router bgp 4
no synchronization
bgp log-neighbor-changes
network 4.4.4.4 mask 255.255.255.255
network 44.44.44.44 mask 255.255.255.255
network 144.144.144.144 mask 255.255.255.255
neighbor 24.24.24.2 remote-as 123
neighbor 34.34.34.3 remote-as 123
no auto-summary

Let's see what is the best path taken by R1 to reach the networks advertised by R4.


R1#sh ip bgp

BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
*>i4.4.4.4/32       12.12.12.2               0    100      0 4 i
* i                 13.13.13.3               0    100      0 4 i
*>i44.44.44.44/32   12.12.12.2               0    100      0 4 i
* i                 13.13.13.3               0    100      0 4 i
*>i144.144.144.144/32
                   12.12.12.2               0    100      0 4 i
* i                 13.13.13.3               0    100      0 4 i

R1#sh ip route | beg Gateway


Gateway of last resort is not set

    1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
    4.0.0.0/32 is subnetted, 1 subnets
B       4.4.4.4 [200/0] via 12.12.12.2, 00:04:00
    144.144.0.0/32 is subnetted, 1 subnets
B       144.144.144.144 [200/0] via 12.12.12.2, 00:04:00
    12.0.0.0/24 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, Serial1/2
    13.0.0.0/24 is subnetted, 1 subnets
C       13.13.13.0 is directly connected, Serial1/3
    44.0.0.0/32 is subnetted, 1 subnets
B       44.44.44.44 [200/0] via 12.12.12.2, 00:04:00

It's clear that it prefers to take R2 to reach the networks in R4. Let's configure R3 so that all routes received by R3 will have a Local preference of 300


R3#config t
R3(config)#router bgp 123
R3(config-router)#bgp default local-preference 300

R1#sh ip bgp
BGP table version is 13, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
* i4.4.4.4/32       12.12.12.2               0    100      0 4 i
*>i                 13.13.13.3               0    300      0 4 i
* i44.44.44.44/32   12.12.12.2               0    100      0 4 i
*>i                 13.13.13.3               0    300      0 4 i
* i144.144.144.144/32
                   12.12.12.2               0    100      0 4 i
*>i                 13.13.13.3               0    300      0 4 i

Immediately, even without clearing the BGP process, R3 now became the more preferred path to reach R4. Remember that in Local Preference, the higher the value, the more preferred.

Let's configure in R2 a route-map so the network 144.144.144.144/32 will have a local preference of 500. This will make R2 the best path to reach the mentioned network.


R2(config)#access-list 1 permit host 144.144.144.144
R2(config)#route-map LOCALPREF500 permit 10
R2(config-route-map)#match ip address 1
R2(config-route-map)#set local-preference 500
R2#(config)# router bgp 123
R2(config-router)#neighbor 24.24.24.4 route-map LOCALPREF500 in
R2# clear ip bgp *

R1#sh ip bgp
BGP table version is 14, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
*>i4.4.4.4/32       13.13.13.3               0    300      0 4 i
*>i44.44.44.44/32   13.13.13.3               0    300      0 4 i
*>i144.144.144.144/32
                   12.12.12.2               0    500      0 4 i
* i                 13.13.13.3               0    300      0 4 i

Firstly, why is that the route-map has an "in" direction. It's because we are receiving the route from another router, R2 is not the one advertising. You can see now that path to 144.144.144.144/32 will have R2 as the next hop. If you noticed also, why is that for 4.4.4.4/32 and 44.44.44.44/32, there is no other path except through 13.13.13.3. Check the route-map above and you'll find the answer. There is no succedding line after line 10, which means, it will block out the subnets and not advertised it to R1.

Let's configure the 20th sequence of the route-map.


R2(config)#route-map LOCALPREF500 permit 20

Let's see now if there are changes.


R1#sh ip bgp
BGP table version is 16, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
* i4.4.4.4/32       12.12.12.2               0    100      0 4 i
*>i                 13.13.13.3               0    300      0 4 i
* i44.44.44.44/32   12.12.12.2               0    100      0 4 i
*>i                 13.13.13.3               0    300      0 4 i
*>i144.144.144.144/32
                   12.12.12.2               0    500      0 4 i
* i                 13.13.13.3               0    300      0 4 i

That's it for local preference. Hopefully I can finish the BGP topics soon. :)

HSRP Route Tracking

2009-09-04T16:51:00.010+08:00

I have been accustomed to tracking the WAN interface to determine the HSRP priority. However, there are more ways to use tracking in HSRP and one of those is to track a certain prefix in the routing table. This works by checking a specific route configured in "track" if it is still in the routing table. If not, it will decrease the priority according the configured decrement.

R1 and R2 are in one site. R1 is the Active HSRP route while R2 is the standby. R1 and R2 should
not be OSPF neighbors. Traffic should go to R2 once a route to 3.3.3.3/32 is lost in R1.

This is not the best way to track this scenario but just for example sake. Excuse the IP addressing scheme as well because I find it easier to know which ip is from which router just by number in the last octet. (e.g. .1 is in R1, .2 is in R2 and .3 is in R3)

The pre-configuration of the routers is found below.


R1#
interface FastEthernet0/0
ip address 10.10.20.1 255.255.255.0
duplex half
standby 1 ip 10.10.20.10
standby 1 preempt
!
interface Serial1/0
ip address 10.10.13.1 255.255.255.0
serial restart-delay 0
no fair-queue
!
interface Serial1/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/3
no ip address
shutdown
serial restart-delay 0
!
router ospf 1
log-adjacency-changes
passive-interface FastEthernet0/0
network 10.10.13.0 0.0.0.255 area 0
network 10.10.20.0 0.0.0.255 area 0

R2#
interface FastEthernet0/0
ip address 10.10.20.2 255.255.255.0
duplex half
standby 1 ip 10.10.20.10
standby 1 priority 91
standby 1 preempt
!
interface Serial1/0
ip address 10.10.23.2 255.255.255.0
serial restart-delay 0
!
interface Serial1/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/3
no ip address
shutdown
serial restart-delay 0
!
router ospf 1
log-adjacency-changes
passive-interface FastEthernet0/0
network 10.10.20.0 0.0.0.255 area 0
network 10.10.23.0 0.0.0.255 area 0

R3#
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface Serial1/0
ip address 10.10.13.3 255.255.255.0
serial restart-delay 0
!
interface Serial1/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/2
ip address 10.10.23.3 255.255.255.0
serial restart-delay 0
!
interface Serial1/3
no ip address
shutdown
serial restart-delay 0
!
router ospf 1
log-adjacency-changes
network 3.3.3.3 0.0.0.0 area 0
network 10.10.13.0 0.0.0.255 area 0
network 10.10.23.0 0.0.0.255 area 0

Let's configure tracking and apply it on the HSRP group of 1.

R1(config)#track 1 ip route 3.3.3.3 255.255.255.255 reachability
R1(config-track)#int fa0/0
R1(config-if)#standby 1 track 1 decrement 11

Ok, lets see how a "show track" output looks like.

R1#sh track 1
Track 1
IP route 3.3.3.3 255.255.255.255 reachability
Reachability is Up (OSPF)
1 change, last change 00:01:22
First-hop interface is Serial1/0
Tracked by:
HSRP FastEthernet0/0 1

Notice that tracking knows what routing protocol the route is learned from. It also shows how long its up, which interface and what HSRP group is using. Pretty neat huh? :) Let's remove the announcement of 3.3.3.3/32 in R3 to simulate lost of entry in the routing table.


R3(config-router)#no network 3.3.3.3 0.0.0.0 area 0

Let's see how R1 reacts to that.


R1#
*Sep  4 16:57:37.679: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/0 from FULL to DOWN, Neighbor Down: Dead timer expired
*Sep  4 16:57:53.679: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
*Sep  4 16:58:03.675: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby
*Sep  4 16:58:08.747: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/0 from LOADING to FULL, Loading Done
*Sep  4 16:58:23.691: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
*Sep  4 16:58:38.831: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
*Sep  4 16:58:48.831: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby

R1#sh standby br
            P indicates configured to preempt.
            |
Interface   Grp Prio P State    Active          Standby         Virtual IP
Fa0/0       1   89   P Standby  10.10.20.2      local           10.10.20.10

R1#sh track 1
Track 1
IP route 3.3.3.3 255.255.255.255 reachability
Reachability is Down (no route)
4 changes, last change 00:00:56
First-hop interface is unknown
Tracked by:
HSRP FastEthernet0/0 1

Ok, as we can see, once OSPF detected that the network isn't anymore reachable, HSRP reacted as well by decrementing the priority by 11 as per configured. The priority is now 89, 11 less than the default HSRP priority of 100. "show track" also indicated that there is no more route going to 3.3.3.3. I would just like to point out here that if the command "standby 1 preempt" was not configured in R2, it would not assume the Active state and R1 will still remain the Active HSRP router. Preempt feature will make HSRP renegotiate.

Let's advertise again the route and see the changes.


R3(config)#router ospf 1
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0

R1#sh standby br
                  P indicates configured to preempt.
                  |
Interface   Grp Prio P State    Active          Standby         Virtual IP 
Fa0/0       1   100  P Active   local           10.10.20.2      10.10.20.10

As expected R1 will reassume the HSRP Active state because the route is now found in the routing table. :)

IP SLA with HSRP

2009-09-02T10:25:00.011+08:00

My friend recently had an implementation involving an EoSDH connection from one site to another involving 2 routers. LAN side of Site 1 requires HSRP to be running and it needs to track the EoSDH connection so the Active HSRP will shift to R2 incase of primary link failure. The problem is most EoSDH connection like his implementation has no way of detecting Layer 1 and Layer 2 failures upstream because there are switches installed in the customer premise and even within the ISP EoSDH connection. Houston we have a problem! :)

As a solution he can have a transit connection between R1 and R2 and run OSPF but configure the routes received from R2 to have a higher admin distance than the OSPF which has 110. He could also use IP SLA feature to detect failures and track it in the HSRP group so that any breaches on the configured IP SLA will make HSRP decrement priority. The diagram is shown below similar to most setups.


Cisco IOS IP SLAs is a feature included in the Cisco IOS Software that can allow administrators the ability to
Analyze IP Service Levels for IP applications and services.IP SLA's uses active traffic-monitoring technology to
monitor continuous traffic on the network. This is a reliable method in measuring over head network performance.
Cisco Routers provide IP SLA Responders that give accuracy of measured data across a network.
-Wikipedia-

In our diagram, the requirement is to run HSRP on the LAN and connect the primary router R1
and backup router, R2 to Site 2 which has R3. Connections to R1 -R3 and R2 - R3 should be in
different subnets. Imagine the network after SW1 towards R3 will be on the ISP side and could
have several switches towards R3. R1 is the Active HSRP router and R2 is the Standby.

The challenge here is how to track the EoSDH link which is like a FastEthernet/ GigabitEthernet network run across the
WAN. Tracking the interface of R1 or R2 connected to the switch won't do any good in HSRP because, even if there is
an upstream failure, that connection will still remain up. HSRP only decrements priority once it detects the router's interface
down. The solution to this problem is to configure IP SLA.

Before we proceed the routers' initial configs are shown below.


R1#
interface FastEthernet0/0
ip address 10.10.20.1 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address 192.168.100.10 255.255.255.0
duplex full
speed auto
standby 12 ip 192.168.100.1
standby 12 preempt
!
router ospf 1
log-adjacency-changes
passive-interface FastEthernet1/0
network 10.10.20.0 0.0.0.255 area 0
network 192.168.100.0 0.0.0.255 area 0

R2#
!
interface FastEthernet0/0
ip address 10.10.30.2 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address 192.168.100.20 255.255.255.0
duplex full
speed auto
standby 12 ip 192.168.100.1
standby 12 priority 91
!      
router ospf 1
log-adjacency-changes
passive-interface FastEthernet1/0
network 10.10.30.0 0.0.0.255 area 0
network 192.168.100.0 0.0.0.255 area 0

R3#
!
interface Loopback0
ip address 192.168.33.33 255.255.255.255
!
interface FastEthernet0/0
ip address 10.10.20.3 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address 10.10.30.3 255.255.255.0
duplex full
speed auto
!
router ospf 1
log-adjacency-changes
network 10.10.20.0 0.0.0.255 area 0
network 10.10.30.0 0.0.0.255 area 0
network 192.168.33.33 0.0.0.0 area 0
distance 254 10.10.30.2 0.0.0.0

Now, lets configure and SLA that constantly pings the Loopback address of R3 from R1. We will set the frequency of 10 , timeout and threshold of 2000.


R1(config)#ip sla monitor 1
R1(config-sla-monitor)#type echo protocol ipIcmpEcho 192.168.33.33
R1(config-sla-monitor-echo)#timeout 2000
R1(config-sla-monitor-echo)#threshold 2000
R1(config-sla-monitor-echo)#frequency 10

The frequency means it will do a ping in every 10 seconds to check if the configured netework is still reachable. The timeout and threshold values will determine if there is a "breach" in the configured SLA. Now let's start the SLA now and let it continue "forever" as long as the router is alive. You can also set other parameters like what time of the day this will start and what time it will end.


R1(config)#ip sla monitor schedule 1 start-time now life forever

Let's do a "debug ip icmp" and see if it is really doing its job now.


R1#debug ip icmp
ICMP packet debugging is on
R1#
*Sep  2 10:57:31.507: ICMP: echo reply rcvd, src 192.168.33.33, dst 10.10.20.1
*Sep  2 10:57:41.523: ICMP: echo reply rcvd, src 192.168.33.33, dst 10.10.20.1
*Sep  2 10:57:51.523: ICMP: echo reply rcvd, src 192.168.33.33, dst 10.10.20.1
*Sep  2 10:58:01.547: ICMP: echo reply rcvd, src 192.168.33.33, dst 10.10.20.1

Ok, its clear its receiving replies every 10 seconds. We are not done yet, we have to configure this to be tracked by HSRP.


R1(config)#track 1 rtr 1 reachability
R1(config-track)#int fa1/0
R1(config-if)#standby 12 track 1 decrement 11

The command "track 1 rtr 1" means that the IP SLA 1 is marked as tracked number 1. It doesn't matter what track number you use. Now, the HSRP config means that if the SLA is "breached" decrement by 11. First let's see the statistics of the configured IP SLA.

R1#sh ip sla monitor statistics 1
Round trip time (RTT)   Index 1
Latest RTT: 28 ms
Latest operation start time: *11:04:01.523 UTC Wed Sep 2 2009
Latest operation return code: OK
Number of successes: 42
Number of failures: 0
Operation time to live: Forever

I will shut down the connection from R1 to R3. The threshold and timeout are set to 2000 but if there isn't a reply its also a breach. Let's check what happens to the HSRP.


R1#sh standby br
         P indicates configured to preempt.
         |
Interface   Grp Prio P State    Active          Standby         Virtual IP
Fa1/0       12  89   P Standby  192.168.100.20  local           192.168.100.1

When the router is able to ping again the loopback of R3. The HSRP state will become active again.

BGP Weight Attribute

2009-08-20T13:30:00.016+08:00

The BGP Weight attribute is a Cisco Proprietary attribute that influences a router how to reach a certain prefix. The difference between Local Preference and Weight is that the former is propagated within an AS and the latter is router locally significant. Weight can be used if there is one router connected to two or more AS's or just to just one with two or more eBGP peers. Now, lets configure weight and later use a route-map for more complex use of weight.


Weight is a Cisco Proprietary attribute for BGP that is "locally significant."
Local Preference is a Well-known Discretionary attribute, Weight doesn't belong to any category.
Default Weight for locally originated routes is 32768.Zero is the default for other routes.
Weight is not propagated to other routers within the AS.

All routers have BGP established and within its own AS.R4 is announcing 4 prefixes and the condition is
for R1 to reach routes 4.4.4.4/32, 44.44.4.44/32 and 144.144.144.144/32, it must take AS2. Then later
configure a route-map to so that R1 with take AS 3 to reach 144.144.144.144/32.

Lets see how R1 reaches the prefixes announced by R4.


R1#sh ip bgp
BGP table version is 12, local router ID is 13.13.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  4.4.4.4/32       12.12.12.2                             0 2 4 i
*>                  13.13.13.3                             0 3 4 i
*  44.44.44.44/32   12.12.12.2                             0 2 4 i
*>                  13.13.13.3                             0 3 4 i
*  144.144.144.144/32
                    12.12.12.2                             0 2 4 i
*>                  13.13.13.3                             0 3 4 i

Ok, it takes AS3 to reach the prefixes. Now, lets configure Weight to make AS2 the more preferred path to reach the prefixes.


R1(config)#router bgp 1
R1(config-router)#neighbor 12.12.12.2 weight 100
R1(config-router)#do clear ip bgp * soft

Now let's see if that changes after clearing the BGP session "softly".


R1#sh ip bgp
BGP table version is 15, local router ID is 13.13.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
  r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       12.12.12.2                           100 2 4 i
*                   13.13.13.3                             0 3 4 i
*> 44.44.44.44/32   12.12.12.2                           100 2 4 i
*                   13.13.13.3                             0 3 4 i
*> 144.144.144.144/32
        12.12.12.2                           100 2 4 i
*                   13.13.13.3                             0 3 4 i

It's now taking AS 2. Let's configure a route-map so R1 will take AS3 to reach 144.144.144.144/32. The weight should be 200. We will apply the route-map towards neighbor 13.13.13.3.


R1(config)#access-list 1 permit host 144.144.144.144
R1(config)#route-map TAKE_AS3 permit 10
R1(config-route-map)#match address 1
R1(config-route-map)#set weight 200
R1(config-router)#neighbor 13.13.13.3 route-map TAKE_AS3 in
R1(config-router)# do clear ip bgp * soft

The ACL is to filter which routes be given a weight of 200. The reason the route-map was configured inbound direction because we are receiving the routes from that neighbor. Let's see what happens to the BGP table.


R1#sh ip bgp
BGP table version is 16, local router ID is 13.13.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       12.12.12.2                           100 2 4 i
*> 44.44.44.44/32   12.12.12.2                           100 2 4 i
*  144.144.144.144/32
                    12.12.12.2                           100 2 4 i
*>                  13.13.13.3                           200 3 4 i

Now, R1 will take AS3 to reach 144.144.144.144/32. Notice that the weight now is 200, and its more prefered.

Comparing Config Differences

2009-08-14T16:45:00.005+08:00

When I started as a network engineer, whenever I configured something and forgot what it was, I usually do "show start" and "show run" to compare the difference manually before I do a "write mem". Believe me, it was an eyesore comparing the start-up and running-config line by line. There is a easy way though to compare the configs and the command is "show archive config differences" for the router to compare the start-up and the running-config. Check the output below.


Router#show archive config differences
Contextual Config Diffs:
+no aaa new-model
interface FastEthernet0/0
+description to LAN
+ip ospf cost 100
+duplex half
+mpls ip
-aaa new-model
-aaa session-id common
interface FastEthernet0/0
-description to Building 2
-ip ospf cost 800
-duplex full

The commands prepended with a "+" means that this commands are in the "start-up config". The ones with "-" are in the running config. Of course when you do a "write mem" after this and you issue the command, you won't be seing any differences :). Good day!

EBGP Multihop

2009-08-13T13:08:00.016+08:00

Configuring iBGP doesn't require the neighbor address to be directly connected. The best practice for iBGP is to use the loopback address as the ip address configured on the BGP neighbor statement. Loopback interfaces never go down so provided that there is an alternate route to the loopback ip address through an IGP, BGP session will not be torn down.

Using loopback addresses for eBGP is also a good practice if there are multiple links between two routers on different autonomous system as shown on the example diagram below. This will also achieve load balancing.

The initial configuration for this lab is shown below.


R1#
!
interface Serial1/0
ip address 10.10.10.1 255.255.255.0
serial restart-delay 0
end
!
interface Serial1/1
ip address 10.10.20.1 255.255.255.0
serial restart-delay 0
end
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
no auto-summary
!
ip route 2.2.2.2 255.255.255.255 10.10.10.2
ip route 2.2.2.2 255.255.255.255 10.10.20.2

R2#
!
interface Serial1/0
ip address 10.10.10.2 255.255.255.0
serial restart-delay 0
end
!
interface Serial1/1
ip address 10.10.20.2 255.255.255.0
serial restart-delay 0
end
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
no auto-summary
!
ip route 1.1.1.1 255.255.255.255 10.10.10.1
ip route 1.1.1.1 255.255.255.255 10.10.20.1

Notice that in both routers we put 2 static routes to achieve load balancing. Currently the BGP session is not established eventhough both loopbacks are reachable. Now, lets configure "ebgp-multihop" on both routers and see if this will make the BGP session establish.


The purpose of "ebgp-multihop" is to connect to eBGP neighbors that are not directly connected.
As we know, BGP expects eBGP peers to be directly connected but this command will make
neighborship possible even though they are not directly connected.

Now let's configure the routers.


R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2

R2(config)#router bgp 2
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2

R1#sh ip bgp sum
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4     2       0       0        0    0    0 never    Active

The BGP session is not established even though we configured the "ebgp-multihop" command. Before we find out why, lets first discuss the "ebgp-multihop" command. The default value of this command if we don't put anything will be 255. We put a value of 2 because it will take 2 hops to reach 2.2.2.2 from 1.1.1.1 as they are not directly connected. Provided all the requirements are met except the hop count value, if the hop count value is lesser than what it should be, the eBGP neighborship will not be established.

Going back to why its not established, its because by default for BGP to establish the TCP session it will use the outgoing interface ip address as the source. The other router will reject the incoming TCP SYN packets because it doesn't recognize the source IP address as a configured neighbor. In our case, it will source the TCP session using the two physical interfaces ip addresses.


The BGP session updates should be sourced from the IP address that the the neighbor
configured for eBGP Multihop to work. The command "neighbor ip_address update-source
Loopback0" in our example is needed.

Now lets configure, the update-source command sourcing all BGP negiotiations and updates from Loopback0 which are the ip addresses configured on our neighbor statements.


R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 update-source Loopback0

R2(config)#router bgp 2
R2(config-router)#neighbor 1.1.1.1 update-source Loopback0

R1#sh ip bgp su
*Aug 13 14:41:43.175: %SYS-5-CONFIG_I: Configured from console by consolem
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4     2      11      11        1    0    0 00:00:47        0

R2#sh ip bgp sum
*Aug 13 14:41:38.099: %SYS-5-CONFIG_I: Configured from console by console
BGP router identifier 2.2.2.2, local AS number 2
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4     1      11      11        1    0    0 00:00:42        0

BGP session now established. We can see in CEF that this is load balanced.


R1#sh ip cef 2.2.2.2
2.2.2.2/32, version 27, epoch 0, per-destination sharing
0 packets, 0 bytes
via 10.10.20.2, 0 dependencies, recursive
traffic share 1
next hop 10.10.20.2, Serial1/1 via 10.10.20.0/24
valid adjacency
via 10.10.10.2, 0 dependencies, recursive
traffic share 1
next hop 10.10.10.2, Serial1/0 via 10.10.10.0/24
valid adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes

Now, BGP session is established. Let's try shutting down one link and see if the session is still established.


R2(config)#int se1/0
R2(config-if)#shut
R2(config-if)#^Z
R2#sh ihp b
*Aug 13 14:42:38.871: %SYS-5-CONFIG_I: Configured from console by console
*Aug 13 14:42:39.095: %LINK-5-CHANGED: Interface Serial1/0, changed state to administrativ
*Aug 13 14:42:39.095: %ENTITY_ALARM-6-INFO: ASSERT INFO Se1/0 Physical Port Administrative State Down
*Aug 13 14:42:40.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down
R2#sh ip bgp sum
BGP router identifier 2.2.2.2, local AS number 2
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4     1      12      12        1    0    0 00:01:45        0

BGP session still established. Thats all about EBGP Multihop feature.:)

Show Command Multiple Filtering

2009-08-12T20:58:00.006+08:00

Normally when we do show command we make use of the "|" to filter and put in keywords after like include, exclude, begin and section. As we all know "include" means show only that matches the string like for the example below.


R1#sh run | inc CISCO
 neighbor CISCO peer-group

We can do some multiple command filtering like the example below using the "include" keyword. Let's say we want to see the interface name, then the description, the OSPF cost and if its configured with the "mpls ip" command.


R1#sh run | inc interface |^ description |^ ip ospf cost |^ mpls ip
interface FastEthernet0/0
description towards LAN
ip ospf cost 100
mpls ip

The trick is to use multiple "|" and then the regular expression "^". Then put a space before the string because the configurations under the interface configuration if you do a "show run" has a space before the line. This also applies to the "exclude" keyword but who the heck uses "exclude" that much? There goes another stupid blog entry post. :)

My Next Target: CCDA

2009-08-11T12:28:00.004+08:00

Currently I am working as a Change Management Engineer and my job involves planning and preparing configuration for new site setups, partner vpn and just about anything in the WAN/LAN side of the network. There are times that it is required for me to do some proposals on how the network should be designed and I really need to do some research on how this should be done the proper way. As a network engineer, I believe we are not only only into configuring routers and do it for a lifetime.:) I think its best if we also know how the network should be designed and it pays a lot if you work for pre-sales job which requires designing knowledge and experience.

I first started reading Dianne Teare's book on CCDA a few months ago. I find it boring at first but when I went into the succeeding chapters, I find it more interesting. The book is so nice, you have to read it twice or thrice!:)

My journey towards the CCIE, doesn't mean I am not open for other certifications. I believe certifications like the CCDA and CCDP can greatly help not only for the exam but also for your value as an individual in the networking industry. Certifications like ITIL which I currently have, are also good in terms of the business and process side of the networking job.Being multi vendor certified is also good because there are also good networking products out there. Juniper and Checkpoints are my next targets after I have achieved my CCDP certification. I only need two more exams and I hope to accomplish the certifications I mentioned this year. I will learn as much as I can but will not forget on my target and my focus.

BGP Confederation

2009-08-06T14:30:00.013+08:00

This is feature is used to split an autonomous system into smaller autonomous systems or the reverse which is to combine several autonomous systems into one. Reasons of splitting might be IGP's like OSPF might not be able to handle the routes of a really big enterprise so splitting the AS into smaller will help OSPF scale better, or perhaps the enterprise wants to have separate administrative control per region and wants to control the routing policies on their specific regions. This could also be used if there are company mergers and they want to appear as one AS to other EBGP peers. One thing that intrigues me though is that one of the materials I was using mentioned that this could also be a work around for the BGP Split Horizon Rule. I really doubt that Confederations can be a work around for that. I'll find out for sure in this lab.

The diagram below shows 5 Routers with each its own AS number. The goal here to group these routers into one confederation and make them appear as AS1234 to R5 in AS5.

Below are the configurations I have placed on the routers.


R1#sh run | section router bgp
router bgp 1
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
no auto-summary

R2#sh run | section router bgp
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary

R3#sh run | section router bgp
router bgp 3
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary

R4#sh run | section router bgp
router bgp 4
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 5.5.5.5 remote-as 5
neighbor 5.5.5.5 ebgp-multihop 2
neighbor 5.5.5.5 update-source Loopback0
no auto-summary

R5#sh run | section router bgp
router bgp 5
no synchronization
bgp log-neighbor-changes
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary

I have configured static routes for reachability. Notice as well that I am using EBGP-multihop feature for EBGP neighbors. I have configured Loopback10 11.11.11.11/32 in R1 and lets see how R2,R3,R4 and R5 see this prefix.


R2# sh ip bgp | beg Network
Network          Next Hop            Metric LocPrf Weight Path
*> 11.11.11.11/32   1.1.1.1                  0             0 1 i

R3#sh ip bgp | beg Network
Network          Next Hop            Metric LocPrf Weight Path
*  11.11.11.11/32   4.4.4.4                                0 4 2 1 i
*>                  1.1.1.1                  0             0 1 i

R4#sh ip bgp | beg Network
Network          Next Hop            Metric LocPrf Weight Path
*  11.11.11.11/32   3.3.3.3                                0 3 1 i
*>                  2.2.2.2                                0 2 1 i

R5#sh ip bgp | beg Network
Network          Next Hop            Metric LocPrf Weight Path
*> 11.11.11.11/32   4.4.4.4                                0 4 2 1 i

All of them is seeing this prefix sourcing from an EBGP. Now let's configure R1, R2, R3 and R4 as one confederation and let's see how the BGP table looks like after that. To configure BGP confederations, what are needed is the confederation ID and the peer ASes belonging to that confederation.


R1(config)#router bgp 1
R1(config-router)#bgp confederation identifier 1234
R1(config-router)#bgp confederation peers 2 3 4

R2(config)#router bgp 2
R2(config-router)#bgp confederation identifier 1234
R2(config-router)#bgp confederation peers 1 3 4

R3(config)#router bgp 3
R3(config-router)#bgp confederation identifier 1234
R3(config-router)#bgp confederation peers 1 2 4

R4(config)#router bgp 4
R4(config-router)#bgp confederation identifier 1234
R4(config-router)#bgp confederation peers 1 2 3
R4(config-router)#bgp confederation peers 4
4 Local member-AS not allowed in confed peer list
4 Local member-AS not allowed in confed peer list

As you noticed, you are not allowed to configure your own AS on the "bgp confederation peer command". Ok now let's check how R2,R3,R4 and R5 sees this prefix.



R2#sh ip bgp | beg Network
Network          Next Hop            Metric LocPrf Weight Path
*> 11.11.11.11/32   1.1.1.1                  0    100      0 (1) i

R3#sh ip bgp | beg Network
Network          Next Hop            Metric LocPrf Weight Path
*> 11.11.11.11/32   1.1.1.1                  0    100      0 (1) i

R4#sh ip bgp | beg Network
Network          Next Hop            Metric LocPrf Weight Path
*  11.11.11.11/32   1.1.1.1                  0    100      0 (3 1) i
*                   1.1.1.1                  0    100      0 (2 1) i

R5#sh ip bgp

It's clear that its now behaving like they are in one AS. In R4, you can see that it enclosed the AS path in parenthesis, which means AS is using BGP confederation. I have not configured any route reflector here but R4 is still learning the prefix as advertised by R2 and R3. Therefore in some way it circumvents the BGP Split Horizon rule. In a confederation, it may appear like its one AS but it functions how the peering is configured whether its IBGP or EBGP. Going back, R5 is not seeing anything. You know why? It's because R4 doesn't know how to get to 1.1.1.1 inorder to reach 11.11.11.11/32. It won't advertise anything to R5 until it knows how to get to the destination. Let's configure a static route.


R4(config)#ip route 1.1.1.1 255.255.255.255 24.24.24.2
R4(config)#ip route 1.1.1.1 255.255.255.255 34.34.34.3

Then let's see if R4 now sees the best path to 11.11.11.11 in its BGP table.


R4#sh ip bgp | beg Network
Network          Next Hop            Metric LocPrf Weight Path
*> 11.11.11.11/32   1.1.1.1                  0    100      0 (2 1) i

EBGP peering between R4 and R5 is still there but R5 is still using 4 as the remote-as of R4. It may learn the prefix even though the remote-as number for 4.4.4.4 hasn't been changed, however if the link goes down or the BGP session is cleared, BGP will generate now an error that neighbor in wrong AS. Let's change that config to 1234 and check if R5 now sees 11.11.11.11/32.


R5(config)#router bgp 5
R5(config-router)#neighbor 4.4.4.4 remote 1234
R5(config-router)#neighbor 4.4.4.4 update-source Lo0
*Aug  6 16:09:00.259: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Down Remote AS changed.4.4.4
*Aug  6 16:09:02.567: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up  update lo0
R5(config-router)#neighbor 4.4.4.4 ebgp 2

R5#sh ip bgp | beg Network
Network          Next Hop            Metric LocPrf Weight Path
*> 11.11.11.11/32   4.4.4.4                                0 1234 i

The AS path to get to 11.11.11.11/32 is now only 1234 and R5 is now seeing the groups of AS as one AS. Well that's all about it regarding Confederations.

Fun with TCL: Generating 100 Loopbacks in 1 Minute

2009-08-05T14:51:00.007+08:00

When I did the BGP Maximum-Prefix post, I used Excel to generate 100 ip addresses, just by typing 1.1.1.1 then dragging all the way down to 100. On the cell to the left, I put "network" then to the right "mask 255.255.255.255". I pasted, it under BGP and I noticed there are some errors because of the line breaking. I hate to paste over and over again. I'd rather be effective than persistent.:)

So after an hour of research and experimentation, I found a way to generate 100 ip route commands without any problem. I tried it on loopback interfaces configuration and it worked fine! Check the script below.


foreach number {
1
2
3
4
5
6
} { puts [ ios_config "interface Loopback$number" ] }

It's almost the same as the common TCL ping script I use but the keyword "ios_config" made the difference. This keyword makes you execute any global configuration command in TCL. For example's sake I used only 6 numbers. I will post later the 100 loopbacks I created.

Now what the heck is a loopback without any ip address. Useless isn't it? I also found a way to map an ip address to a loopback in TCL. You use multiple variables.


foreach {number address} {
           1       3.3.4.1
           2       3.3.4.2
           3       3.3.4.3
           4       3.3.4.4
           5       3.3.4.5
           6       3.3.4.6

 } {   puts [ ios_config "interface Loopback$number" "ip address $address 255.255.255.255" ] }

Now, if you notice after the "interface Loopack$number" there is a subcommand for interface configuration mode. You can add as many commands as you want like descriptions. Just enclose it with parenthesis.

Just be creative with your script. I also used it to announce 500 prefixes in BGP just for fun. As promised here is my "show ip interface brief" showing the loopbacks.


Router#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES unset  administratively down down
Loopback1                  3.3.4.1         YES unset  up                    up
Loopback2                  3.3.4.2         YES unset  up                    up
Loopback3                  3.3.4.3         YES unset  up                    up
Loopback4                  3.3.4.4         YES unset  up                    up
Loopback5                  3.3.4.5         YES unset  up                    up
Loopback6                  3.3.4.6         YES unset  up                    up
Loopback7                  3.3.4.7         YES unset  up                    up
Loopback8                  3.3.4.8         YES unset  up                    up
Loopback9                  3.3.4.9         YES unset  up                    up
Loopback10                 3.3.4.10        YES unset  up                    up
Loopback11                 3.3.4.11        YES unset  up                    up
Loopback12                 3.3.4.12        YES unset  up                    up
Loopback13                 3.3.4.13        YES unset  up                    up
Loopback14                 3.3.4.14        YES unset  up                    up
Loopback15                 3.3.4.15        YES unset  up                    up
Loopback16                 3.3.4.16        YES unset  up                    up
Loopback17                 3.3.4.17        YES unset  up                    up
Loopback18                 3.3.4.18        YES unset  up                    up
Loopback19                 3.3.4.19        YES unset  up                    up
Loopback20                 3.3.4.20        YES unset  up                    up
Loopback21                 3.3.4.21        YES unset  up                    up
Loopback22                 3.3.4.22        YES unset  up                    up
Loopback23                 3.3.4.23        YES unset  up                    up
Loopback24                 3.3.4.24        YES unset  up                    up
Loopback25                 3.3.4.25        YES unset  up                    up
Loopback26                 3.3.4.26        YES unset  up                    up
Loopback27                 3.3.4.27        YES unset  up                    up
Loopback28                 3.3.4.28        YES unset  up                    up
Loopback29                 3.3.4.29        YES unset  up                    up
Loopback30                 3.3.4.30        YES unset  up                    up
Loopback31                 3.3.4.31        YES unset  up                    up
Loopback32                 3.3.4.32        YES unset  up                    up
Loopback33                 3.3.4.33        YES unset  up                    up
Loopback34                 3.3.4.34        YES unset  up                    up
Loopback35                 3.3.4.35        YES unset  up                    up
Loopback36                 3.3.4.36        YES unset  up                    up
Loopback37                 3.3.4.37        YES unset  up                    up
Loopback38                 3.3.4.38        YES unset  up                    up
Loopback39                 3.3.4.39        YES unset  up                    up
Loopback40                 3.3.4.40        YES unset  up                    up
Loopback41                 3.3.4.41        YES unset  up                    up
Loopback42                 3.3.4.42        YES unset  up                    up
Loopback43                 3.3.4.43        YES unset  up                    up
Loopback44                 3.3.4.44        YES unset  up                    up
Loopback45                 3.3.4.45        YES unset  up                    up
Loopback46                 3.3.4.46        YES unset  up                    up
Loopback47                 3.3.4.47        YES unset  up                    up
Loopback48                 3.3.4.48        YES unset  up                    up
Loopback49                 3.3.4.49        YES unset  up                    up
Loopback50                 3.3.4.50        YES unset  up                    up
Loopback51                 3.3.4.51        YES unset  up                    up
Loopback52                 3.3.4.52        YES unset  up                    up
Loopback53                 3.3.4.53        YES unset  up                    up
Loopback54                 3.3.4.54        YES unset  up                    up
Loopback55                 3.3.4.55        YES unset  up                    up
Loopback56                 3.3.4.56        YES unset  up                    up
Loopback57                 3.3.4.57        YES unset  up                    up
Loopback58                 3.3.4.58        YES unset  up                    up
Loopback59                 3.3.4.59        YES unset  up                    up
Loopback60                 3.3.4.60        YES unset  up                    up
Loopback61                 3.3.4.61        YES unset  up                    up
Loopback62                 3.3.4.62        YES unset  up                    up
Loopback63                 3.3.4.63        YES unset  up                    up
Loopback64                 3.3.4.64        YES unset  up                    up
Loopback65                 3.3.4.65        YES unset  up                    up
Loopback66                 3.3.4.66        YES unset  up                    up
Loopback67                 3.3.4.67        YES unset  up                    up
Loopback68                 3.3.4.68        YES unset  up                    up
Loopback69                 3.3.4.69        YES unset  up                    up
Loopback70                 3.3.4.70        YES unset  up                    up
Loopback71                 3.3.4.71        YES unset  up                    up
Loopback72                 3.3.4.72        YES unset  up                    up
Loopback73                 3.3.4.73        YES unset  up                    up
Loopback74                 3.3.4.74        YES unset  up                    up
Loopback75                 3.3.4.75        YES unset  up                    up
Loopback76                 3.3.4.76        YES unset  up                    up
Loopback77                 3.3.4.77        YES unset  up                    up
Loopback78                 3.3.4.78        YES unset  up                    up
Loopback79                 3.3.4.79        YES unset  up                    up
Loopback80                 3.3.4.80        YES unset  up                    up
Loopback81                 3.3.4.81        YES unset  up                    up
Loopback82                 3.3.4.82        YES unset  up                    up
Loopback83                 3.3.4.83        YES unset  up                    up
Loopback84                 3.3.4.84        YES unset  up                    up
Loopback85                 3.3.4.85        YES unset  up                    up
Loopback86                 3.3.4.86        YES unset  up                    up
Loopback87                 3.3.4.87        YES unset  up                    up
Loopback88                 3.3.4.88        YES unset  up                    up
Loopback89                 3.3.4.89        YES unset  up                    up
Loopback90                 3.3.4.90        YES unset  up                    up
Loopback91                 3.3.4.91        YES unset  up                    up
Loopback92                 3.3.4.92        YES unset  up                    up
Loopback93                 3.3.4.93        YES unset  up                    up
Loopback94                 3.3.4.94        YES unset  up                    up
Loopback95                 3.3.4.95        YES unset  up                    up
Loopback96                 3.3.4.96        YES unset  up                    up
Loopback97                 3.3.4.97        YES unset  up                    up
Loopback98                 3.3.4.98        YES unset  up                    up
Loopback99                 3.3.4.99        YES unset  up                    up
Loopback100                3.3.4.100       YES unset  up                    up

I wonder how many loopbacks I can create in a Cisco router. Maybe I'll try that some other time. Good day mates! :)

BGP Maximum-Prefix

2009-08-05T12:35:00.016+08:00

BGP handles over 100,000 routes in the internet and it is doing a very good job in doing so. I tried doing the "show ip bgp" command on our internet router with a Public AS and takes quite a long time to show all the prefixes. I have to hit the space bar a lot of times. You can imagine how much CPU this number of routes will take on the router.

I have read an article that a few months ago, there was one ISP that advertised the whole internet routing table and originated all the routes. A mistake will most likely affect the routers in the internet, or could take the internet down if there are no counter measures done. One more possible thing I can imagine that might happen is that private ip addresses from a customer might be advertised out to the internet if the ISP failed to filter the private address. ( I dunno if this happened before)

Limiting the number of prefixes received from a BGP neighbor is one of the best ways to make sure these mistakes never affect the whole internet. The best practice is to check the number of prefixes received from a neighbor and then give a little allowance on the number of prefixes allowed. R1 on the diagram below is announcing prefixes to R2, let's see what happens if these prefixes reach the limit and what happens if it exceeds the limit.

Let's see how many prefixes R2 learns from R1.


R2#sh ip bgp summary
BGP router identifier 10.10.10.2, local AS number 234
BGP table version is 101, main routing table version 101
100 network entries using 11700 bytes of memory
100 path entries using 5200 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 17172 total bytes of memory
BGP activity 100/0 prefixes, 100/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4   123      13      12      101    0    0 00:06:03      100

It's learning 100 prefixes from R1. Now lets configure BGP so that R2 will only allow 101 routes from R1. The command we will use is "neighbor neighboraddress maximum-prefix number ".


R2(config)#router bgp 234
R2(config-router)#neighbor 10.10.10.1 remote-as 123
R2(config-router)#neighbor 10.10.10.1 maximum-prefix 101

Let's advertise one route to BGP in R1. I will configure as well a static route pointing to Null0, to make sure the new route will be advertised. I didn't configure any loopback addresses on R1.


R1(config)#router bgp 123
R1(config-router)#network 1.1.1.101 mask 255.255.255.255
R1(config-router)#ip route 1.1.1.101 255.255.255.255 Null0

Let's see how R2 reacted to this configuration.


R2#
*Aug  5 13:08:58.959: %BGP-4-MAXPFX: No. of prefix received from 10.10.10.1 (afi 0) reaches 101, max 101

Oh, it reacted by generating a log message that the number of prefixes learned from R1 has reached its maximum. Lets add one more route in R1 and see what happens.


R1(config)#router bgp 123
R1(config-router)#network 1.1.1.102 mask 255.255.255.255
R1(config-router)#ip route 1.1.1.102 255.255.255.255 Null0

Let's check R1 and R2 syslog messages.


R1#
*Aug  5 13:11:16.415: %BGP-3-NOTIFICATION: received from neighbor 10.10.10.2 3/1 (update malformed) 0 bytes
*Aug  5 13:11:16.415: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Down BGP Notification received

R2#
*Aug  5 13:11:20.199: %BGP-3-MAXPFXEXCEED: No. of prefix received from 10.10.10.1 (afi 0): 102 exceed limit 101
*Aug  5 13:11:20.199: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Down BGP Notification sent
*Aug  5 13:11:20.199: %BGP-3-NOTIFICATION: sent to neighbor 10.10.10.1 3/1 (update malformed) 0 bytes  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0035 0200 0000 1940 0101 0040 0204 0201 007B 4003 040A 0A0A 0180 0404 0000 0000 2001 0101 66

This time it gave also a notification in R2 and also generated a hexadecimal code. ( I have yet to review what this means :)) Right then and there, when it exceeded the limit R2 dropped the peering to R1. Let's see what the BGP table summary looks like after the violation.


R2#sh ip bgp sum
BGP router identifier 10.10.10.2, local AS number 234
BGP table version is 203, main routing table version 203

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4   123      21      19        0    0    0 00:04:26 Idle (PfxCt)

The state is in Idle and included a description (PfxCt) which means the neighbor exceeded the prefix limit set. The peering will only be established once the prefixes goes below the threshold set and "clear ip bgp *" needs to be issued to renegotiate the connection. Again, this command is very useful to protect your own AS from over flooding of prefixes and protect other ASes as well.

VRF Route Target

2009-08-04T15:03:00.004+08:00

MPLS VPN implementation requires VRF and also exporting and importing routes for that VRF. I mentioned on my previous posts about VRF that the VRF name is locally significant and even the RD number. What counts is what you import and export. Importing and exporting route targets use the same syntax as the RD and it is ASN:NN as shown by the example below.

!
ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3

By definition the routes that you "export" are only the routes you advertise on the vrf address family in BGP. The routes that you import are the cummulative routes with the same label that were exported from the other routers participating in the MPLS VPN. Remember that you don't export what you have learned through importation. Check the diagram below and the scenario we need to accomplish in this lab.

Scenario Conditions:

1. EMEA should have full ip reachability to APAC and AMERICAS but APAC and AMERICAS should not see each other.
2. RR should only see the all the routes but will not be seen by the routers.

I have setup everything and configured MPLS as well. I have configured the clients on the RR on both ipv4 and vpnv4 address-families. The command "show ip bgp vpnv4 all sum" on the RR should show that its learning prefixes from the clients.

RR#sh ip bgp vpnv4 all sum
BGP router identifier 123.123.123.4, local AS number 123
BGP table version is 13, main routing table version 13
12 network entries using 1644 bytes of memory
12 path entries using 816 bytes of memory
4/3 BGP path/bestpath attribute entries using 496 bytes of memory
3 BGP extended community entries using 72 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 3028 total bytes of memory
BGP activity 12/0 prefixes, 12/0 paths, scan interval 15 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
123.123.123.1   4   123      52      57       13    0    0 00:40:41        2
123.123.123.2   4   123      53      61       13    0    0 00:41:26        2
123.123.123.3   4   123      43      44       13    0    0 00:36:44        2

We can clearly see that its learning prefixes in the vpnv4 but will not put those routes in the routing table until it has been imported in one of the VRF's. In our case, I have configured vrf ALL-VRF in RR and imported all the route-targets 123:1, 123:2 and 123:4. In a VRF you can export and import as many route-targets as needed. Lets see if RR can see the routes now

RR

!
ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3

RR#sh ip route vrf ALL-VRF

Routing Table: ALL-VRF
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

 1.0.0.0/32 is subnetted, 1 subnets
B       1.1.1.1 [200/0] via 123.123.123.1, 00:46:26
 2.0.0.0/32 is subnetted, 1 subnets
B       2.2.2.2 [200/0] via 123.123.123.2, 00:46:26
 33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 00:46:26
 3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 00:46:26
 22.0.0.0/32 is subnetted, 1 subnets
B       22.22.22.22 [200/0] via 123.123.123.2, 00:46:26
 11.0.0.0/32 is subnetted, 1 subnets
B       11.11.11.11 [200/0] via 123.123.123.1, 00:46:28
 123.0.0.0/32 is subnetted, 1 subnets
C       123.123.123.14 is directly connected, Loopback40

Ok, we have meet the first condition. RR is now able to see the routes exported by the RR clients. They won't see the route advertised in RR because the clients are not even importing that route. Full reachability in MPLS VPN requires that one router's exported route-target should be imported by another and vice-versa, otherwise you can only see the route but you won't be able to reach it. The networks should be in the corresponding VRF routing table of the routers.

To illustrate this point, let's configure the second scenario. Below are the VRF configurations on the 3 clients.

APAC#

!
ip vrf APAC
rd 123:1
route-target export 123:1
route-target import 123:3

AMERICAS#

!
ip vrf AMERICAS
rd 123:2
route-target export 123:2
route-target import 123:2

EMEA#
!
ip vrf EMEA
rd 123:3
route-target export 123:3
route-target export 123:2
route-target import 123:1
route-target import 123:2

APAC is exporting route-target 123:1 and its importing 123:3 which is exported by EMEA. EMEA on the other hand is importing 123:1 and exporting 123:3. There should be full ip reachability between the two. By the way the route-target ID doesn't necessarily match with the RD. Normally for networks that should see each other in MPLS VPN both the export and import route target ID's are the same. It will get rid of any unnecessary confusion created by using different RT ID's. Take into consideration AMERICAS and EMEA routers. As you can see on the config above, AMERICAS is importing and exporting 123:2. One command can generate the both export and import and that is "route-target both 123:2". EMEA is importing and exporting also 123:2 which means they will reach each other. Let's test if we have accomplished the condition, we will show the routing table in APAC and AMERICAS and let's ping the networks in EMEA. The ping should be sourced on the loopback interfaces where we configured the VRF's.

APAC#sh ip route vrf APAC

Routing Table: APAC
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

 1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
 33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 01:04:51
 3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 01:04:51
 11.0.0.0/32 is subnetted, 1 subnets
C       11.11.11.11 is directly connected, Loopback10

APAC#ping vrf APAC 3.3.3.3 source lo0


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 248/346/436 ms


AMERICAS#sh ip route vrf AMERICAS

Routing Table: AMERICAS
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

 2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
 33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 00:56:20
 3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 00:56:20
 22.0.0.0/32 is subnetted, 1 subnets
C       22.22.22.22 is directly connected, Loopback10

AMERICAS#ping vrf AMERICAS 3.3.3.3 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 184/593/1020 ms


EMEA#sh ip route vrf EMEA

Routing Table: EMEA
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

 1.0.0.0/32 is subnetted, 1 subnets
B       1.1.1.1 [200/0] via 123.123.123.1, 00:00:00
 2.0.0.0/32 is subnetted, 1 subnets
B       2.2.2.2 [200/0] via 123.123.123.2, 01:07:06
 33.0.0.0/32 is subnetted, 1 subnets
C       33.33.33.33 is directly connected, Loopback10
 3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback0
 22.0.0.0/32 is subnetted, 1 subnets
B       22.22.22.22 [200/0] via 123.123.123.2, 01:07:06
 11.0.0.0/32 is subnetted, 1 subnets
B       11.11.11.11 [200/0] via 123.123.123.1, 00:00:03

It will take a while to get used to VRF Route-target if you are just learning it but this should be pretty easy. Remember, you can't reach a network that you have imported unless it exported your network. In MPLS VRF, entries in your VRF routing table doesn't assure reachability, the router in the destination network should also have your network in its VRF routing table. Ok, we are done! :)

Improving the Pages

2009-08-02T16:49:00.006+08:00

I spent this whole Sunday on improving the pages. For a long time, I have been looking to put the routers' show output command in a textbox so the alignment will be correct but sadly textarea sucks in blogger. I happen to run accross an CSS code somewhere and I applied it to my page. To my surprise, it worked fine and I am now able to put the show commands and configurations on these boxes without any problem or any weird text coming out. Now, I am looking for visio stencils/ symbols I can use for my drawings cause I find my drawings really sucky! :) If someone happens to have a pretty neat collection of visio symbols, kindly let me know where to get it. Some modern and funky styles will do! Ok, now I'll resume putting the show commands in textboxes on my previous posts. Good day!

Question of the Day: July 31, 2009

2009-07-31T19:42:00.001+08:00

Q: What is the range of the Private AS numbers allocated by IANA?

Highlight after < for the answer.

A: <IANA has reserved AS64512 through to AS65535 to be used as private ASNs

For more information on this visit this page:

http://www.apnic.net/services/services-apnic-provides/helpdesk/faqs/asn-faqs

BGP Remove-Private-AS

2009-07-30T14:11:00.014+08:00

Most companies have acquired their own AS number and also some have implemented Private AS numbers connected to their Public AS network. They might have created a private AS number per region. There are others also who run BGP and are using private AS connected to their ISP using PA (Provider Allocated) Public IP addresses. No matter, how its implemented, announcing the private AS number you are using to the internet is a big NO, NO. ISP's should filter these private AS and not advertise them out to the internet.

Consider the diagram below. Let's say R1 is in Company A and is connected to its ISP using a private AS number 65535. The task we need to complete here is to filter any private AS to be announced to R2 so that R2 will only see the AS number of the ISP.

Firstly, I have done configuring the IP addresses indicated in the diagram. Created Loopback0 and Loopback10 in R1 and ISP and advertised them in BGP. Of course, all routers have BGP established. I have also announced networks 123.123.123.123/32 and 12.12.12.12/32 in the ISP router.

Now, lets check what R2 sees in the BGP table.


R2#sh ip bgp
BGP table version is 5, local router ID is 192.168.20.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       192.168.20.20                          0 100 65535 i
*> 11.11.11.11/32   192.168.20.20                          0 100 65535 i
*> 12.12.12.12/32   192.168.20.20            0             0 100 i
*> 123.123.123.123/32
                    192.168.20.20            0             0 100 i

We see that the AS path to get to 1.1.1.1/32 and 11.11.11.11/32 is through AS 100 then AS65535. Lets do a filtering in ISP router not to advertise this private AS but instead make the ISP's AS the originating AS.


ISP(config)#router bgp 100
ISP(config-router)#neighbor 192.168.20.1 remove-private-as

The "remove-private-as" appended to the neighbor statement ensures that any private AS connected to the ISP will not appear in the AS path. Lets clear the BGP process by doing "clear ip bgp * soft" on ISP router and see what R2 BGP table.


R2#sh ip bgp
BGP table version is 7, local router ID is 192.168.20.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       192.168.20.20                          0 100 i
*> 11.11.11.11/32   192.168.20.20                          0 100 i
*> 12.12.12.12/32   192.168.20.20            0             0 100 i
*> 123.123.123.123/32
                    192.168.20.20            0             0 100 i

The networks from R1 now is seen originated from AS 100. The private AS number was removed by the command we issued. Note that this command works in the outbound direction and should be placed on the networks with public AS number but have private AS connected to them. I tried this command on R2 before I added in ISP but I didn't work because like what I mentioned, this works in the outbound direction. Lab is done, proceeding to the next one or perhaps I might reading some cool mangas like my favorite One Piece! :)

Question of the Day: July 29, 2009

2009-07-29T20:57:00.001+08:00

Q: In BGP dampening, what is the default value of the "reuse-value"?

Highlight after < for the answer.

A: <750

For more information on this visit this page:

http://www.avici.com/documentation/HTMLDocs/02223-06_revBA/BGP_Nd7.html

Question of the Day: July 28, 2009

2009-07-28T10:39:00.005+08:00

Q: In BGP dampening, how much is the per-flap penalty points?

Highlight after < for the answer.

A: <1000

For more information on this visit this page:

http://www.avici.com/documentation/HTMLDocs/02223-06_revBA/BGP_Nd7.html

Question of the Day: July 27, 2009

2009-07-27T18:14:00.002+08:00

Q: By default, BGP can perform load balancing over how many parallel links?

Highlight after < for the answer.

A: < One. You can change the number of parallel links by the "maximum-paths" command.

For more information on this visit this page:

http://www.avici.com/documentation/HTMLDocs/02223-10_revAB/BGP_Nd22.html

Question of the Day: July 26, 2009

2009-07-26T19:45:00.005+08:00

Q: What is required for the command "default-information originate" to work?

Highlight after < for the answer.

A: <For the router to advertise itself as a default route to the other routers, it must have its own default route configured statically or learned dynamically. Adding the keyword "always" will force the router to advertise itself as a default route even if there is no default route learned by the advertising router.

For more information on this visit this page:

http://www.avici.com/documentation/HTMLDocs/02223-10_revAB/ospf8.html

VRF and VRF-lite

2009-07-26T13:39:00.003+08:00

I remembered that several months ago, I had an implementation regarding VRF-lite. In my previous posts VRF Basics and MPLS VPN VRF Select I haven't actually mentioned about VRF-lite. What exactly is this and how does this differ with VRF used in MPLS VPN?

First, ask the question, what is required to run VRF in the MPLS VPN implementation? Of course VRF, MP-BGP and MPLS should be running on the Provider's routers. It would need BGP VPNv4 neighborship to make MPLS VPN run.

VRF-lite is normally VRF without MPLS. This is Cisco's way, of what is so called virtualization. This can be useful of course if the enterprise has networks of overlapping IP addresses or some segments they don't want to be reached by other segments. Its kinda like VLAN in the sense that its in WAN. In this sense, VRF-lite configuration doesn't need the route-target part. For every VRF is a separate routing table. Routing VRF-lite can be done by static or dynamic under its vrf instance. I think I'll create a lab for this to show how it can be configured using IGP's. By the way, these days, I wonder why I am posting more on MPLS than any other topic? Does it mean I want to pursue CCIE SP than gettting the R&S? Good day! :)

Question of the Day: July 25, 2009

2009-07-25T20:18:00.002+08:00

Q: What are the 5 STP switch port states?

Highlight after < for the answer.

A: <Blocking, Listening, Learning, Forwarding and Disabled

For more information on this visit this page:

http://en.wikipedia.org/wiki/Spanning_tree_protocol

Why CCIE?

2009-07-24T11:23:00.003+08:00

So many have been asked the question why CCIE? Why not other certifications in networking? I have been asking myself the same question "why CCIE"? The second question is "is it worth getting a CCIE"?

Before I answer that trivial question, let me begin how I got into the Cisco world. I was hired as a contractor for AT&T and I had little knowledge about Cisco. Prior to that, I had Cisco experience by configuring Cisco DSL modems and the old Cisco routers like the 1700. During my training in AT&T, I met a CCIE for the first time and he showed us how good a CCIE is. That training sparked my interest in Cisco and from then on I started my path. A few months from that, I got my CCNA which I think was well worth because of that certification I landed a job in a good company who paid my CCNP fees.

Reminiscing about how my CCNP got me to where I am now, I have an idea how much more a CCIE cert will do to my career. If my CCNP got me a good job, how much more a CCIE. To answer the first question, "why CCIE?" The answer is because, I love the technology but more than that the driving force behind this motivation to get the cert is to give my family a better future. Being a CCIE, means you are an expert on what you doing. It means better job and a better life and it is a trademark of hardwork and perseverance. CCIE's also has a nice ring to it when someone calls you "hey Mr. CCIE".:)

Secondly, "is it worth it"? I think there is no need to ask this question. The answers from the first question should show that it is really worth it. I have known people who got CCIE and got better jobs and better exposure. My job currently is supporting and doing Change Management but imagine how exciting would it be if one was the expert and consultant of enterprises. It's a whole new level than my current job.

Thirdly, you might ask this question. Why Cisco Dreamer? Well, my goal is not only to be a CCIE but to work with Cisco as well. Simple and obvious isn't it? Good day!

Question of the Day: July 24, 2009

2009-07-24T11:13:00.000+08:00

Q: What is default spanning-tree priority in Cisco switches?

Highlight after < for the answer.

A: <32768

For more information on this visit this page:

http://en.wikipedia.org/wiki/Spanning_tree_protocol

Question of the Day: July 23, 2009

2009-07-23T21:11:00.003+08:00

Q: Name the metrics used in EIGRP.

Highlight after < for the answer.

A: <Delay, Bandwidth, Reliability and Load. MTU is not being used in metric calculation but is considered a metric.

For more information on this visit this page:

http://www.rhyshaden.com/eigrp.htm

Question of the Day: July 22, 2009

2009-07-23T21:01:00.003+08:00

Q: What is the name of a device in IS-IS that is similar to a DR in OSPF that flood hello packets in a broadcast media?

Highlight after < for the answer.

A: <Designated Intermediate System (DIS)

For more information on this visit this page:

http://en.wikipedia.org/wiki/IS-IS

Question of the Day: July 21, 2009

2009-07-23T20:54:00.002+08:00

Q: In EIGRP, what is a feasible successor?

Highlight after < for the answer.

A: <A Feasible Successor is a backup route to a destination which is kept in the Topology Table.

For more information on this visit this page:

http://www.rhyshaden.com/eigrp.htm

MPLS VPN VRF Source Selection

2009-07-23T15:09:00.017+08:00

It's been a while since I did some labs. Recently I received a comment from someone in the VRF Basics entry regarding importing the loopbacks from the CE routers to a VRF for management purposes. I'm in the middle of my BGP review but I'm curious anyway. I created a lab and tried a way and it seems I found a way how to. The feature is called VRF source selection, in which you can have multiple VRF's in an interface and VRF mapping is based on the source ip address. As we all know, CE routers usually don't have VRF's configured on them and usually for MPLS VPN setup one customer is assigned to one VRF. For MPLS Basics check my previous entry.

The diagram below shows 2 PE's and 3 CE's. I have preconfigured the PE's with BGP peering on both ipv4 and vpnv4 address-families and the necessary IP configuration with the CE's having a default route toward the directly connected PE. VPNv4 address-family on BGP by the way, is used for MPLS VPN. Configured MPLS on the link between PE1 and PE2.

Scenario:

We have 2 Customers, Customer1 and Customer2. The branch offices needs to connect to the other branches in PE2(I have created Loopback addresses for these). They need to have their own VRF's configured. Customer1 and Customer2 should have loopback0 ip addresses configured on the CE's for the NOC to use as management ip to access from their hopping server which is in ISP NOC router. VRF named "Management" should be used on the CE's. Customer's LAN networks are represented as Loopback10. The RD's of the Customers should be Customer1 - 1234:1, Customer2 - 1234:2 and Management - 1234:100. Click the image below for a bigger view.

The scenario requires 2 VRF's from every Customer CE. The Command "ip vrf forwarding" only uses one VRF per interface. We only have 1 interface and this command is not a feasible solution. We need to use VRF source selection in order to use multiple VRF's in an interface.

Provided that we already created the VRF's, first we would need to map a source IP address to a VRF. The PE will know which VRF a packet will be through the source IP.


PE1(config)#vrf selection source 1.1.1.1 255.255.255.255 vrf Management 
PE1(config)#vrf selection source 2.2.2.2 255.255.255.255 vrf Management 
PE1(config)#vrf selection source 11.11.11.11 255.255.255.255 vrf Customer1 
PE1(config)#vrf selection source 22.22.22.22 255.255.255.255 vrf Customer2  

PE2(config)#vrf selection source 3.3.3.3 255.255.255.255 vrf Management

After that, we would need to configure the interfaces in the PE's to use source selection. As mentioned, a while ago, "ip vrf forwarding" command is used if there is only one VRF used so in this scenario there is no need for the command.


PE1(config)#interface Serial1/1 
PE1(config-if)#ip vrf select source 
PE1(config-if)#ip vrf receive Customer1 
PE1(config-if)#ip vrf receive Management

PE1(config)#interface Serial1/2 
PE1(config-if)#ip vrf select source 
PE1(config-if)#ip vrf receive Customer2 
PE1(config-if)#ip vrf receive Management

PE2(config)#interface Se1/3
PE2(config)#ip vrf select source
PE2(config)#ip vrf receive Management

The commands mean that on the corresponding interfaces the VRF are activated based on the "vrf selection source" commands. It's the equivalent of "ip Vrf forwarding" command but in the sense that its for multiple vrfs.

Well now the question is, how will the VRF's know which subnets will come from what interface. Simple, through routing.:) In our case since we are not configuring dynamic routing, we will configure static vrf routes.

PE1(config)#ip route vrf Customer1 11.11.11.11 255.255.255.255 192.168.10.1 
PE1(config)#ip route vrf Customer2 22.22.22.22 255.255.255.255 192.168.20.2 
PE1(config)#ip route vrf Management 1.1.1.1 255.255.255.255 192.168.10.1 
PE1(config)#ip route vrf Management 2.2.2.2 255.255.255.255 192.168.20.2  

PE2(config)#ip route vrf Management 3.3.3.3 255.255.255.255 192.168.30.3

It's obvious that the "vrf " keyword there points to what VRF this route belongs to.:) MPLS VPN requires that the routes be learned by Multiprotocol BGP. Since these are static routes we need to redistribute them into BGP on the ipv4 VRF address-family. Output pasted below from the running config.


PE1
! 
address-family ipv4
neighbor 10.10.10.2 activate 
no auto-summary 
no synchronization
exit-address-family 
! 
address-family vpnv4
neighbor 10.10.10.2 activate 
neighbor 10.10.10.2 send-community extended 
exit-address-family 
!
address-family ipv4 vrf Management 
redistribute static metric 1 
no auto-summary  no synchronization 
exit-address-family 
!
address-family ipv4 vrf Customer2
redistribute static metric 1
 no auto-summary 
no synchronization 
exit-address-family 
!
 address-family ipv4 vrf Customer1 
redistribute static metric 1  no auto-summary  no synchronization  exit-address-family

PE2
!
 address-family ipv4 vrf Management
redistribute static metric 1
no auto-summary
no synchronization
exit-address-family

If you notice, we didn't redistribute it on the "ipv4" global address-family but instead we did it on their corresponding VRF address-families. We learned that VRF's are like separate routing tables in a single router, and that exactly is the reason why we advertise this in different address-families.

We are not done yet, remember we have 2 loopback's in PE2 representing the other sites of Customer1 and Customer2. Lets configure those.


PE2
!
interface Loopback1
 ip vrf forwarding Customer1
 ip address 111.111.111.111 255.255.255.255
!
interface Loopback2
 ip vrf forwarding Customer2
 ip address 222.222.222.222 255.255.255.255

Now let's advertise this in BGP.
!
 address-family ipv4 vrf Customer2
 no auto-summary
 no synchronization
 network 222.222.222.222 mask 255.255.255.255
 exit-address-family
 !
 address-family ipv4 vrf Customer1
 no auto-summary
 no synchronization
 network 111.111.111.111 mask 255.255.255.255
 exit-address-family

Ok, now lets check BGP peering on the VPNv4 address family. The "show ip bgp vpnv4 all summary" command will display the summary of the prefixes learned through all the VRF's.


PE1#sh ip bgp vpnv4 all sum | beg Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.2      4  1234      93     106       15    0    0 01:14:47        3

PE2#sh ip bgp vpnv4 all sum | beg Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4  1234     106      93       20    0    0 01:14:56        4

Let's check the VRF routing tables on R1.


PE1#sh ip route vrf Customer1 | beg Gateway
Gateway of last resort is not set

C    192.168.10.0/24 is directly connected, Serial1/1
     111.0.0.0/32 is subnetted, 1 subnets
B       111.111.111.111 [200/0] via 10.10.10.2, 00:23:02
     11.0.0.0/32 is subnetted, 1 subnets
S       11.11.11.11 [1/0] via 192.168.10.1
PE1#sh ip route vrf Customer2 | beg Gateway
Gateway of last resort is not set

     222.222.222.0/32 is subnetted, 1 subnets
B       222.222.222.222 [200/0] via 10.10.10.2, 00:24:04
     22.0.0.0/32 is subnetted, 1 subnets
S       22.22.22.22 [1/0] via 192.168.20.2
C    192.168.20.0/24 is directly connected, Serial1/2
PE1#sh ip route vrf Management | beg Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
S       1.1.1.1 [1/0] via 192.168.10.1
     2.0.0.0/32 is subnetted, 1 subnets
S       2.2.2.2 [1/0] via 192.168.20.2
     3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/1] via 10.10.10.2, 01:02:10
C    192.168.10.0/24 is directly connected, Serial1/1
C    192.168.20.0/24 is directly connected, Serial1/2

We can see the routes that should be there. Now let's test the Customer1 VRF first if we achieved our objective. It should be able to reach the network 111.111.111.111/32 in PE2.


Customer1#ping 111.111.111.111 source 11.11.11.11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 111.111.111.111, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/168/192 ms

Cool its working! We need to specify the source ip so that it will be in the correct VRF. Network 111.111.111.111/32 is in vrf Customer1, if we don't use a source ip, by default it will use the exit interface's ip address as the source and will not be using any vrf since we don't have a source selection mapping for that. Instead it will use the "global routing table" which doesn't have entries for 111.111.111.111/32. Let's see what happens.


Customer1#ping 111.111.111.111

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 111.111.111.111, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

As expected! Let's do a test for Customer2.


Customer2#ping 222.222.222.222 source 22.22.22.22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 222.222.222.222, timeout is 2 seconds:
Packet sent with a source address of 22.22.22.22
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/173/192 ms

And for our final objective, the Loopback0 should be reachable through vrf "Management" from ISP NOC router. By the way, since we are only using one VRF for this, it was not necessary to use source selection. It's only for example sake!:) Now for the testing.


ISPNOC#ping 1.1.1.1 source 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 172/216/264 ms
ISPNOC#ping 2.2.2.2 source 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/231/292 ms

Success!!! Whew, I don't like long blog entries but sure this will be helpful for myself in case I forget this feature. More on route-target import and export next time. Cheers!

Question of the Day: July 20, 2009

2009-07-20T21:09:00.000+08:00

Q: What are the three tables EIGRP uses to store data?

Highlight after < for the answer.

A: < Neighbor Table, Topology Table, Routing Table

For more information on this visit this page:

http://en.wikipedia.org/wiki/Enhanced_Interior_Gateway_Routing_Protocol

Question of the Day: July 19, 2009

2009-07-20T21:01:00.002+08:00

Q: Name the OSPF Neighbor States.

Highlight after < for the answer.

A: < Down,Attempt,Init,Two-Way(2way),Exstart,Exchange,Loading,Full

For more information on this visit this page:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0e.shtml

Question of the Day: July 18, 2009

2009-07-18T17:45:00.003+08:00

Q: How many BGP processes can you run in a Cisco router?

Highlight after < for the answer.

A: <Only one process

Question of the Day: July 17, 2009

2009-07-18T08:40:00.003+08:00

Q: What are the differences between DOT1Q and ISL?

Highlight after < for the answer.

A: < 1. Dot1q is IEEE standard, ISL is Cisco-proprietary. 2. Dot1q has the concept of a Native VLAN which doesn't tag the native vlan, ISL does not, it encapsulates all frames. 3. Dot1q tags the frame, ISL encapsulates it.

For more information on this visit this page:

http://www.thebryantadvantage.com/CCNACertificationExamWhySwitchesTrunkAndHow.htm

BGP AS-Path Prepending

2009-07-16T11:43:00.012+08:00

BGP is rich in features that you can have more control than on what IGP's offer however, you can only have control on how the traffic leaves your autonomous system and can't really control how other autonomous systems reach you. Other AS'es might have BGP policies that route the traffic in a way you don't intend it to go. You don't have control over those because, its their autonomous systems after all. However, there are work arounds which allow, an autonomous system affect the other autonomous systems, one of this is called BGP AS-path prepending. It is basically adding additional AS-paths by repeating your own AS number. Consider the diagram below. (Click image for a bigger view) By looking at the diagram, if you are familiar with BGP, the AS-path the networks from R4 will take towards R1 will be AS4, AS3 and then AS1. If all the attributes are set to the default values, most likely the AS-path attribute will determine which path to take. The more desirable path in this scenario is AS4, AS3, AS2 and then AS1 for the reason that there is a 100mbps link connecting AS1 and AS2 which makes traffic forwarding more efficient. But remember, unlike IGP's, BGP doesn't take to account the bandwidth.

In this scenario we are in AS1 and we make AS2 the more desirable path for AS4 to reach us using AS-path prepending.

Checking on R4 we will see how it gets to R1.


R4#
*Jul 16 13:25:54.039: %SYS-5-CONFIG_I: Configured from console by console
R4#sh ip bgp
BGP table version is 11, local router ID is 34.34.34.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       34.34.34.3                             0 3 1 i
*> 4.4.4.4/32       0.0.0.0                  0         32768 i
*> 11.11.11.11/32   34.34.34.3                             0 3 1 i
*> 44.44.44.44/32   0.0.0.0                  0         32768 i

Just as we guessed, it would take AS3 then AS1 which is the shortest path based on BGP attributes. Now we will configure AS-prepending on R1 for R4 to take the AS3, AS2 then AS1 path.


R1(config)#route-map ASPREPEND permit 10          
R1(config-route-map)#set as-path prepend 1 1 1
R1(config)#route-map ASPREPEND permit 20

We made it 1 1 1 cause it would only 2 AS paths to reach R1 from R4 through R3. We will make that AS-path longer and less desirable. We will apply this route map we created to the neighborship peering between R1 and R3.


R1(config)#router bgp 1
R1(config-router)#neighbor 13.13.13.3 route-map ASPREPEND out

The reason its in the outbound direction because R1 is advertising the subnets. Let's clear the bgp process in R1 to make the changes. Then lets see what happened to the AS-path in R4.


R4#sh ip bgp
BGP table version is 13, local router ID is 34.34.34.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       34.34.34.3                             0 3 2 1 i
*> 4.4.4.4/32       0.0.0.0                  0         32768 i
*> 11.11.11.11/32   34.34.34.3                             0 3 2 1 i
*> 44.44.44.44/32   0.0.0.0                  0         32768 i

Ok, you can see the difference now, its now taking 3-2-1. This is because it received an advertisement from R3 about the best path. BGP only advertises the best path to a network to its neighbor. Since R3 is seeing the AS_Path going to R1 is longer, it now takes AS2 to get to R1. Lets see what happened to the BGP table after applying the route map.


R3#sh ip bgp
BGP table version is 13, local router ID is 23.23.23.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       23.23.23.2                             0 2 1 i
*                   13.13.13.1               0             0 1 1 1 1 i
*> 4.4.4.4/32       34.34.34.4               0             0 4 i
*> 11.11.11.11/32   23.23.23.2                             0 2 1 i
*                   13.13.13.1               0             0 1 1 1 1 i
*> 44.44.44.44/32   34.34.34.4               0             0 4 i

Three 1's were added to the AS_Path based on what we put on the route-map, so from the AS-path values, R3 will not go directly to R1 but will take R2 now instead.

Now what if we want traffic to 11.11.11.11 to take A3 directly and traffic to 1.1.1.1 take AS3 then AS2 from R4. We will create an access-list TAKER2 and modify the route-map to match the condition.


R1(config)#ip access-list extended TAKER2
R1(config-ext-nacl)#permit ip host 1.1.1.1 any

R1(config)#route-map ASPREPEND permit 10
R1(config-route-map)#match ip address TAKER2
R1(config-route-map)#set as-path prepend 1 1 1

Let's check what happened to R3


R3#sh ip bgp
BGP table version is 28, local router ID is 23.23.23.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       23.23.23.2                             0 2 1 i
*                   13.13.13.1               0             0 1 1 1 1 i
*> 4.4.4.4/32       34.34.34.4               0             0 4 i
*  11.11.11.11/32   23.23.23.2                             0 2 1 i
*>                  13.13.13.1               0             0 1 i
*> 44.44.44.44/32   34.34.34.4               0             0 4 i

Cool, you can see the difference with the ACL. Now 1.1.1.1 in R3 has prepend but 11.11.11.11 has no prepend. Finally, lets check R4.


R4#sh ip bgp
BGP table version is 27, local router ID is 34.34.34.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       34.34.34.3                             0 3 2 1 i
*> 4.4.4.4/32       0.0.0.0                  0         32768 i
*> 11.11.11.11/32   34.34.34.3                             0 3 1 i
*> 44.44.44.44/32   0.0.0.0                  0         32768 i

From R4 traffic to 1.1.1.1 will pass through AS2 but to 11.11.11.11 it will go directly to R3 then R1. Whew, kinda hard to explain. Enough is enough! Cheers! :)

Question of the Day: July 16, 2009

2009-07-16T10:58:00.003+08:00

Q: Into which of the BGP neighbor states must a neighbor stabilize before BGP Update messages may be sent?

Highlight after < for the answer.

A: < Established

For more information on this visit this page:

http://archive.networknewz.com/networknewz-10-20060403BGPAdjacencyStates.html

Firewall Security-Level

2009-07-15T14:43:00.013+08:00

This is my first Security Post regarding Cisco PIX/ASA firewalls. To begin with, what is a firewall? Literally, in the real world, a firewall as part of a building, is used to you guessed it: protect the building from fire. :) The same applies in the networking world. A firewall is a device that prevents unauthorized access and permits authorized access to a network. A firewall may function for packet filtering, proxy server and stateful packet filtering. Cisco PIX/ASA devices function as stateful packet filtering devices, which builds a stateful connection table to verify the connections.

A firewall prevents access from the untrusted network to the trusted network. An interface of the firewall may belong to the untrusted or the trusted. The interface that belongs to the trusted network is often called the inside interface and the untrusted one is the outside interface. Security-levels from 0-100 indicates the level of trust for an interface. The higher the number the more trusted the interface. The rule in security-level is that a higher security level can have access to a lower security level, the lower security level doesn't have access to a higher security level and is blocked by default. Interfaces with the same security levels are blocked as well.

Let's configure interfaces and lets see how security-levels are applied automatically and manually. I am using a PIX firewall.

First lets configure an outside interface.


petesfirewall(config)# interface ethernet0
petesfirewall(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.

The "nameif" command is basically used to name an interface. Very obvious isn't it?:) Notice that once we named the interface "outside", Cisco automatically set the security-level to 0 meaning its untrusted. Next we configure an inside interface.


petesfirewall(config-if)# interface ethernet1
petesfirewall(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.

The PIX now configures the security level by 100 which means its a trusted interface. For this reason, traffic from ethernet1 to ethernet0 is permitted by default but traffic from ethernet0 to ethernet1 is not. This is where inbound access-list comes in to allow traffic from an untrusted interface to a trusted one.

Let us now configure an interface named "webservers". You can use any name you like by the way. Let's give it a security-level of 60.


petesfirewall(config-if)# interface ethernet2 
petesfirewall(config-if)# nameif webservers
INFO: Security level for "webservers" set to 0 by default.
petesfirewall(config-if)# security-level 60

Notice that any interface name other than "inside" is automatically given a 0 security-level value. The "security-level" command is used to specify manually a security level to an interface. Ethernet2 by default can access Ethernet0 but can't access Ethernet1, because the latter has a higher security-level than the former. The "show nameif" command is a very useful command to display the names of the interfaces including the security-levels.


petesfirewall(config)# show nameif 
Interface                Name                     Security
Ethernet0                outside                    0
Ethernet1                inside                   100
Ethernet2                webservers                60

As you can see, in the PIX firewall the show command is accepted unlike in the routers which doesn't accept show commands in the global-configuration mode. For those have been configuring routers, adapting to configuring firewalls would be easy. After all, its still Cisco. :)

Finally, sometimes there is a need to allow access to interfaces with the same security-level. The command below, will allow such access.


petesfirewall(config)# same-security-traffic permit inter-interface

There you have it. Its easy as one, two, three. Good day homies!

Question of the Day: July 15, 2009

2009-07-15T14:14:00.008+08:00

Q: What is the IEEE standard that defines Fasthernet standard?

Highlight after < for the answer.

A: <IEEE 802.3u

For more information on this visit this page:

http://www.javvin.com/protocolFastE.html

Question of the Day: July 14, 2009

2009-07-14T13:53:00.004+08:00

Q: What is the algorithm used in link-state protocols to calculate the best path?

Highlight after < for the answer.

A: < Dijkstra's Algorithm

For more information on this visit this page:

http://en.wikipedia.org/wiki/Link-state_routing_protocol

Question of the Day: July 13, 2009

2009-07-14T13:48:00.004+08:00

Q: What is the default security-level of a PIX/ASA outside interface?

Highlight after < for the answer.

A: < Zero (0)

Question of the Day: July 12, 2009

2009-07-12T19:48:00.007+08:00

Q: What are the 4 categories of BGP Attributes?

Highlight after < for the answer.

A: < 1) Well-known Mandatory 2) Well-known Discretionary 3) Optional Transitive 4) Optional Non-transitive

For more information on this visit this page:

http://www.brainbuzz.com/articles/files/border-gateway-protocol-a-982003-1304.asp

IPSEC VPN Configuration

2009-07-11T12:28:00.009+08:00

IPSEC VPN's have revolutionized the networking world. It is usually used over the unsecured network called "the Internet". It's a way to ensure secure transfer of data over the internet and used for site to site connections and telecommuters who need remote access from anywhere to the corporate Intranet or for remote branch offices that only have internet connection. We have a basic diagram below and lets configure a Site to Site IPSEC VPN. We will focus more on configuration not on the nitty gritty details of the protocols and the process of VPN creation.

Let's pretend ISP is the Internet Cloud. We have R1 and R2 connected through an internet leased line to their ISP's. Lets say R2 has a server 2.2.2.2 which R1 needs to access from 1.1.1.1 in its network. (1.1.1.1 and 2.2.2.2 are just loopback addresses in R1 and R2 respectively) We will build a VPN tunnel allowing 1.1.1.1 to access 2.2.2.2 and vice versa. Steps are numbered but not necessarily the standard way but a more favorable way of configuring.

1. Create an access-list on both R1 and R2. This will indicate the "interesting traffic". This means that anything that matches the ACL applied to the tunnel configuration will pass through the tunnel instead of exiting the interface facing the internet.


R1(config)#access-list 100 permit ip host 1.1.1.1 host 2.2.2.2
R2(config)#access-list 100 permit ip host 2.2.2.2 host 1.1.1.1

Notice that the ACL's mirror each other.

2. Configure an ISAKMP key. This key will be used to generate more keys for VPN tunnel creation and must match between the peers.


R1(config)#crypto isakmp key 0 myvpnrouter address 192.168.20.1
R2(config)#crypto isakmp key 0 myvpnrouter address 192.168.10.1

The ip address at the end of the command is the IP address of the peer router.

3. Create an ISAKMP policy. The policy components like hashing, authentication, Diffie-Helman group, and lifetime must match. You can configure many different policies and the routers will check the ISAKMP policy until it finds a match of its own. It is checked sequentially by using policy sequence numbers. ISAKMP negotiation is also called Phase 1.


R1(config-isakmp)#crypto isakmp policy 10
R1(config-isakmp)#group 2
R1(config-isakmp)#hash md5
R1(config-isakmp)#lifetime 28800
R1(config-isakmp)#encryption aes
R1(config-isakmp)#authentication pre-share

R2(config-isakmp)#crypto isakmp policy 10
R2(config-isakmp)#group 2
R2(config-isakmp)#hash md5
R2(config-isakmp)#lifetime 28800
R2(config-isakmp)#encryption aes
R2(config-isakmp)#authentication pre-share

4. Configure Phase 2 which are IPSEC parameters.


R1(config)#crypto ipsec transform-set TRANSFORMERS esp-3des esp-sha-hmac
R1(config)#crypto ipsec security-association lifetime seconds 28800
R2(config)#crypto ipsec transform-set TRANSFORMERS esp-3des esp-sha-hmac
R2(config)#crypto ipsec security-association lifetime seconds 28800

Configure a crypto map.


R1(config)#crypto map MYMAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
R1(config-crypto-map)#match address 100
R1(config-crypto-map)#description to R2
R1(config-crypto-map)#set transform-set TRANSFORMERS
R1(config-crypto-map)#set peer 192.168.20.1
R1(config-crypto-map)#set security-association lifetime seconds 28800

R2(config)#crypto map MYMAP 10 ipsec-isakmp
 % NOTE: This new crypto map will remain disabled until a peer
         and a valid access list have been configured.
R2(config-crypto-map)#match address 100
R2(config-crypto-map)#description to R1
R2(config-crypto-map)#set transform-set TRANSFORMERS
R2(config-crypto-map)#set peer 192.168.10.1
R2(config-crypto-map)#set security-association lifetime seconds 28800

5. Apply the Crypto map to the outgoing interface.


R1(config)#int se1/1
R1(config-if)#crypto map MYMAP
R1(config-if)#
*Jul 11 13:05:47.007: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

R2(config)#int se1/2
R2(config-if)#crypto map MYMAP
R2(config-if)#
*Jul 11 13:05:47.007: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

6. Make sure you have a route towards the peer vpn router public ip. In our case lets create a default route.


R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.10.10 name To_R2
R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.20.20 name To_R1

7. Finally lets test the connection. The tunnel won't come up until there is interesting traffic passing through the tunnel. Any traffic that will hit the access-list we matched in the crypto-map will trigger the tunnel negotiation. In our case lets ping 2.2.2.2 from R1 sourcing from the Loopback interface 1.1.1.1. In the ISP router, I have configured a route for the 2 loopback addresses.


ISP(config)#ip route 2.2.2.2 255.255.255.255 192.168.20.1
ISP(config)#ip route 1.1.1.1 255.255.255.255 192.168.10.1

R1#ping 2.2.2.2 source 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!

To verify if the tunnel is up and running, lets use the "show crypto isakmp sa" to check Phase 1 status.


R1#sh cry isakmp sa
dst             src             state          conn-id slot status
192.168.20.1    192.168.10.1    QM_IDLE              1    0 ACTIVE

QM_IDLE means that the tunnel is up. If the state is not that, that means that there is a problem.

"Show crypto ipsec sa" displays Phase 2 information which includes the number of packets that used the tunnel and the source and destination IP. Thats it for the configuration. For more detailed information on the VPN negotiation process visit this link. Cheers

Question of the Day: July 11, 2009

2009-07-11T10:40:00.015+08:00

Q: What is a virtual link?

Highlight after < for the answer.

A: < All areas in an OSPF autonomous system must be physically connected to the backbone area (area 0). In some cases where this physical connection is not possible, you can use a virtual link to connect to the backbone through a non-backbone area. As mentioned above, you can also use virtual links to connect two parts of a partitioned backbone through a non-backbone area. The area through which you configure the virtual link, known as a transit area, must have full routing information. The transit area cannot be a stub area.

For more information on virtual-links visit this page:

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801ec9ee.shtml

Question of the Day Portion

2009-07-11T10:33:00.007+08:00

Its been a while since I last posted an entry. I have been doing some reading and I feel that for the mastery of the topics, a question of the day portion would be very nice. CCIE Pursuit blog shows some excellent Question of the day portion which I think would be good for my blog. All credit goes to CCIE Pursuit blog for this idea! From here own, I'll start the question of the day.

VRF Basics

2009-06-11T11:33:00.009+08:00

When we hear about VRF, its almost synonymous to MPLS VPN. Virtual Routing and Forwarding is commonly used by Service Providers to provide services within an MPLS cloud with multiple customers. The most interesting feature of this is that, VRF allows creation of multiple routing tables within a single router. This means that overlapping use of IP addresses from different customers is possible. Some enterprises use VRF to seggrate their services like VOIP, wireless, geographical location and other varieties. Through the network setup below, we will see how to configure VRF and check if its really possible for duplicate ip addresses. We have 3 customers in the figure connected to a Provider Edge router. We will name the VRF's Blue, Red and Yellow. Click image for a bigger view.

Now let's configure RD's on the PE router.


Router(config)#host PE 
PE(config)#ip vrf blue 
PE(config-vrf)#rd 1:1 
PE(config-vrf)#ip vrf red 
PE(config-vrf)#rd 2:2 
PE(config-vrf)#ip vrf yellow 
PE(config-vrf)#rd 3:3

Basically the "rd" command is in the format ASN:nn or IP-address:nn. The VRF names and rd values are actually locally significant which means that it doesn't matter what name you create. What really matters is the "route target" value because this is what you will import or export. More about this on the next blog entry.

Now we have created VRF's, lets configure interfaces and apply the VRF's to the interfaces.


PE(config)#int fa0/0.2
PE(config-subif)#encapsulation dot1q 2
PE(config-subif)#ip vrf forwarding blue
PE(config-subif)#ip address 1.1.1.1 255.255.255.252
PE(config-subif)#int fa0/0.3
PE(config-subif)#encapsulation dot1q 3
PE(config-subif)#ip vrf forwarding red
PE(config-subif)#ip address 1.1.1.1 255.255.255.252
PE(config-subif)#int fa0/0.4
PE(config-subif)#encapsulation dot1q 4
PE(config-subif)#ip vrf forwarding yellow
PE(config-subif)#ip address 1.1.1.1 255.255.255.252

If you notice above all interfaces have the same ip address which is 1.1.1.1. Normally without VRF, the router will give a warning message that overlapping ip addresses are not allowed. The command "ip vrf forwarding " will add the vrf to a specific interface.

Let's configure the other routers Blue, Red and Yellow with 1.1.1.2/30 on their FastEthernet0/0 interfaces. Lets ping 1.1.1.1 from the routers.


Blue#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/35/80 ms

Red#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/48/156 ms

Yellow#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/60/136 ms

It's good! We have ip reachability to PE from the CE routers. Now, from PE point of view, how will PE know which one to ping if we use 1.1.1.2 since all Blue, Red and Yellow routers use the same ip? This can be accomplished using the "ping vrf " command. See below.


PE#ping vrf blue 1.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/28/68 ms
PE#ping vrf red 1.1.1.2 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/28/88 ms
PE#ping vrf yellow 1.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/31/68 ms

Now, we have proven that duplicate IP addresses is possible using VRF. Be reminded that VRF's are usually and by standard configured on PE routers. CE routers normally don't make use of VRF's but there are always exceptions. Next entries will focus on importing Route Targets and using IGP's and BGP on a MPLS VPN setup. Cheers.

Simple TCL Ping Script

2009-05-11T18:13:00.008+08:00

Doing ping tests for lots of IP addresses can be tiring since you can't paste all the ping commands at the same time. You have to do it one at a time. All you need is Patience or you can opt for a TCL scripting language which is already available in Cisco IOS 12.2(25). At first, I thought you need to learn TCL scripting to be a CCIE but nah! :) All you need is the basics and if you are interested learning more about TCL you can click here. To access the tcl command line in Cisco router issue the "tclsh" command. For the ping script just modify the ip addresses what is shown below and it should be good.


foreach address {
1.1.1.1
2.2.2.2
3.3.3.3
4.4.4.4
5.5.5.5
6.6.6.6
} { puts [ exec "ping $address" ] }

The word "address" here is just a variable, you can substitute this with anything you want. Now lets try applying this to the Cisco router.


R0#tclsh
R0(tcl)#foreach address {
+>(tcl)#1.1.1.1
+>(tcl)#2.2.2.2
+>(tcl)#3.3.3.3
+>(tcl)#4.4.4.4
+>(tcl)#5.5.5.5
+>(tcl)#6.6.6.6
+>(tcl)#} { puts [ exec "ping $address" ] }

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/44/100 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/27/56 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/26/96 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/27/52 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/27/96 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/84 ms

How cool is that!!! This script can be useful when you are doing your CCIE lab exams as they say, when you want to verify that every subnet in your lab routers are reachable. You can try this in your own Dynamips lab. This should be safe to be done in the production routers but where I work, I doubt if this will be allowed by the company's IT policy. :P

BGP Local-AS

2009-05-10T16:46:00.008+08:00

When configuring BGP, we usually use the "remote-as" command to specify the AS of the neighbor specified. The purpose of the "local-as" command is to spoof the neighbor router by advertising a different AS other than the real AS of the originating router. This command is very useful whenever there is an ISP merger, when one ISP purchases another. Let's say ISP1 purchases ISP 2 and wants it to belong to AS 12345. The customers of ISP2's routers should need to configure the new "remote-as" on their end because ISP2 will now be on AS12345. As a temporary solution, "local-as" command can be configured on the ISPs's router and still have a BGP adjancency without any changes on the customer side. To see how local-as functions, let's take the diagram below as an example.

Scenario: R2 used to belong to AS 250 and now is on AS 200.

First, let see what happens in the router is there is a "remote-as" mismatch on the neighbors.


R2#
*May 10 15:33:38.983: %BGP-3-NOTIFICATION: received from neighbor 192.168.12.1 2
/2 (peer in wrong AS) 2 bytes 00C8

This is because R1 is configured as "neighbor 192.168.12.2 remote-as 250" but R2 now belongs to AS 200. Lets configure "local-as" in R2.


R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router bgp 200
R2(config-router)#neighbor 192.168.12.1 local-as 250
*May 10 15:39:02.931: %BGP-5-ADJCHANGE: neighbor 192.168.12.1 Up neighbor 192.168.12.1

Now, adjacency is up! R2 "spoofed" its AS by sending AS 250 instead of AS 200. There is an option you can add to the local-as command. The "no-prepend" command. Before adding the option lets check "show ip bgp" output.

*May 10 16:29:49.119: %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up
R1#sh ip bgp
BGP table version is 55, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 192.168.12.2 0 0 250 200 i
*> 3.3.3.3/32 192.168.12.2 0 250 200 300 i
*> 11.11.11.11/32 0.0.0.0 0 32768 i
*> 22.22.22.22/32 192.168.12.2 0 0 250 200 i
*> 33.33.33.33/32 192.168.12.2 0 250 200 300 i

R2#sh ip bgp
BGP table version is 63, local router ID is 22.22.22.22
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.12.1 0 0 250 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 192.168.23.3 0 0 300 i
*> 11.11.11.11/32 192.168.12.1 0 0 250 100 i
*> 22.22.22.22/32 0.0.0.0 0 32768 i
*> 33.33.33.33/32 192.168.23.3 0 0 300 i

R3#sh ip bgp
BGP table version is 35, local router ID is 33.33.33.33
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.23.2 0 200 250 100 i
*> 2.2.2.2/32 192.168.23.2 0 0 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
*> 11.11.11.11/32 192.168.23.2 0 200 250 100 i
*> 22.22.22.22/32 192.168.23.2 0 0 200 i
*> 33.33.33.33/32 0.0.0.0 0 32768 i

We notice that in the AS path, we can see AS 250. Lets check the routers after adding the "no-prepend" option.


R2(config-router)#neighbor 192.168.12.1 local-as 250 no-prepend
R1#sh ip bgp
BGP table version is 63, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 192.168.12.2 0 0 250 200 i
*> 3.3.3.3/32 192.168.12.2 0 250 200 300 i
*> 11.11.11.11/32 0.0.0.0 0 32768 i
*> 22.22.22.22/32 192.168.12.2 0 0 250 200 i
*> 33.33.33.33/32 192.168.12.2 0 250 200 300 i

R2#sh ip bgp
BGP table version is 79, local router ID is 22.22.22.22
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.12.1 0 0 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 192.168.23.3 0 0 300 i
*> 11.11.11.11/32 192.168.12.1 0 0 100 i
*> 22.22.22.22/32 0.0.0.0 0 32768 i
*> 33.33.33.33/32 192.168.23.3 0 0 300 i

R3#sh ip bgp
BGP table version is 39, local router ID is 33.33.33.33
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.23.2 0 200 100 i
*> 2.2.2.2/32 192.168.23.2 0 0 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
*> 11.11.11.11/32 192.168.23.2 0 200 100 i
*> 22.22.22.22/32 192.168.23.2 0 0 200 i
*> 33.33.33.33/32 0.0.0.0 0 32768 i

R1 is not affected by the command, but R2 and R3 are. We can now see, that the AS 250 path is no longer included in the AS path. That's the purpose of the "no-prepend" command option, to hide that local-as configured from the other ebgp peers/ There is a "sub-option" however, for the "no-prepend" commands and that is the "replace-as" command. Lets see what it does.


R2(config-router)#neighbor 192.168.12.1 local-as 250 no-prepend replace-as

R1#sh ip bgp
BGP table version is 47, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 192.168.12.2 0 0 250 i
*> 3.3.3.3/32 192.168.12.2 0 250 300 i
*> 11.11.11.11/32 0.0.0.0 0 32768 i
*> 22.22.22.22/32 192.168.12.2 0 0 250 i
*> 33.33.33.33/32 192.168.12.2 0 250 300 i

R2#sh ip bgp
BGP table version is 71, local router ID is 22.22.22.22
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.12.1 0 0 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 192.168.23.3 0 0 300 i
*> 11.11.11.11/32 192.168.12.1 0 0 100 i
*> 22.22.22.22/32 0.0.0.0 0 32768 i
*> 33.33.33.33/32 192.168.23.3 0 0 300 i

R3#sh ip bgp
BGP table version is 31, local router ID is 33.33.33.33
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.23.2 0 200 100 i
*> 2.2.2.2/32 192.168.23.2 0 0 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
*> 11.11.11.11/32 192.168.23.2 f0 200 100 i
*> 22.22.22.22/32 192.168.23.2 0 0 200 i
*> 33.33.33.33/32 0.0.0.0 0 32768 i

This command somehow affects R1 only, and what it does is it replaces AS 200 with AS 250 on the AS path.

Cisco Router as a DNS server

2009-05-06T17:59:00.012+08:00

Not exactly like a DNS server that is hosted from a server and so on and so forth, the Cisco Router can act like a DNS server without the service stated above. It can even act as a proxy dns server, meaning forwarding the request to the upstream DNS server and cache the replies from the DNS server, so it can use the cache entries for other requesting hosts. We will only focus on the simple and practical configuration. I don't even know if this feature can be called a "DNS server" feature. :P If you have your own Dynamips Lab and has fixed ip addresses, it would be easier though to use hostnames when trying to ping devices. This can be achieved by the "ip host" command. It can be configured as the example below.


Router(config)#ip host R1 1.1.1.1
Router(config)#ip host R2 2.2.2.2
Router(config)#ip host R3 3.3.3.3
Router(config)#ip host R4 4.4.4.4

Let's do a ping test.



Router#ping R1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
...

Well, R1 now resolves to 1.1.1.1. There you have it, makes life easier! :P

Using Aliases in Cisco Routers

2009-05-06T17:24:00.008+08:00

Cisco has long, frequently used commands like our favorites "show ip interface brief", "show ip route" and the annoying "do show" commands while in the global configuration mode. If you want the easy way, the good news is there is an easy way. Using aliases will save you some keystrokes. Here's the way to configure aliases. We will create aliases for the commands above and also be able to use the "show" command on the global configuration mode. "show ip interface brief" will be assigned with the alias "sib", "show ip route" will be "sir" and "do show" will be "show".


Router(config)#alias exec sib show ip interface brief
Router(config)#alias exec sir show ip route
Router(config)#alias configure show do show

Let's test if the alias commands really work.


Router#sib
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES unset  administratively down down

Router#sir
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
  D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
  N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
  E1 - OSPF external type 1, E2 - OSPF external type 2
  i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
  ia - IS-IS inter area, * - candidate default, U - per-user static route
  o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

Router#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#show ip int brief
Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            unassigned      YES unset  administratively down down

Well it did! Lets check what we will see in IOS help.


Router#s?
*s=show     *sib="show ip interface brief"  *sir="show ip route"  sdlc
send        set                             setup                 show
slip        snasw                           squeeze               ssh
start-chat  systat

Router#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#s?
*show="do show"  sap-priority-list  scheduler          scripting
secure           security           service            sgbp
signaling-class  sip-ua             sna                snasw
snmp             snmp-server        source-bridge      srcp
standby          state-machine      stun               su-mac
su-tag           subscriber         subscriber-policy  subscription

Now we see the aliases we made and they have the preceeding asterisk before them. *s=show is the default alias in the router. Cool! Try other aliases in different modes, make your own aliases and just be creative!