Anthony and guest world renowned CCIE instructors: Scott Morris, Keith Barker, Marko Milivojevic, Kevin Wallace, Vik Malhi, and Joe Astorino will cover in depth and demonstrate on the following topics:

• Tuesday, March 6, 2012: Topic: Implement Layer 2 Technologies
• Tuesday, March 13, 2012: Topic: Implement Layer 2 Technologies
• Tuesday, March 20, 2012: Topic: Implement IPv4
• Tuesday, March 27, 2012: Topic: Implement IPv4
• Tuesday, April 3, 2012: Topic: Implement IPv6
• Tuesday, April 10, 2012: Topic: Implement MPLS Layer 3 VPNs
• Tuesday, April 17, 2012: Topic: Implement IP Multicast
• Tuesday, April 24, 2012: Topic: Implement Network Security
• Tuesday, May 1, 2012: Topic: Implement Network Services
• Tuesday, May 8, 2012: Topic: Implement Quality of Service
• Tuesday, May 15, 2012: Topic: Optimize the Network
• Tuesday, May 22, 2012: Topic: Final Exam Week

This live, online event from IPexpert is also unique in that it provides unprecedented access to the course instructor during, and following, the 12 week long event.

Register today for only $499 

Materials Provided:

• Slide PDF workbook for note taking and review
• Full practice exam delivered during Final Exam Week
• 24 x 7 access to all recorded class sessions
• 30 minute one-on-one call with instructor; scheduled during the 12 week event; additional one-on-one’s available as needed
• Private Facebook group
• Facebook and/or Skype chat access with class instructor (Daily, 7a-11p EST)
• 80 hours of Virtual Rack Vouchers

Live class hours are scheduled in the evening every Tuesday beginning March 6th Eastern Standard time for 12 weeks to help ensure working professionals are able to study without sacrificing valuable time away from the office or business engagements.

Check out what some of the students had to say about the last class held:

Patrik Berlund Jimenez:
“I took a couple of days off from work this week to study since I had booked the written for next week. It felt really good and I felt like “I got this”, so I moved the written exam to this morning and I PASSED! Just a couple of minutes ago, I can barely believe it. I mainly used this bootcamp to rehearse (and to ask Anthony a bunch of questions), which I think (obviously) worked out great!!! =) Now I can really relax and enjoy the weekends, and afterwards I’m looking forward to continuing my studies with IPexpert for the lab exam!”

Mohammed Yahya Mousa:
“I passed the written today! I would like to thank Matt Just, all the guest speakers and a SPECIAL THANKS to our Instructor Anthony. I am planning to take the lab in July (7 months from now), it’s time use the Blended Learning Solution and listen to the VOD with Joe Astorino. Wish you all good luck, I really enjoyed the CCIE R&S Written and Lab Fundamentals Exam Bootcamp.”

Matt Just
Chief Technology Officer

IPexpert Inc
Email: mjust@ipexpert.com
Office: (810) 326-1444 Ext: 331

Print Friendly

Tomorrow it is here – the start of our upcoming online bootcamp from IPexpert!

Agenda:

Session 1 - Tuesday, November 1, 2011

Introduction and Implement Layer 2 Technologies

• Exam Details
  • The Written Exam
  • The Lab Exam
• Four Cornerstones for Success
  • Knowledge of Technologies
  • Strategies
  • Psychology
  • Physical Wellness
• Killer Strategies
  • Written Prep
  • Written Exam
  • Lab Prep
  • Lab Exam
• Frame Relay
  • Multipoint
  • Point-to-Point
  • Inverse ARP
  • Static Mappings
  • PPP over Frame Relay
  • Troubleshooting Frame Relay
• Catalyst Switch Configurations
  • VLANs
  • SVIs
  • Trunking
  • Router on a Stick
  • VTP
  • 802.1D
  • STP Toolkit
  • UDLD
  • 802.1w
  • 802.1s
  • Rapid-PVST+

Special Guest Speaker:

Joe Astorino

CCIE #24347, R&S – Joe Astorino is an experienced network engineer specializing in routing and switching, specifically in large enterprise network environments.  He has worked on some of the largest enterprise networks in the world, including those owned by General Motors, Ford Motor Company and the US Department Of Defense.  Joe also has a true passion for teaching Cisco networking technologies!  Joe spent some time as a senior technical instructor with IPexpert, where he contributed to students’ CCIE success by leading CCIE R&S bootcamps, and developing self study material (including the CCIE R&S v4.0 video on demand course).  Joe is now leading a technical team of network engineers at a large internationally based company, while teaching his own self developed Cisco courses and consulting locally in the Grand Rapids, MI area.

Print Friendly

Join us in congratulating the following CCIEs on their great achievement;

• Ramarao Vadlamudi CCIE #28700 (R&S)
• Nadeem Rafi CCIE #28781 (R&S)

Ramarao Vadlamudi CCIE #28700:
On 21/4/2011 I have been certified as CCIE 28700(R&S) in Sydney. Thanks for your CCIE R&S training material and the Online Study List. I found your CCIE blog to be useful to understand not just R&S topics but also emerging technologies. I would pass my heart felt thanks to the Structured Learning Approach study material that you guys have provided to attain my CCIE. Actual exam was easier than the CCIE R&S Workbook vol3.
A quick summary of my experience in CCIE journey..

• Get good study material (which is comprehensive and tailored to understand in an easy format) IPexpert is good. I personally used the CCIE R&S BLS from IPexpert.
• Get involved in a study group.
• Read CCIE blogs to understand technologies
• Practice, Practice and Practice….You do not have a shortcut.
• In real exam, read your questions a good number of times. Ask proctor if you’re not sure and do not assume if you don’t understand questions.

Nadeem Rafi CCIE #28781:
I would like to thank IPexpert team; Wayne, Tyson and Joe Astorino. Wayne has offered me his end to end program along with CCIE R&S bootcamp. I would like to admit IPexpert study guides and videos/audio guides are superb. This material is to the point and concise. If some one want to do CCIE on fast track then IPexpert is best suited for him. Joe and Tyson are always available on skype for any kind of question you got. Their audio and video classes are best. I would admit I have not worked extensively with IPexpert program, but what ever I have studied from IPexpert it was proved to be good. Once again Thanks IPexpert Team.

IPexpert is proud to boast the world’s largest list of CCIE success stories, and the industry’s most complete and updated self-study portfolio for the CCIE Routing & Switching, CCIE Voice, CCIE Security, and CCIE Wireless Lab exams. Have you also used IPexpert or Proctor Labs to help you pass the CCIE lab exam? If so, we want to hear your story! Please email us at success@ipexpert.com.

Print Friendly

Congratulations to:
• Rob Simmons #26625 (R&S)
• Dominic Zeni #26686 (R&S)

Rob Simmons stated:

“I’d like to thank all of the folks at IPexpert for their support in helping me attain my CCIE. I would highly recommend all CCIE candidates utilize the products offered by IPexpert. I couldn’t have done it without your company’s BLS which was the foundation of my CCIE training material. Also, your OnlineStudyList is hands down the best CCIE email list in the industry (Joe Astorino was especially helpful). Thanks for making this a great journey.”

Rob Simmons CCIE # 26625

IPexpert is proud to boast the world’s largest list of CCIE success stories, and the industry’s most complete and updated self-study portfolio for the CCIE Routing & Switching, CCIE Voice, CCIE Security and CCIE Service Provider Lab exams. Have you also used IPexpert or Proctor Labs to help you pass the CCIE lab exam? If so, we want to hear your story! Please email us at success@ipexpert.com.

Print Friendly

Site-Local Addresses

