New Job

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

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

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

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

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

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

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

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

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!!!

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.