| 1.00 | Implement Layer 2 Technologies | √ |
| 1.10 | Implement Spanning Tree Protocol (STP) | |
| (a) 802.1d | ||
| (b) 802.1w | ||
| (c) 801.1s | ||
| (d) Loop guard | ||
| (e) Root guard | ||
| (f) Bridge protocol data unit (BPDU) guard | ||
| (g) Storm control | ||
| (h) Unicast flooding | ||
| (i) Port roles, failure propagation, and loop guard operation | ||
| 1.20 | Implement VLAN and VLAN Trunking Protocol (VTP) | |
| 1.30 | Implement trunk and trunk protocols, EtherChannel, and load-balance | |
| 1.40 | Implement Ethernet technologies | |
| (a) Speed and duplex | ||
| (b) Ethernet, Fast Ethernet, and Gigabit Ethernet | ||
| (c) PPP over Ethernet (PPPoE) | ||
| 1.50 | Implement Switched Port Analyzer (SPAN), Remote Switched Port Analyzer (RSPAN), and flow control | |
| 1.60 | Implement Frame Relay | |
| (a) Local Management Interface (LMI) | ||
| (b) Traffic shaping | ||
| (c) Full mesh | ||
| (d) Hub and spoke | ||
| (e) Discard eligible (DE) | ||
| 1.70 | Implement High-Level Data Link Control (HDLC) and PPP | |
| 2.00 | Implement IPv4 | |
| 2.10 | Implement IP version 4 (IPv4) addressing, subnetting, and variable-length subnet masking (VLSM) | |
| 2.20 | Implement IPv4 tunneling and Generic Routing Encapsulation (GRE) | |
| 2.30 | Implement IPv4 RIP version 2 (RIPv2) | |
| 2.40 | Implement IPv4 Open Shortest Path First (OSPF) | |
| (a) Standard OSPF areas | ||
| (b) Stub area | ||
| (c) Totally stubby area | ||
| (d) Not-so-stubby-area (NSSA) | ||
| (e) Totally NSSA | ||
| (f) Link-state advertisement (LSA) types | ||
| (g) Adjacency on a point-to-point and on a multi-access network | ||
| (h) OSPF graceful restart | ||
| 2.50 | Implement IPv4 Enhanced Interior Gateway Routing Protocol (EIGRP) | |
| (a) Best path | ||
| (b) Loop-free paths | ||
| (c) EIGRP operations when alternate loop-free paths are available, and when they are not available | ||
| (d) EIGRP queries | ||
| (e) Manual summarization and autosummarization | ||
| (f) EIGRP stubs | ||
| 2.60 | Implement IPv4 Border Gateway Protocol (BGP) | |
| (a) Next hop | ||
| (b) Peering | ||
| (c) Internal Border Gateway Protocol (IBGP) and External Border Gateway Protocol (EBGP) | ||
| 2.70 | Implement policy routing | |
| 2.80 | Implement Performance Routing (PfR) and Cisco Optimized Edge Routing (OER) | |
| 2.90 | Implement filtering, route redistribution, summarization, synchronization, attributes, and other advanced features | |
| 3.00 | Implement IPv6 | |
| 3.10 | Implement IP version 6 (IPv6) addressing and different addressing types | |
| 3.20 | Implement IPv6 neighbor discovery | |
| 3.30 | Implement basic IPv6 functionality protocols | |
| 3.40 | Implement tunneling techniques | |
| 3.50 | Implement OSPF version 3 (OSPFv3) | |
| 3.60 | Implement EIGRP version 6 (EIGRPv6) | |
| 3.70 | Implement filtering and route redistribution | |
| 4.00 | Implement MPLS Layer 3 VPNs | |
| 4.10 | Implement Multiprotocol Label Switching (MPLS) | |
| 4.20 | Implement Layer 3 virtual private networks (VPNs) on provider edge (PE), provider (P), and customer edge (CE) routers | |
| 4.30 | Implement virtual routing and forwarding (VRF) and Multi-VRF Customer Edge (VRF-Lite) | |
| 5.00 | Implement IP Multicast | |
| 5.10 | Implement Protocol Independent Multicast (PIM) sparse mode | |
| 5.20 | Implement Multicast Source Discovery Protocol (MSDP) | |
| 5.30 | Implement interdomain multicast routing | |
| 5.40 | Implement PIM Auto-Rendezvous Point (Auto-RP), unicast rendezvous point (RP), and bootstrap router (BSR) | |
| 5.50 | Implement multicast tools, features, and source-specific multicast | |
| 5.60 | Implement IPv6 multicast, PIM, and related multicast protocols, such as Multicast Listener Discovery (MLD) | |
| 6.00 | Implement Network Security | |
| 6.01 | Implement access lists | |
| 6.02 | Implement Zone Based Firewall | |
| 6.03 | Implement Unicast Reverse Path Forwarding (uRPF) | |
| 6.04 | Implement IP Source Guard | |
| 6.05 | Implement authentication, authorization, and accounting (AAA) (configuring the AAA server is not required, only the client-side (IOS) is configured) | |
| 6.06 | Implement Control Plane Policing (CoPP) | |
| 6.07 | Implement Cisco IOS Firewall | |
| 6.08 | Implement Cisco IOS Intrusion Prevention System (IPS) | |
| 6.09 | Implement Secure Shell (SSH) | |
| 6.10 | Implement 802.1x | |
| 6.11 | Implement NAT | |
| 6.12 | Implement routing protocol authentication | |
| 6.13 | Implement device access control | |
| 6.14 | Implement security features | |
| 7.00 | Implement Network Services | |
| 7.10 | Implement Hot Standby Router Protocol (HSRP) | |
| 7.20 | Implement Gateway Load Balancing Protocol (GLBP) | |
| 7.30 | Implement Virtual Router Redundancy Protocol (VRRP) | |
| 7.40 | Implement Network Time Protocol (NTP) | |
| 7.50 | Implement DHCP | |
| 7.60 | Implement Web Cache Communication Protocol (WCCP) | |
| 8.00 | Implement Quality of Service (QoS) | |
| 8.10 | Implement Modular QoS CLI (MQC) | |
| (a) Network-Based Application Recognition (NBAR) | ||
| (b) Class-based weighted fair queuing (CBWFQ), modified deficit round robin (MDRR), and low latency queuing (LLQ) | ||
| (c) Classification | ||
| (d) Policing | ||
| (e) Shaping | ||
| (f) Marking | ||
| (g) Weighted random early detection (WRED) and random early detection (RED) | ||
| (h) Compression | ||
| 8.20 | Implement Layer 2 QoS: weighted round robin (WRR), shaped round robin (SRR), and policies | |
| 8.30 | Implement link fragmentation and interleaving (LFI) for Frame Relay | |
| 8.40 | Implement generic traffic shaping | |
| 8.50 | Implement Resource Reservation Protocol (RSVP) | |
| 8.60 | Implement Cisco AutoQoS | |
| 9.00 | Troubleshoot a Network | |
| 9.10 | Troubleshoot complex Layer 2 network issues | |
| 9.20 | Troubleshoot complex Layer 3 network issues | |
| 9.30 | Troubleshoot a network in response to application problems | |
| 9.40 | Troubleshoot network services | |
| 9.50 | Troubleshoot network security | |
| 10.00 | Optimize the Network | |
| 10.01 | Implement syslog and local logging | |
| 10.02 | Implement IP Service Level Agreement SLA | |
| 10.03 | Implement NetFlow | |
| 10.04 | Implement SPAN, RSPAN, and router IP traffic export (RITE) | |
| 10.05 | Implement Simple Network Management Protocol (SNMP) | |
| 10.06 | Implement Cisco IOS Embedded Event Manager (EEM) | |
| 10.07 | Implement Remote Monitoring (RMON) | |
| 10.08 | Implement FTP | |
| 10.09 | Implement TFTP | |
| 10.10 | Implement TFTP server on router | |
| 10.11 | Implement Switch-module Configuration Protocol (SCP) | |
| 10.12 | Implement HTTP and HTTPS | |
| 10.13 | Implement Telnet |
Tuesday, May 5, 2009
MPLS + Troubleshooting added to CCIE R/S exam
Cisco today announced some exciting changes to the CCIE Routing and Switching written and lab exams. Cisco will be adding MPLS and two hours of troublshooting to the CCIE R/S lab. The lab will now be made up of the open-ended questions, two hours of troublshooting, and then the rest of the scenario-based questions. I have pasted the new CCIE R/S version 4 lab blueprint below. You can read more about this change on Cisco's site at https://cisco.hosted.jivesoftware.com/community/certifications/ccie_routing_switching/lab_exam?view=overview.
Monday, April 13, 2009
CCIE ALU - Traffic Control
Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.
Question:
In addition to the 1.1.3.0/24 subnet on R3's FastEthernet0/0 interface, there is also a subnet 1.1.33.0/24, which contains several high bandwidth users. These users have been receiving very large HTTP downloads across the Serial1/3 interface. Limit HTTP responses destined to the 1.1.33.0/24 subnet to 512kbit/sec. All configuration must be done on R3.
Highlight below for the solution:
Solution:
R3:
ip access-list extended HTTP_TO_1.1.33
permit tcp any eq www 1.1.33.0 0.0.0.255
!
class-map match-all HTTP_TO_1.1.33
match access-group name HTTP_TO_1.1.33
!
policy-map QOS1
class HTTP_TO_1.1.33
police 512000
class class-default
!
interface Serial1/3
service-policy input QOS1
Confirmation:
Rack1R3(config-if)#do sh policy-map int
Serial1/3
Service-policy input: QOS1
Class-map: HTTP_TO_1.1.33 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name HTTP_TO_1.1.33
police:
cir 512000 bps, bc 16000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: class-default (match-any)
11 packets, 1088 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Explanation:
Since all configuration must be done on R3, we must use policing because only the very high-end Cisco routers can perform shaping inbound. We create a class that matches TCP traffic with a source port of 80 and any destination port, since the HTTP request is a very small packet going out Serial1/3, and the HTTP response is the very large packet coming in Serial1/3.
One important point to remember is this method of traffic control is ineffective for controlling UDP traffic streams since the traffic has already traversed the serial link between R2 and R3 by the time policing on R3 is enforced. This method of policing on the "far end" is effective when controlling TCP traffic because the applications will set their sliding window to a size that will approximate 512kbit/sec.
If you are not 100% familiar with TCP, sliding windows, and all aspects of TCP retransmission, please read the following site for a great tutorial: http://www.rhyshaden.com/tcp.htm
I highly encourage you to be extremely consistent in the way you name access-lists, class-maps, policy-maps, or other items you create in the IOS. You are free to create any system you would like, but my general guidelines are to make your variables in all capital letters so they stand out in your show commands. I also like to name items according to the section they were created for. For example, if item 4.5 in the QOS section of a test requires me to create an access-list, I will name the access-list QOS4.5. Or if I need to make a numbered ACL, I will number it 45 or 145 depending if I need a standard or extended access-list.
DocCD items to reference:
Configuration Guide (Class-Based Weighted Fair Queueing Configuration Task List)
ip access-list (Named Access-Lists)
Tuesday, March 24, 2009
CCIE ALU - FRTS and how to compute ts
Foreward: A CCIE ALU is an Autonomous Learning Unit, you can read this post to learn more about them.
Question:
Users have been reporting an increase in the number of dropped packets on the frame relay link between R1 and R2. Your frame relay provider has sent you a notice that they are seeing significantly more traffic attempting to go through the frame relay link then permitted. You have purchased 128kbit/sec of guaranteed bandwidth from the provider, but there is currently no restriction on the amount of traffic permitted out the frame relay link. Limit the amount of traffic traversing the frame relay link to the permitted amount. You will soon be allowing voice traffic across that link, so you must minimize delay and jitter.
Highlight below for the solution:
Solution:
map-class frame-relay FRTS
frame-relay cir 128000
frame-relay bc 1280
frame-relay be 0
!
interface Serial0/0
frame-relay traffic-shaping
frame-relay class FRTS
Confirmation:
R2#show frame pvc 201
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
input pkts 5 output pkts 5 in bytes 520
out bytes 520 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 1w6d, last time pvc status changed 00:00:01
cir 128000 bc 1280 be 0 byte limit 160 interval 10
mincir 64000 byte increment 160 Adaptive Shaping none
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued
Explanation:
Frame relay traffic shaping is the method of controlling the rate at which packets are allowed to exit an interface. Since frame relay is a multi-access medium, FRTS specifically allows us to specify separate queues for each DLCI, therefore if you need to allow a certain amount of bandwidth between one set of routers, and a separate amount of bandwidth between another set of routers, FRTS is a great option.
By default there is no limit to the amount of traffic exiting an interface, therefore in this case we will be attempting to send traffic up to the full interface speed out the frame relay interface. Since our service provider is limiting us to 128kbit/sec, it is fruitless to send more than that.
The most important part of this question is to understand how CIR, Bc, Be, and Tc relate mathematically. In this case, since we are asked to minimize delay and jitter we need to set our Tc as low as possible, which is 10ms.
You cannot set the Tc for FRTS explicitly, therefore we must calculate it. To obtain the Tc we want, we need to first figure out how many segments should be sent in a single second. To do this we take 1000 ms and divide it by the desired TC:
1000 / 10 = 100
Now we take our CIR and divide it by the number of segments we will send in a given second to figure out how many bits we should send each time segment, that number will be our Bc:
128000 / 100 = 1280
FRTS will now send 1280 bits every 10ms, resulting in 128,000 bits being sent per second.
It is interesting to note that a router cannot actually send data at less than the interface speed. Therefore, if our frame relay connection above is a 1.536Mbit/sec T1, FRTS will send 1280 bits in only 0.84ms, then sit idle for 9.16ms, then repeat that process 99 more times per second, resulting in the equivalent of 128Kbit/sec.
If you remember the above two step process, you will always be able to calculate the Bc needed to achieve a certain Tc.
- Figure out how many segments should be sent in a single second (1000ms / 10ms = 100 segments)
- Divide our CIR by the number of segments to send in a single second to calculate Bc (128000bps / 100 segments = 1280 bits/segment)
DocCD items to reference:
Configuration Guide (Configuring Frame Relay Traffic Shaping)
Tuesday, March 10, 2009
CCIE ALU - CBWFQ and qos-group tagging to match traffic
Foreward: An ALU is an Autonomous Learning Unit to help with CCIE lab preparation , you can read this post to learn more about them.
Question:
All traffic coming in Serial0/1 of R2 needs to be guaranteed 512Kbit/sec of bandwidth when exiting the frame relay interface of R2. All traffic entering FastEthernet0/0 of R2 should be dropped if it tries to exit the frame relay interface of R2, unless it is HTTPS traffic. No change in configuration should be required if any IP addresses change in the future. Also, no part of the packet header should be modified in any way by this configuration.
Highlight below for the solution:
Solution:
R2:
class-map match-all MATCH_HTTPS
match protocol secure-http
class-map match-all MATCH_QOS1
match qos-group 1
class-map match-all MATCH_QOS2
match qos-group 2
!
policy-map IN_S0-1
class class-default
set qos-group 1
policy-map OUT_S0-0
class MATCH_QOS1
bandwidth 512
class MATCH_QOS2
drop
policy-map IN_FA0-0
class MATCH_HTTPS
class class-default
set qos-group 2
!
interface FastEthernet0/0
service-policy input IN_FA0-0
interface Serial0/1
service-policy input IN_S0-1
interface Serial0/0
service-policy output OUT_S0-0
Confirmation:
R2#show policy-map interface
FastEthernet0/0
Service-policy input: IN_FA0-0
Class-map: MATCH_HTTPS (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: protocol secure-http
Class-map: class-default (match-any)
45 packets, 670 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
qos-group 2
Packets marked 45
Serial0/0
Service-policy output: OUT_S0-0
Class-map: MATCH_QOS1 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: qos-group 1
Queueing
Output Queue: Conversation 265
Bandwidth 512 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: MATCH_QOS2 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: qos-group 2
drop
Class-map: class-default (match-any)
33 packets, 462 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Serial0/1
Service-policy input: IN_S0-1
Class-map: class-default (match-any)
15 packets, 150 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
qos-group 1
Packets marked 15
Explanation:
Qos-group is a flag that can be set and matched on packets, and is local to the router; that is, it is not an industry standard flag, or a flag that is part of the IP or Ethernet headers. The qos-group is very useful because it allows you to apply QOS policy without modifying a packet. For example, in the above question we could have set a DSCP or IP Precedence value, then matched based on that. However, that would modify the packet and change those values; which might have been set by other devices in the network.
In this example we are setting QOS Group 1 on any packets entering the PPP serial link from R3 using the policy-map IN_S0-1. We are also setting QOS Group 2 on any non-HTTPS packet entering FastEthernet0/0 using policy-map IN_FA0-0. We are then reserving bandwidth for QOS Group 1, and dropping QOS Group 2 in policy-map OUT_S0-0.
An important point to remember is that policy-maps are "first hit exit" policies. Meaning traffic is compared to each class within the policy-map, and as soon as it finds one that matches, the actions in that class are executed and the policy-map is exited. In the example of IN_FA0-0 we can see that we are matching HTTPS traffic, and applying no action to it. All other traffic hits the class class-default and has a QOS-GROUP 2 set on it. An alternative to this configuration would be to set QOS-GROUP 2 on all traffic entering FastEthernet0/0, then in policy-map OUT_S0-0 you could match HTTPS and do nothing to it, thereby bypassing the drop associated with QOS GROUP 2. Both options are valid and would be awarded full credit in the CCIE lab.
DocCD items to reference:
Configuration Guide (Class-Based Weighted Fair Queueing Configuration Task List)
Thursday, March 5, 2009
CCIE ALU - CBWFQ Part 4, CBWFQ as a Security Feature
Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.
Question:
Users in subnet 1.1.124.0/24 have been using Kazaa and edonkey to download illegal music files. Company policy prohibits downloading illegal music, and your CIO would like you to stop Kazaa and Edonkey traffic. User's default gateway is 1.1.124.2.
Highlight below for the solution:
Solution:
R2:
class-map match-any DROP_TRAFFIC
match protocol kazaa2
match protocol edonkey
!
policy-map QOS2
class DROP_TRAFFIC
drop
!
interface FastEthernet0/0
service-policy input QOS2
Confirmation:
R2(config)#do sh policy-map interface FastEthernet0/0
FastEthernet0/0
Service-policy input: QOS2
Class-map: DROP_TRAFFIC (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol kazaa2
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol edonkey
0 packets, 0 bytes
5 minute rate 0 bps
drop
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Explanation:
One great feature of Class Based Weighted Fair Queueing (CBWFQ) is the option to assign the action "drop" within a policy-map, turning CBWFQ into a security tool. Combined with NBAR to perform deep inspection on packets, you can selectively drop traffic based on application.
Keeping in mind that CBWFQ can be used to drop traffic is a great way to address questions that prevent you from using all of the traditional security tools such as access-lists, it also allows you to drop very specific traffic such as Kazaa and Edonkey.
Additionally, this question shows the "match-any" keyword on a class-map. By default, a class-map with multiple match statements is a "match-all" class-map. That means if you had a class match that matched an access-list and a DSCP value, both items would need to be true for that class-map to apply. However, in this case we are matching two applications, so a "match-all" class-map would never match, since traffic cannot be BOTH applications. By using the "match-any" keyword, we can use fewer class-maps to match the traffic.
In this question we apply the policy-map in the inbound direction on FA0/0, however we could have also applied it outbound on Serial0/1 of R2. It is best to block traffic as close to the source as possible, so I blocked it inbound at FastEthernet0/0.
DocCD items to reference:
Configuration Guide (Class-Based Weighted Fair Queueing Configuration Task List)
Subscribe to:
Posts (Atom)
Posts