Site-local addresses were the first stab at having a private address space range for our internal organizations similar to RFC 1918 for IPv4. This address space was defined in RFC 3513 as being in the range FEC0::/10. Basically what this means is that the first 12 bits of the address had to look something like this:

1111 1110 11xx

[ F ] [ E ] [C-F]

So anyways, the site-local address was the first attempt at letting network admins assign their own private addressing for their “sites.” The issues with it were that the term “site” was somewhat ambiguous. Nobody could really agree on what a “site” was. Secondly, there was no guarantee that no two sites within the same organization would not end up using overlapping site addressing due to carelessness or whatever else. Site-Local addresses went to sleep permanently when deprecated officially in RFC 3879. Unfortunately for the current CCIE candidate, this site-local address range is still used quite extensively in some Cisco documentation

Unique-Local Addresses

Out with the old in with the new! Unique-Local addresses have officially replaced site-local addresses. These get a little bit more interesting because there are really two different “flavors.” Unique-Local Addresses (ULA) are defined in RFC 4193 and are given the range FC00::/7. Basically your first 8 bits will look like this:

1111 110x

[F ] [C-D]

Overall, your unique-local address will look something like this:

F[C-D]xx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

So obviously it starts with EITHER FC or FD in hexadecimal. The string of ‘x’s there represents what we call our “global-id” which would describe your company and is 40 bits long. The string of ‘y’s represent what we call the “subnet-id” which describes the sites within your company and is 16 bits long. The string of ‘z’s is the remaining 64 bits that represent a host. So essentially you have a 40-bit value that represents your company and 16 bits to play with for subnetting. If you do the math that gives you up to 65,535 /64 subnets…a LOT of addresses.

OK, so we have this FC00::/7 range. Now, here is where it gets a little extra interesting. Basically some people thought the 40-bit global-id should be something centrally assigned by a registrar of sorts (kind of like ARIN). The addresses would still not be routable on the public internet, but would be controlled by a trusted third party registrar. The reasoning was so that it was guaranteed that no two sites within an organization would ever get overlapping ranges. On the other hand, other people didn’t like the idea of having private addresses allocated to them. Therefore, what they did was a compromise. They took this massive FC00::/7 range and broke it up into two individual /8’s – FC00::/8 and FD00::/8 and each one works a bit differently.

Unique-Local Locally-Assigned Addresses (FD00::/8)

The folks that do not want their private addresses assigned to them by a third party get this range. The kicker is that in the RFC the way that 40-bit global-id get’s picked is still not really SUPPOSED to be up to you. It is a randomly generated number (at least “pseudo-random”). So, with FD00::/8 you get something like this

FDxx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

Here the string of ‘x’s is still the global-id and is 40-bits long…it is just randomly generated, or at least SHOULD be. The rest is the same…we still have 16 bits for subnetting and a /64 host address

Unique-Local Centrally-Assigned Addresses (FD00::/8)

The folks that WERE for the private addresses being centrally assigned by some sort of registrar get the FC00::/8 range. Now, as of right now this organization that is supposed to hand out the addresses really doesn’t exist yet :P ANYWAYS, the concept is similar except now you have something like this:

FCxx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

Here the string of ‘x’s is still the global-id and is 40-bits long…but it is ASSIGNED to you in theory. The rest is the same…we still have 16 bits for subnetting and a /64 host address

So now what?!

For purposes of the CCIE R&S v4.0 lab – IF you are asked to do “site-local” addressing I would verify with the proctor that they REALLY mean site-local as in the FEC0::/10 range. IF that is the case, go ahead and just pick something in the range and use it while smiling to yourself because it is really deprecated.

IF you are asked to do unique-local addressing I would watch the wording of your lab. If it says something about you being “assigned” such and such range, I would opt for the centrally assigned range of FC00::/8. They may say something like “You have been ASSIGNED a global-id of ABCD:EF12:34. Use the middle two octets of your IPv4 subnet as your subnet ID.” Let’s say the middle two octets were 4.4 in your IPv4 address space. That would equate to something like FCAB:CDEF:1234:0404::/64. Because they said ASSIGNED I would assume we were using the FC00::/8 range. The next 40 bits (global-id) were given to you, and you derived the next 16 bits from your IPv4 address.

IF you are told to do unique-local addressing and they mention something about you assigning your global-id yourself, or having it randomly generated I would opt for the FD00::/8 locally assigned range. Maybe you would have a task similar to this: “You have decided to assign the unique-local global-id of BABA:CACA:12. Use the middle two octets of your IPv4 subnet as your subnet ID.” That would equate to something like FDBA:BACA:CA12:0404::/64. Because they said YOU assigned it to yourself or that it was “randomly generated” I would use the FD00::/8 range of addressing there.

Don’t you miss RFC 1918 now? :P

–
Joe Astorino
CCIE #24347 (R&S)

Print Friendly

Alright, that doesn’t look so bad does it? Well…not if you already have read my MPLS L3 VPN blog heh… So what we have going on here is a simple MPLS L3 VPN setup. We have a customer, we’ll call them “Customer A” and they have two remote sites connected together via the services provider MPLS cloud here. Additionally, they have a direct “backdoor link” configured between them for backup purposes. The PE/CE routing protocol of choice here is OSPF.

To start things off, let’s disable the backdoor links and just see how things work normally. Also notice we are running the SAME OSPF process-ID on both PE routers for the customer VRF and that both customer sites are running in area 0 on all links. All the MPLS and redistribution has already been done here.

R1:

R1(config-router)#int fa0/1
R1(config-if)#shut

R7:

R7(config-router)#int fa0/1
R7(config-if)#shut

R2:

R2#sh ip proto vrf CustA | i Routing Protocol
Routing Protocol is "ospf 2"
Routing Protocol is "bgp 55"

R4:

R4(config)#do sh ip proto vrf CustA | i Routing Protocol
Routing Protocol is "ospf 2"
Routing Protocol is "bgp 55"

OK. So what do our routes look like on R1 and R7?

R1:

R1#sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.12.2         1   FULL/BDR        00:00:38    10.0.12.2       FastEthernet0/0

R1#sh ip route ospf
7.0.0.0/32 is subnetted, 1 subnets
O IA    7.7.7.7 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
O IA    10.0.47.0/24 [110/2] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.204.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.201.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.200.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.203.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.202.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0

R7:

R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
O IA    10.0.12.0/24 [110/2] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.104.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.103.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.102.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.101.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.100.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0

Alright, wait a tick…the site-to-site routes are showing up as O IA INTER-area routes via type-3 summary LSAs. But…aren’t I in the same area, area 0? Well…”sort of” By default, if our OSPF domain-ID matches on both sides and we are transporting routes over MPLS we will get inter-area routes here. The domain-ID is the OSPF process ID by default, but can be changed. If they are not the same, we will see the routes come in as external O E2 routes. Let’s see that in action.

R4:

R4(config-router)#router ospf 2
R4(config-router)#domain-id 0.0.0.3

R7:

R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2    1.1.1.1 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
O E2    10.0.12.0/24 [110/1] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.104.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.103.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.102.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.101.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.100.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0

Wow, that is pretty cool! Let’s change it back now…

R4:

R4(config-router)#no domain-id 0.0.0.3

R7:

R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
O IA    10.0.12.0/24 [110/2] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.104.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.103.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.102.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.101.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.100.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0

Alright…well that is neat and pretty cool and all, but we still don’t know what a sham-link is at this point! Let’s bring up that backup link. Notice that right now the MPLS path is the ONLY path we know traffic through.

R1:

R1(config)#int fa0/1
R1(config-if)#no shut

R7:

R7(config-if)#int fa0/1
R7(config-if)#no shut
R7(config-if)#do sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.104.1        1   FULL/DR         00:00:36    10.0.17.1       FastEthernet0/1
10.0.47.4         1   FULL/BDR        00:00:36    10.0.47.4       FastEthernet0/0
R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
O       10.0.12.0/24 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.104.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.103.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.102.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.101.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.100.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1

Hmmm…interesting! When I brought up the backup link over VLAN 17, my routes completely changed. NOW my best path is an INTRA-area route via VLAN 17. Why? Well, OSPF always preferes intra-area routes to inter-area routes. Even if we tweaked our OSPF metric all day long to give precedence to the MPLS route, we are screwed at this point due to this rule. This is a rule of OSPF we can NOT change…but can we manipulate other things? What if we could make the routes coming in from the MPLS intra-area routes as well? Enter the sham-link. The sham link is essentially an OSPF virtual-link that goes through the service provider cloud to connect two areas together. So basically, we can create a special virtual-link between our PE routers called a sham-link that connects our two area 0’s together. The routes over the sham link will then be considered inter-area routes. Let’s do it! For this to work, we need to do a few things:

• A /32 loopback address on each PE router. This loopback has to be in the customer VRF and can NOT be directly advertised into OSPF.
• Advertise these loopbacks into MP-BGP as vpnv4 routes. This is how the PE routers will learn about the endpoints of the sham-link.
• Configure the sham-link under the OSPF process on the PE routers

R2:

R2(config)#int lo22
R2(config-if)#ip vrf forwarding CustA
R2(config-if)#ip add 22.22.22.22 255.255.255.255
R2(config-if)#router bgp 55
R2(config-router)#address-family ipv4 vrf CustA
R2(config-router-af)#network 22.22.22.22 mask 255.255.255.255
R2(config-router-af)#router ospf 2
R2(config-router)#area 0 sham-link 22.22.22.22 44.44.44.44

R4:

R4(config-router)#int lo44
R4(config-if)#ip vrf forwarding CustA
R4(config-if)#ip add 44.44.44.44 255.255.255.255
R4(config-if)#router bgp 55
R4(config-router)#address-family ipv4 vrf CustA
R4(config-router-af)#network 44.44.44.44 mask 255.255.255.255
R4(config-router-af)#router ospf 2
R4(config-router)#area 0 sham-link 44.44.44.44 22.22.22.22
R4(config-router)#do sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
6.6.6.6           0   FULL/  -        00:01:35    100.100.100.6   Serial0/0/0
10.0.12.2         0   FULL/  -           -        22.22.22.22     OSPF_SL1
10.0.204.7        1   FULL/DR         00:00:31    10.0.47.7       FastEthernet0/0

Rock N’ Roll!!! Notice the sham-link came up! (OSPF_SL1) So, to recap we added a loopback on both ends. We advertised that loopback into MP-BGP in the CustA VRF. We then created a sham-link that connected our two area 0’s together. NOW, let’s see those routes.

R7:

R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
22.0.0.0/32 is subnetted, 1 subnets
O E2    22.22.22.22 [110/1] via 10.0.47.4, 00:04:23, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
O       10.0.12.0/24 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.104.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.103.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.102.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.101.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.100.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
44.0.0.0/32 is subnetted, 1 subnets
O E2    44.44.44.44 [110/1] via 10.0.47.4, 00:02:48, FastEthernet0/0

Boooooo, hisssssss, stink! We still have the same problem. Why? Well, despite the fact that we now have intra-area routes through the MPLS, the cost over the directly connected FastEthernet interface still beats us (darn FastEthernet cost of 1!!!) Oh well, this is easily fixed…

R1:

R1(config-if)#int fa0/1
R1(config-if)#ip ospf cost 10

R7:

R7(config-if)#int fa0/1
R7(config-if)#ip ospf cost 10
R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
22.0.0.0/32 is subnetted, 1 subnets
O E2    22.22.22.22 [110/1] via 10.0.47.4, 00:06:32, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
O       10.0.12.0/24 [110/3] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.104.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.103.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.102.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.101.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.100.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
44.0.0.0/32 is subnetted, 1 subnets
O E2    44.44.44.44 [110/1] via 10.0.47.4, 00:04:57, FastEthernet0/0

R1:

R1(config-if)#do sh ip route ospf

22.0.0.0/32 is subnetted, 1 subnets
O E2    22.22.22.22 [110/1] via 10.0.12.2, 00:07:38, FastEthernet0/0
7.0.0.0/32 is subnetted, 1 subnets
O       7.7.7.7 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
O       10.0.47.0/24 [110/3] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.204.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.201.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.200.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.203.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.202.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
44.0.0.0/32 is subnetted, 1 subnets
O E2    44.44.44.44 [110/1] via 10.0.12.2, 00:05:43, FastEthernet0/0

Rock N’ Roll…Notice the best path is now via the MPLS and they are INTRA-Area routes! There is also an option when we create the sham-link to set the cost of the sham-link. In this case, it wouldn’t really help use since our total path cost out VLAN 17 is like 2 :P So there you have it…that’s not so bad now is it?

–
Joe Astorino
CCIE #24347 (R&S)

Print Friendly

MPPE is a protocol defined by RFC 3078 which provides a way to do encryption over PPP links. The protocol allows for two different types of encryption which differ on the size of the key. The two key sizes supported are 40-bit, and 128-bit and the encryption itself uses an RC4 cipher. The session keys themselves also change dynamically. Encryption of the PPP links is something that is negotiated by a lower level sub-protocol of PPP known as CCP (Compression Control Protocol) during NCP phase of PPP link negotiation.

OK, now that we have looked at the important protocol information with a 5 minute summary of the RFC let’s look at how to actually get this working in a Cisco environment! For our test bed, we will simply be looking at two routers on a standard proctorlabs rack — R2 and R5. R2 and R5 have a direct PPP link between them on interface s0/2/0.

One thing to be aware of before we look at the configuration is that in order to get MPPE working on a Cisco router you must already have configured and working authentication. Specifically, you must run MS-CHAP authentication. MS-CHAP is a microsoft-ized version of the popular CHAP authentication protocol. Let’s get started. For our example, we will simply do 1-way authentication to make things simple. R2 will be authenticating R5. We will use the hostname as the username and a password of “pants.”

R2:

username R5 password pants
!
interface Serial0/2/0
 ip address 25.25.25.2 255.255.255.0
 encapsulation ppp
 clock rate 2000000
 ppp encrypt mppe 128 required
 ppp authentication ms-chap

R5:

interface Serial0/2/0
 ip address 25.25.25.5 255.255.255.0
 encapsulation ppp
 ppp encrypt mppe 128
 ppp chap password 0 pants

Let’s take a look at some debug and show command output to verify our configuration. Notice that on R2 we have specified the required keyword. This means that R2 will require that the other side of the link use 128-bit encryption for the line to come up properly. We have configured 128-bit encryption on the remote end so we are good. Also notice that we use the usual “ppp chap password” command on R5 even though technically it is MS-CHAP. There is no “ppp ms-chap…” command.

Let’s take a look at a “debug ppp negotiation” on R5 when the interface comes up

R5(config-if)#no shut
 R5(config-if)#
*Apr  6 13:23:27.832: Se0/2/0 PPP: Outbound cdp packet dropped
*Apr  6 13:23:29.832: %LINK-3-UPDOWN: Interface Serial0/2/0, changed state to up
*Apr  6 13:23:29.832: Se0/2/0 LCP: I CONFREQ [Closed] id 252 len 15
*Apr  6 13:23:29.832: Se0/2/0 LCP:    AuthProto MS-CHAP (0x0305C22380)
*Apr  6 13:23:29.832: Se0/2/0 LCP:    MagicNumber 0x18180FB4 (0x050618180FB4)
*Apr  6 13:23:29.832: Se0/2/0 LCP LCP: Missed a Link-Up transition, starting PPP
*Apr  6 13:23:29.832: Se0/2/0 PPP: Using default call direction
*Apr  6 13:23:29.836: Se0/2/0 PPP: Treating connection as a dedicated line
*Apr  6 13:23:29.836: Se0/2/0 PPP: Session handle[C500011F] Session id[474]
*Apr  6 13:23:29.836: Se0/2/0 PPP: Phase is ESTABLISHING, Active Open
*Apr  6 13:23:29.836: Se0/2/0 LCP: O CONFREQ [Closed] id 234 len 10
*Apr  6 13:23:29.836: Se0/2/0 LCP:    MagicNumber 0x19046115 (0x050619046115)
*Apr  6 13:23:29.836: Se0/2/0 LCP: O CONFACK [REQsent] id 252 len 15
*Apr  6 13:23:29.836: Se0/2/0 LCP:    AuthProto MS-CHAP (0x0305C22380)
*Apr  6 13:23:29.836: Se0/2/0 LCP:    MagicNumber 0x18180FB4 (0x050618180FB4)
*Apr  6 13:23:29.836: Se0/2/0 LCP: I CONFACK [ACKsent] id 234 len 10
*Apr  6 13:23:29.836: Se0/2/0 LCP:    MagicNumber 0x19046115 (0x050619046115)
*Apr  6 13:23:29.836: Se0/2/0 LCP: State is Open
*Apr  6 13:23:29.836: Se0/2/0 PPP: Phase is AUTHENTICATING, by the peer
*Apr  6 13:23:29.836: Se0/2/0 MS-CHAP: I CHALLENGE id 218 len 21 from "R2      "
*Apr  6 13:23:29.852: Se0/2/0 MS CHAP: Using hostname from unknown source
*Apr  6 13:23:29.852: Se0/2/0 MS CHAP: Using password from interface CHAP
*Apr  6 13:23:29.852: Se0/2/0 MS-CHAP: O RESPONSE id 218 len 56 from "R5"
*Apr  6 13:23:29.860: Se0/2/0 MS-CHAP: I SUCCESS id 218 len 4
*Apr  6 13:23:29.860: Se0/2/0 PPP: Phase is FORWARDING, Attempting Forward
*Apr  6 13:23:29.860: Se0/2/0 PPP: Queue CCP code[1] id[1]
*Apr  6 13:23:29.860: Se0/2/0 PPP: Discarded CDPCP code[1] id[1]
*Apr  6 13:23:29.860: Se0/2/0 PPP: Queue IPCP code[1] id[1]
*Apr  6 13:23:29.864: Se0/2/0 PPP: Phase is ESTABLISHING, Finish LCP
*Apr  6 13:23:29.864: Se0/2/0 PPP: Phase is UP
*Apr  6 13:23:29.864: Se0/2/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Apr  6 13:23:29.864: Se0/2/0 IPCP:    Address 25.25.25.5 (0x030619191905)
*Apr  6 13:23:29.864: Se0/2/0 CCP: O CONFREQ [Closed] id 1 len 10
*Apr  6 13:23:29.864: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.864: Se0/2/0 CDPCP: O CONFREQ [Closed] id 1 len 4
*Apr  6 13:23:29.864: Se0/2/0 PPP: Process pending ncp packets
*Apr  6 13:23:29.864: Se0/2/0 IPCP: Redirect packet to Se0/2/0
*Apr  6 13:23:29.864: Se0/2/0 IPCP: I CONFREQ [REQsent] id 1 len 10
*Apr  6 13:23:29.864: Se0/2/0 IPCP:    Address 25.25.25.2 (0x030619191902)
*Apr  6 13:23:29.868: Se0/2/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 IPCP:    Address 25.25.25.2 (0x030619191902)
*Apr  6 13:23:29.868: Se0/2/0 CCP: Redirect packet to Se0/2/0
*Apr  6 13:23:29.868: Se0/2/0 CCP: I CONFREQ [REQsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.868: Se0/2/0 CCP: O CONFACK [REQsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.868: Se0/2/0 CCP: I CONFACK [ACKsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.868: Se0/2/0 CCP: State is Open
*Apr  6 13:23:29.868: Se0/2/0 CDPCP: I CONFACK [REQsent] id 1 len 4
*Apr  6 13:23:29.868: Se0/2/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 IPCP:    Address 25.25.25.5 (0x030619191905)
*Apr  6 13:23:29.868: Se0/2/0 IPCP: State is Open
*Apr  6 13:23:29.872: Se0/2/0 IPCP: Install route to 25.25.25.2
*Apr  6 13:23:30.864: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2/0, changed state to up
*Apr  6 13:23:31.856: Se0/2/0 CDPCP: I CONFREQ [ACKrcvd] id 2 len 4
*Apr  6 13:23:31.856: Se0/2/0 CDPCP: O CONFACK [ACKrcvd] id 2 len 4
*Apr  6 13:23:31.856: Se0/2/0 CDPCP: State is Open
R5(config-if)#do no deb all

All possible debugging has been turned off

We can see from the above output exactly what we would expect — The LCP phase of PPP negotiation begins which moves us into authentication via MS-CHAP. We can see that R5 gets an inbound authentication request from R2. R5 responds appropriately with the MD5 hash and R2 lets us know the authentication was successful. After LCP and authentication we move into the NCP phase. During NCP, we can see that encryption is being negotiated via the CCP protocol. If encryption is successfully negotiated you will see that the CCP state goes to Open as it has here. So, let’s take a look at our link and test

R2#sh ip int brie | i 0/2/0
Serial0/2/0                25.25.25.2      YES manual up                    up

R2#ping 25.25.25.5 re 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 25.25.25.5, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms

R2#show ppp mppe serial0/2/0
Interface Serial0/2/0 (current connection)
Software encryption, 128 bit encryption, Stateless mode
packets encrypted = 100      packets decrypted  = 100
sent CCP resets   = 0        receive CCP resets = 0
next tx coherency = 100      next rx coherency  = 100
tx key changes    = 100      rx key changes     = 100
rx pkt dropped    = 0        rx out of order pkt= 0
rx missed packets = 0

We can see from the above output that we are indeed running 128-bit encryption and that all of our ping packets were encrypted! We can also see that the key seems to actually change every packet! That is about it for setting up basic MPPE on a Cisco router PPP link!!!

Joe Astorino CCIE #24347

Print Friendly

QoS Actions For Ingress Traffic

When traffic arrives on a switchport, there is a set of different QoS functions we have the ability to apply.
• Classification
• Policing
• Marking
• Queueing
• Scheduling

Most of these functions are specific for ingress traffic. A few of the options, namely queueing and scheduling, we can also do for egress traffic. One important thing to remember with the 3560 is that when we talk about queueing or scheduling, we could be talking about it from the perspective of inbound traffic (ingress) or outbound traffic (egress). The queueing and scheduling is very similar, but with ingress queueing we have two queues, whereas with egress queueing we have four. In both situations, one queue can be configured as a strict priority queue. In this article we will take a look at Classification, Policing and Marking. Additionally, we will look at egress Queueing and Scheduling.

Classification

The entire point of QoS is to give prefferential treatment to some packets that are deemed “more important” than other packets during times of congestion. If we want to do that, we need a way to figure out what packets are more important. That is the basis of classification. There are multiple different ways to do classification on the 3560, depending on what type of environment you are working in and what it is you are trying to accomplish. We may classify traffic at the interface level through a variety of methods we will discuss below, or at the VLAN level. If you choose to do classification at the VLAN level you will need the mls qos vlan-based command on interfaces that are part of the VLAN you want to do classification on. If we are talking about non-IP traffic we can classify based on trusting the incoming CoS values or based on MAC ACLs. Recall that CoS is a layer 2 thing, so it makes sense that we can classify non-IP traffic with CoS. CoS bits get set in the L2 header, and really have nothing to do with IP. With IP traffic however, we can classify based on trusting incoming CoS, DSCP, IP Precendence values or with L3 ACLs. This also makes sense if you recall that DSCP and IP Precedence are marked in the ToS byte of the IP header. If you attempt to trust DSCP or IP Precendence for non IP traffic, one of two things will happen: If the frame has a CoS value, it will be retained. If not, the default port CoS value will be used. If you choose to classify with ACLs instead of trusting QoS markings, ultimately you will be configuring an ACL, calling the ACL in a class-map, and calling the class-map from a policy-map which you will apply to the interface. You can also configure VLAN based classification by applying a policy-map that does classification and marking to an SVI. Generally speaking, if you choose to not trust anything, and you don’t have any ACLs configured, things will be marked down to best-effort. If a packet is unmarked when it arrives, it will be assigned the default CoS value assigned to the interface, which is 0. This of course, is something we can change with the mls qos cos command.

Understanding trust states as well as the internal mapping table logic of your 3560 switch is probably one of the most important things to know about. It is also one of the most important things to know how to manipulate.

First of all, in order to turn on QoS processing on the switch, we need to enable it with the mls qos command. Secondly, we need to understand our options. As stated previously, you can configure your switch ports to trust certain QoS markings, or not trust QoS markings. By default, nothing is trusted. To trust the markings you will use a variant of the mls qos trust command as shown below. The device option gives us the ability to essentially say “ONLY trust the incoming QoS markings IF the device connected to this port is a Cisco phone.” This allows us to trust an IP phone’s QoS markings for voice packets while also protecting against a user unplugging his PC from the phone and running his cable directly into the switch and getting priority treatment of all packets.

3560(config)#mls qos
3560(config)#int fa0/1
3560(config-if)#mls qos trust ?
cos            cos keyword
device         trusted device class
dscp           dscp keyword
ip-precedence  ip-precedence keyword

So far we have seen that when a frame arrives at the switch port we can either trust the markings or not trust the markings. If we don’t trust the markings or if there is no marking we will get a CoS value of 0 by default. However, if we DO decide to trust the markings, we move on to the next step — mappings. You see, the 3560 has a variety of internal mapping tables that decide what the final markings are going to be, which are based on the incoming markings. For example, we have CoS-To-DSCP,and DSCP-To-CoS among others. The idea is that when a frame comes in, the switch can look at the incoming QoS markings, and from those incoming markings derive a new QoS marking which will ultimately determine how that traffic gets queued. Let’s have a look at some examples.

3560#sh mls qos maps ?
cos-dscp       cos-dscp map keyword
cos-input-q    cos-input queue map keyword
cos-output-q   cos-output queue map keyword
dscp-cos       dscp-cos map keyword
dscp-input-q   dscp-input queue  map keyword
dscp-mutation  dscp-mutation map keyword
dscp-output-q  dscp-output queue map keyword
ip-prec-dscp   ip-prec-dscp map keyword
policed-dscp   policed-dscp map keyword
|              Output modifiers

3560#sh mls qos maps cos-dscp
Cos-dscp map:
cos:   0  1  2  3  4  5  6  7
--------------------------------
dscp:   0  8 16 24 32 40 48 56

3560#sh mls qos maps dscp-cos
Dscp-cos map:
d1 :  d2 0  1  2  3  4  5  6  7  8  9
---------------------------------------
0 :    00 00 00 00 00 00 00 00 01 01
1 :    01 01 01 01 01 01 02 02 02 02
2 :    02 02 02 02 03 03 03 03 03 03
3 :    03 03 04 04 04 04 04 04 04 04
4 :    05 05 05 05 05 05 05 05 06 06
5 :    06 06 06 06 06 06 07 07 07 07
6 :    07 07 07 07

3560#sh mls qos maps cos-output-q
Cos-outputq-threshold map:
cos:  0   1   2   3   4   5   6   7
------------------------------------
queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1

In the examples above we are looking at three different tables: Cos-To-DSCP and DSCP-To-Cos as well as the CoS to output queue mapping. The idea is this — A frame comes in with some QoS marking (Let’s call it CoS for now) that we happen to trust on the port. The switch then looks at the CoS-To-DSCP mapping and derives a DSCP value to give to the packet. The switch then consults the DSCP-To-CoS map to derive a new CoS value. Finally, based on that CoS value, it chooses an output queue. For example, we can see that CoS 2 gets marked with DSCP 16 and that DSCP 16 gets marked with CoS 2. Let’s say we are trusting CoS and a frame comes in with a CoS of 3. We see that the CoS-To-DSCP map will map CoS 3 to DSCP 24. The DSCP-To-CoS map is then consulted, and we see the CoS value will end up remaining at 3. Finally, we see that CoS 3 gets mapped to output queue #3 with a drop threshold of 1. Keep in mind that this is one particular example of one particular function. If we decided to trust DSCP or IPP instead of CoS, we would consult different tables but the general idea is the same. If we are trusting DSCP instead of CoS on the interface, we can let that DSCP value remain intact and pass through, or we can change it with a DSCP mutation map.

Understanding this process is important for a CCIE candidate. What is equally as important is to know how to modify these default mappings. The key thing to remember is “mls qos map”. From there you can do mostly anything. Let’s go back to our example. Let’s say we are trusting CoS and we want to make sure that incoming frames marked as CoS 3 get mapped to DSCP 28 instead of DSCP 24.

3560(config)#mls qos map cos-dscp ?
  CoS values separated by spaces (up to 8 values total)

3560(config)#mls qos map cos-dscp 0 8 16 28 32 40 48 56
3560(config)#do sh mls qos map cos-dscp
Cos-dscp map:
cos:   0  1  2  3  4  5  6  7
--------------------------------
dscp:   0  8 16 28 32 40 48 56

Now suppose that we need to make sure DSCP 28 gets marked back to CoS 5 so that it is sent to priority queue #1 outbound.

3560(config)#mls qos map dscp-cos ?
     DSCP values separated by spaces (up to 8 values total)

3560(config)#mls qos map dscp-cos 28 ?
     DSCP values separated by spaces (up to 8 values total)
    to      to keyword

3560(config)#mls qos map dscp-cos 28 to ?
     cos value
3560(config)#mls qos map dscp-cos 28 to 5
3560(config)#do sh mls qos map dscp-cos
Dscp-cos map:
d1 :  d2 0  1  2  3  4  5  6  7  8  9
---------------------------------------
0 :    00 00 00 00 00 00 00 00 01 01
1 :    01 01 01 01 01 01 02 02 02 02
2 :    02 02 02 02 03 03 03 03 05 03
3 :    03 03 04 04 04 04 04 04 04 04
4 :    05 05 05 05 05 05 05 05 06 06
5 :    06 06 06 06 06 06 07 07 07 07
6 :    07 07 07 07

If you wish to modify the default CoS/DSCP to output queue mappings you can use the mls qos srr-queue output command.

Policing And Marking

After arriving traffic has been classified, things can move on to the next step if necessary, which is policing and marking. Policing, much like on routers, is for rate-limiting the bandwidth of a particular type of traffic. On the 3560 switch, we can police on an individual interface, or even on an SVI by using hierarchical policies. When we police traffic, we set bandwidth limits on that traffic, and decide what to do about it if things are misbehaving. Namely, we can pass the traffic, drop the traffic, or mark down the QoS markings of the packets. This is all decided on a per-packet basis. After being policed, and potentially marked down THEN we can move into queueing.

One thing to understand about policing on the 3560 switch, is that it works a bit differently than other types of policing or shaping you may be familiar with. Particuarly, people seem to get hung up on why everything they learned about with regards to frame-relay traffic-shaping or shaping in general no longer applies here. Well, for one thing we are talking about policing traffic and not shaping it. Shaping implies some sort of queueing in order to shape the traffic to a given rate over time. Policing on the other hand does not queue traffic. The old well known formula for FRTS Tc = Bc/CIR is not really appropriate for policing on a 3560 switch. The policing IS done using a token bucket type algorithm, but it is much different than the token bucket algorithm used for FRTS. With FRTS things are based on how much data you can send per time slice (Tc). With 3560 policing there is really no concept of hard set time slices. The amount of data you can send at any given moment is more determined by time and the configured policed rate / burst size than anything else. Letting formulas used for traffic-shaping confuse you when doing policing is like comparing apples and oranges. If you don’t allow yourself to confuse the two different but similar technologies, you should be OK.

Policing Physical Ports

Once you decide to police a physical port as opposed to an SVI, you stil have options : ) You can police an individual port based on a policy linked to a single class of traffic, or you can police an individual port based on a policy that is linked to multiple classes (aggregate policer.) The individual port policer is pretty simple. The aggregate policer just allows you to police a SET of classes all together. For example, you can configure multiple class-maps and police the rate of the sum of all the class maps to a certain rate. Let’s have a look at the syntax for the policer on a 3560 switch. This is something you would apply inside a policy-map.

police rate-bps burst-byte [exceed-action {drop | policed-dscp-transmit}]

The rate specified in bits per second tells us what the average rate is that we wish to police to. This is not necessarily a hard limit because we also have the ability to configure a burst size. The burst size allows the policed traffic to temporarily burst above and beyond the average rate. Keep in mind that the average rate is in terms of bits per second while the burst is in bytes. Notice I didn’t say bytes per second. The burst value specified is essentially defining how DEEP the token bucket is. It has nothing to do with how many bits or bytes PER anything. It is simply the size of the bucket in bytes. This parameter works in conjunction with how fast the bucket leaks (the policed rate) to determine if a packet comforms or does not conform. If the traffic conforms, it is transmitted. If the packet does not conform, we can either drop it or mark down the QoS based on the policed-dscp map. Many people learning this technology tend to get hung up on what values to use for burst. Part of this stems from the idea that when we conigure policing on a router using CAR, we are often told to use the formula Bc = [(CIR / 8) * 1.5] for the Bc burst value (as we are told in the command reference as recommended values). There is no such recommendation for burst values on the 3560. In short, do what you are told in the lab. If you are not given a burst value, I would not recommend you stress too much about what values to put here.

Let’s look at an example of a typical port-based policer on the 3560. Let’s say we want to police FTP traffic on port 19 to an average rate of 20Mbps with a burst of 10KB. We would configure something like this:

ip access-list extended FTP-TRAFFIC
permit tcp any any range ftp-data ftp
!
class-map match-all FTP-TRAFFIC
match access-group name FTP-TRAFFIC
!
policy-map POLICE-FTP
class FTP-TRAFFIC
police 20000000 10000 exceed-action drop
!
interface FastEthernet0/19
service-policy input POLICE-FTP

Now, let’s take a look at an aggregate policer. The idea here is this — We have a policy-map that will match multiple classes of traffic. If the rate of all the classes COMBINED goes over a certain level, we do something about that. In this case, let’s say we are matching HTTP, Telnet, and SSH traffic and we don’t want all that traffic combined to exceed 10 Mb/s with a burst of 50KB on interface fa0/1

mls qos aggregate-police WEB-TELNET-SSH 10000000 50000 exceed-action drop
!
ip access-list extended HTTP-TRAFFIC
permit tcp any any eq 80
!
ip access-list extended TELNET-TRAFFIC
permit tcp any any eq 23
!
ip access-list extended SSH-TRAFFIC
permit tcp any any eq 22
!
!
class-map HTTP
match access-group HTTP-TRAFFIC
!
class-map TELNET
match access-group TELNET-TRAFFIC
!
class-map SSH
match access-group SSH-TRAFFIC
!
!
policy-map AGGREGATE-POLICER
class HTTP
police aggregate WEB-TELNET-SSH
!
class TELNET
police aggregate WEB-TELNET-SSH
!
class SSH
police aggregate WEB-TELNET-SSH
!
!
interface FastEthernet0/1
service-policy input AGGREGATE-POLICER

Policing On SVIs

Policing at the SVI level can be a little more confusing at first. The reason it is more confusing is because it requires hierarchical policies. You cannot apply a policy-map that does policing directly to an SVI. This is similar to how you cannot apply queueing on a router to an ethernet sub-interface. You must configure a more general VLAN based “parent” policy and then call your more specific interface based “child” policy from inside the parent VLAN policy. For example, let’s say we want to police HTTP traffic inbound to VLAN 80 to 1Mb with a 20KB burst size. The interfaces in VLAN 80 we want to apply this to are Fa0/1 – Fa0/5. It would look something like this

! Apply VLAN-Based QoS to participating ports
!
interface range FastEthernet0/1 - 5
mls qos vlan-based
!
ip access-list extended HTTP
permit tcp any any eq 80
permit tcp any eq 80 any
!
class-map HTTP
match access-group name HTTP
!
class-map POLICED-PORTS
match interface FastEthernet 0/1 - FastEthernet 0/5
!
! Child policy to police the interfaces of VLAN 80
!
policy-map INTERFACE-POLICY
class POLICED-PORTS
police 1000000 20000
!
! Parent policy to apply to VLAN 80 in general
!
policy-map VLAN-POLICY
class HTTP
service-policy INTERFACE-POLICY
!
interface vlan 80
service-policy input VLAN-POLICY

Marking

The good news is that at this point, marking has really already been discussed. Marking can be done in a few ways. We have already seen how traffic can be marked through the classification process. If we trust markings on the port then incoming marked traffic can be re-marked either through the internal switch mappings, passed through in the case of DSCP, or remarked through a policy. If we don’t trust markings, we can still re-mark the traffic with a policy, or allow it to be marked down as best effort. If the traffic is not marked in the first place, we can choose to mark it ourselves, or assign it the default interface CoS.

Queueing And Scheduling

As I mentioned earlier, the 3560 has two input queues per interface with queue 2 being the default priority queue. The 3560 also has four output queues per interface, with queue 1 being the priority queue. The priority queue is not something that happens automagically, and must be enabled. To enable the input prioriity queue you will use the global command mls qos srr-queue input priority-queue. To enable the output priority queue you will use the interface level command priority-queue out.

When we are talking about Queueing on the 3560 there is a concept known as WTD or weighted tail drop that applies to both input and output queues. To put it simply, each queue has three different drop thresholds that correspond to different CoS values. Frames that are “less important” than others can be configured to be dropped at lower levels of congestion than “more important” frames. For example, maybe CoS values 5,6 and 7 are considered very important in your network, but CoS 1-4 are less important. Your WTD configuration would probably have CoS 1-4 mapped to the thresholds that get dropped sooner than CoS 5-7. Maybe CoS 1-4 gets dropped at 60% congestion, whereas CoS 5-7 only gets dropped when it absolutely HAS to at 100% congestion. In the grand scheme of things for routing and switching I would say understand the basic concept and know where to find the information if you have to.

Now, when we talk about how the queues actually get serviced and how much they get serviced (who gets better treatment by getting more attention), we are getting into SRR or shaped round robin. This happens again for both input and output queues. We will focus on egress queueing here. As usual, there are multiple options. Namely, we have shaped mode and shared mode. In short, with shaped mode each queue is guaranteed a certain amount of bandwidth, but also policed to that level. If the other queues are not filled, the extra bandwidth is not utilized. With shared mode as the name implies, the bandwidth among the queues is shared according to configured weights, but is not policed. There is a significant difference in understanding the syntax between the two modes.

With shaped mode we have the following interface command:

srr-queue bandwidth shape

In this case the weight values are talking about a specific amount of bandwidth guaranteed for that queue. Weight 1 is for queue 1, weight 2 for queue 2 , etc…The numbers that you enter are the denominator portion of a fraction. For example:

srr-queue bandwidth shape 4 4 4 4
srr-queue bandwidth shape 8 0 0 0

First of all, these are two different examples. In the first line, we are saying “each queue will get 1/4 of the bandwidth of this interface guaranteed.” In the second example, we are saying “Queue 1 will get 1/8 of the bandwidth guaranteed, and all other queues operate in shared mode”. When we use the 0 for the other three queues we tell them to operate in shared mode. So in the case of the second example, queues 2-4 would shared the remaining 87.5% equally.

With shared mode we have the following command:

srr-queue bandwidth share

In the case of shared mode, the numbers have different meanings. Now we are looking at a ratio or how the queues relate to each other. The values themselves have no real meaning. The only thing that matters in shared mode is the ratio of the queues. For example, the following three lines accomplish the exact same thing — They each would allocate 25% of the interface bandwidth to each queue because the ratio between the queues is 1:1.

srr-queue bandwidth share 1 1 1 1
srr-queue bandwidth share 25 25 25 25
srr-queue bandwidth share 100 100 100 100

Let’s try something a bit diferent:

srr-queue bandwidth share 10 20 30 40

With the last example, queue 4 gets 4x as much bandwidth as queue 1 because it has a ratio of 4:1 with queue 1. Queue 4 gets twice as much bandwidth as queue 2, and 1 1/3x bandwidth as queue 3.

Hopefully, this article has been of help to everbody out there learning QoS on the Catalyst 3560. I hope that his has given you some valuable insite into the many different options and capabilities of this switch. As you can see, the 3560 is a very powerful device! As always, I would highly recommend and encourage you guys to do more research, labbing and reading on your own to master this topic. The place to go is the 3560 software configuration guide on the DocCD which you can find here:

http://www.cisco.com/en/US/products/hw/switches/ps5528/products_installation_and_configuration_guides_list.html

Best regards and keep studying hard!!!
Joe Astorino – CCIE #24347

Print Friendly

All our vLecture sessions are recorded and available for those who have missed our FREE vLecture and for participants who want to review the vLectures sessions again. We have saved the session recordings for you. Watch our world renowned CCIE instructors explaining specific technical topic in our technology-focused classes and capture the technical knowledge needed to increase your chances of passing CCIE exam.

CCIE Service Provider

• Instructor: Tyson Scott
• Topic:  BGP Path Selection and BGP Filtering
• Link: http://ipexpert.acrobat.com/p84746461/

CCIE Security

• Instructor: Tyson Scott
• Topic: NAC Framework
• Link: http://ipexpert.acrobat.com/p25784815/

CCIE Routing & Switching

• Instructor: Marko Milivojevic
• Topic:  How I passed CCIE R&S v4.0
• Link: http://ipexpert.acrobat.com/p74866708/

• Instructor: Joe Astorino
• Topic: IPv6 Protocol and Routing
• Link: http://ipexpert.acrobat.com/p13872226/

Do not miss our vLectures scheduled for the coming weeks. If you’re an IPexpert client and wish to join these sessions, please be sure to reserve a “virtual seat” now, these have been highly anticipated and we’re quite confident that these online training seats will fill up quickly.

Print Friendly

Unfortunately, sometimes people neglect the information in the structured learning approach and dive in wherever they can. Oftentimes, this can be more detrimental to your success than it is helpful. Over the last 10+ years, we have developed a system that works in developing prepared CCIE candidates. When you stray from the system that is proven to work, you are taking a gamble. Some might argue that the CCIE is about thinking outside the box, and I would agree with them. However, why force yourself “against the grain” and make your journey to the holy digits harder than it has to be? We have already done all that hard work for you. Think of the structured learning approach as part of the reason you pay for the services of a company like IPexpert in the first place. Experience is important for a reason. This blog is going to focus on how you as an IPexpert student can fully utilize our program and get on the right path to becoming a CCIE.

Becoming a CCIE through the mentoring, concepts and approach of IPexpert is a very structured process that requires you as a student to fully understand to be successful. Follow the path, and you have a great shot at joining the ranks of the networking industry elite. Stray from the path, and you could be banging your head against the wall for years before you eventually pass, or just plain give up out of frustration. What I want to do is explain to you guys how to avoid the frustration by following our proven structured learning approach.

Step 1: Understand Advanced Theory & Concepts (After Passing The Written)

This is definitely one of the most important steps in your overall success. All too often, people pass the written examination and bang…they are off to dive into complex, multiprotocol mock labs. “If I do 25 mock labs I should be OK” people say. Another common mistake is to think “I passed the written, I must know the technology…I don’t need any more book theory.” Nothing could be further from the truth. The CCIE written exam and the CCIE lab exam are totally different beasts. In the IPexpert structured learning approach, the core knowledge, theory and concepts will come in the form of our industry leading CCIE R&S Video on Demand course. With the video on demand, you are going to come along with me, CCIE #24347 and go DEEP with technology. Through over 45 hours of lecture mixed with real hands on CCIE level configuration scenarios you are not only going to cement the core knowledge you learned for the written exam, but you are going to actually get your hands dirty as well through configurations. You really cannot expect yourself to jump into configuring labs without having a solid foundation. We don’t believe in building on a weak foundation. This is one of the biggest mistakes people make. Don’t cheat yourself — Start your preparation off right with the video on demand.

Step 2: Begin Technology-Focused, Targeted Learning

Once you have the core theory and concepts down, you need to start actually applying that knowledge. At this point, you already have seen CCIE level scenarios from the video on demand, but now you will go a step further and be doing it yourself. The *most* important part about this step, is that the labs are specific to individual technologies. In other words, you will do a lab on each individual technology by itself. No mixing and matching. Why is this so important? You cannot be expected to figure out how 25 different things are working together in a complex environment if you do not already understand each individual piece. This is how you get the advanced knowledge necessary to do that.

The ideal piece of the puzzle for you at this point is the IPexpert’s CCIE R&S Workbook Volume 1 technology focused workbook mixed together with the IPexpert’s CCIE R&S Volume 1 Walk-Through Video Tutorials. Fortunately, if you purchase the IPexpert’s CCIE R&S Blended Learning Solution, you get both those products. IPexpert’s CCIE R&S 4.0 Volume 1 Workbook will take you through 34 technology specific labs and the accompanying Detailed Solution Guide. If that is still not enough, watch as I take you right through the configurations and thought process in the IPexpert CCIE R&S Volume 1 Walk-Through Video Tutorial. At this point you have core theory down, and once you complete volume 1 you will have the knowledge necessary to continue. Do not cheat yourself by skipping volume 1 because you have extensive experience in the industry. The CCIE lab has nothing to do with best practices in the industry. The CCIE lab, the environment, and the structure of the questions are unlike anything you have probably done before. This will help prepare you for that.

Step 3: Reinforce Theory & Advanced Knowledge

Once you have the fundamental knowledge down, and you have gotten through the challenging volume 1 labs, it is time to move on to the IPexpert CCIE R&S Audio on Demand lecture series. This is a brand new product unlike anything else available in the industry today. For one, it is a completely different course than the video on demand. Secondly, it was designed purposely to cover different aspects, angles, scenarios, and extra “tips and tricks” for the CCIE candidate. Some of the stuff in the audio on demand series, you will not find in any vendor workbook, video or textbook because some things you just pick up from experience. Fortunately, we’ve taken all that expertise and experience and put it into audio format you can take with you anywhere. Finally, the audio on demand is coming at you from the perspective of a dual CCIE that has actually passed the newest v4.0 blueprint himself! Listen as Marko Milivojevic (CCIE #18427) takes you through each and every blueprint topic, with a focus on some specifics not considered core theory and knowledge as well as more “tips and tricks” to success. These audio lectures are directly downloadable from your members account, and available as part of the CCIE R&S Blended Learning Solution!

Step 4: Begin Multiprotocol Exercises

As I said earlier, many people feel they need to start at step #4. These are often the people that come back for 2nd, 3rd, 4th, and 5th attempts at the lab : ) The reason is simple — they didn’t follow the path. When you stray from the proven path to success, you will inevitably run into struggles. This is really not designed to be a sales letter, but really — There is a reason the program has worked for 10 years. There is a reason we have trained more CCIEs than anybody in the world. Stick to the plan!

Now, IPexpert’s CCIE R&S 4.0 Volume 2 Workbook with Detailed Solution Guide multi-protocol labs are where we get to the real meat and potatoes of becoming prepared to take the lab exam. These are CCIE level, full mock labs that will challenge you with all the different technologies and protocols you learned about in volume 1, but now all stuck together in one big nasty lab environment, just like the real deal. : ) This is where you will really cut your teeth and gain invaluable real world experience, which is probably the most important piece of becoming a CCIE. You cannot pass the CCIE by reading books alone. You must get in there and get your hands dirty. IPexpert’s CCIE R&S 4.0 Volume 2 workbook is where that is going to happen for you.

If you need equipment, my recommendation is to utilize our racks. Check out proctorlabs.com and you will not be disappointed. If you want to build your own rack, by all means do it. Just realize, you will spend a LOT of time, energy, and money guaranteed. The reason is that you will have to put together a topology that mimics the topology of the labs you are working on. To put together an exact replica of our lab is doable; it is just tedious and expensive. In addition, if all your interface numbers don’t match exactly, you end up having to modify startup-configurations for every lab which wasted about 30 minutes of your time every single lab. When I studied for my CCIE, I built my own rack. It was great to have, but in retrospect I spent way more $$$, invested way more time, and spent much too long modifying configs than it was worth. Once you complete the volume 2 and volume 3 workbooks you are getting very, very close to being prepared.

Step 5: Reinforce Advanced Knowledge

Once you are in the position where you think you are ready for the exam, you need to take it one step further. When you go through something as technical and lengthy as CCIE prep, and you do it all “on demand” and through self study, inevitably some things are going to happen. You forget things. Secondly, you have questions. While we do our best to deliver the best possible training experience, it is impossible to anticipate every single answer to every person’s questions through video and audio. Additionally, you want to reinforce and validate that the knowledge you have floating around up in your head is actually correct, and that you are ready to rock the lab. Step 5 is to attend one of IPexpert’s industry leading CCIE R&S 5 day ILT boot camps. These IPexpert boot camps are intense, 5 day courses designed to do exactly what I have just said. My boot camps usually have you putting in 60-80 hours of hardcore CCIE preparation within a 5 day period. We cover every technology on the blueprint from a lecture standpoint, as well as challenge you with more hands on lab work. With the lecture in a live environment, you obviously have the ability to ask many more specific questions, and to fill in gaps in your knowledge base. The ILT is designed to be all about filling in holes, one on one time with a world class CCIE instructor, and more hands on practice.

Let me tell you a little bit about what the ILT is not about. The reason I write about this is because this is hands down the biggest mistake our clients make!!!!! I teach a lot of boot camps and a large percentage of people we see coming to ILT have absolutely no previous experience doing CCIE level labs. They have no experience doing technology specific labs. They have no idea what our video on demand is. In other words, they are starting their preparation by coming to the ILT — at step #5 in the process. The vast majority of people that make the choice to skip steps 1 – 4 in the proven time tested approach are the ones that typically are lost during class, and do not get out of the class what it is designed to give them. They have no chance of completing their boot camp lab work because they do not have the prerequisite skills necessary to do so.

Remember, when you come to ILT we expect that you have followed steps 1-4. When you choose to ignore the first four steps, you are really doing yourself a disservice. Please, do the video on demand, do your volume 1, do your volume 2 mock labs, put in your blood sweat and tears and THEN come and see us so we can answer the questions that came up through all of it and make you BETTER.

Step 6: Polish Advanced Knowledge & Troubleshooting Skills

Everything you have done so far builds up to this point — the IPexpert CCIE R&S 4.0 Volume 3 mock lab workbook with Detailed Solution Guide. This is the most comprehensive, advanced and challenging mock lab workbook we offer. The nice thing about volume 3 is that it is has been redesigned from the ground up to cover you guys for CCIE R&S v4.0. That means our current team went through and personally took care of volume 3 to make sure it is the most current, up to date, and relevant material you need to pass. The exam structure is also taken directly from Cisco — 2 hour troubleshooting section followed by 6 hours of configuration on a separate topology! Our mock labs are designed to be harder than the real lab. The volume 3 labs are going to take all that fundamental core knowledge you learned in the IPexpert’s Video On Demand (VoD) and IPexpert’s Audio On Demand (AoD), the experience and knowledge you gained from the volume 1 and volume 2 labs, the information you took out of the ILT and put it all together to challenge you in a way that is going to prepare you to sit the real lab. Additionally, much like volume 1 you have the opportunity to watch an instructor do the lab via the IPexpert CCIE R&S Volume 3 Walk-Through Video Tutorial. Yes, you can watch as I or Marko painstakingly take you through FULL mock labs one single task at a time.  This includes the troubleshooting section as well as the configuration section! This is also part of of the blended learning solution!

Step 7: Practice Taking The REAL Lab

Finally, step 7 is going to be the IPexpert CCIE R&S One-Week-Lab Experience Boot Camp. Before you decide to come to OWLE, please understand what it is designed to do. This is the LAST step in your process before going to face the rigorous CCIE lab exam! This course is NOT designed for you until you have completed all the prerequisite material.

The worst experience for you will be coming to an OWLE and having to leave the class, or be so far buried that you get nothing out of it because you lack the understanding and speed to do anything useful. You build understanding, speed and efficiency through Steps 1 – 6 of course. The OWLE is designed to put everything to the test in a one week experience that has you doing a CCIE like mock lab all day, all week long mixed with feedback, questions, and one on one time with a real CCIE. You will put all your knowledge to the test and see if you are truly ready to sit the CCIE lab exam.

Our OWLE mock labs are going to put you in an environment similar to the real lab. You will have 2 hours of troubleshooting, 6 hours of configuration, and we will treat you as you would be treated taking the real test. That means your instructor is not there to white board and teach while you take the lab. The instructor is not there to hold your hand and baby you through the steps — That has already been accomplished in steps 1 – 6 : ) The instructor will be there to act as a proctor, and to answer questions as a proctor would do so.

Now, with that being said there is also time allotted for re-learning, cementing concepts, and getting last minute help, tips and instruction before your big day. That is also part of the OWLE as a whole. If you can get to step 7 and you can do fairly well on our OWLE labs (which are also designed to be much harder than the real thing) we at IPexpert feel that you have a great chance of passing your lab and becoming a CCIE!

Joe Astorino – CCIE #24347

Sr. Technical Instructor – IPexpert

Print Friendly