Greg Ferro's CCIE Study Method

Greg Ferro from Etheralmind recently posted a fantastic summary of his study methodology, and I agree so strongly with so many of his items that I think everyone needs to read it!

http://etherealmind.com/2009/02/10/cisco-study-planning-tips/

A few of the more potent ideas he mentions are:

• Using ear plugs to block out all distractions
  
• Do not listen to the radio or TV during your study sessions
• Use flash cards to help with your weakest areas
• Use Spaced Learning to perminantly memorize important concepts.  (Note, I talked about this in a previous post)
• Make a plan!  I had a detailed plan of which Class on Demand videos I would watch on which days, and which labs I would do when.  If I started to fall behind I would put in a few extra hours to make it happen.  Remember that the test date will come, you best be prepared.

ALU - CBWFQ Part 3, Time Specific QOS

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

 

 

Question:

 

Users in the 1.1.124.0/24 subnet are accessing a stock trading web site on web server with the IP address 1.1.3.25.  Users are reporting that every afternoon between 3:00 PM and 5:00 PM, in the final minutes of trading, the responsiveness of the web server becomes very poor.  You have traced the issue down to an automated FTP transfer that occurs during this time.  Guarantee 1Mbit/sec of bandwidth for web traffic to and from the web server across the serial link between R2 and R3.  Access-lists should be as specific as possible.  This QOS should only be applied during the two hours listed above, and only on weekdays.

 

Note: This question is an extension of the previous question, ALU - CBWFQ Part 2.

 

 

Highlight below for the solution:

 

Solution:

R3:

access-list 102 remark Traffic from server to clients

access-list 102 permit tcp host 1.1.3.25 eq www 1.1.124.0 0.0.0.255 time-range TRADING_HOURS

!

class-map match-all HTTP_STOCK

 match access-group 102

!   

policy-map QOS1

 class HTTP_STOCK

  bandwidth 1000

!

interface Serial1/3

  service-policy output QOS1

 

R2:

access-list 102 remark Traffic from clients to server

access-list 102 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www time-range TRADING_HOURS

!

class-map match-all HTTP_STOCK

 match access-group 102

!   

policy-map QOS1

 class HTTP_STOCK

  bandwidth 1000

!

interface Serial0/1

  service-policy output QOS1

 

Confirmation:

R2(config)#do show policy-map int

 Serial0/1

 

  Service-policy output: QOS1

 

    Class-map: HTTP_STOCK (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group 102

      Queueing

        Output Queue: Conversation 265

        Bandwidth 1000 (kbps)Max Threshold 64 (packets)

        (pkts matched/bytes matched) 0/0

        (depth/total drops/no-buffer drops) 0/0/0

 

    Class-map: class-default (match-any)

      295 packets, 18144 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 

R2(config)#do sh access-list 102

Extended IP access list 102

    10 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www time-range TRADING_HOURS

 

 

 

Rack1R2#clock set 13:30:00 feb 20 2009

Rack1R2#sh access-list 102

Extended IP access list 102

    10 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www time-range TRADING_HOURS (inactive)

Rack1R2#sh time-range

time-range entry: TRADING_HOURS (inactive)

   periodic weekdays 15:00 to 16:59

   used in: IP ACL entry

Rack1R2#clock set 15:30:00 feb 20 2009

Rack1R2#

Rack1R2#sh access-list 102

Extended IP access list 102

    10 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www time-range TRADING_HOURS (active)

Rack1R2#sh time-range

time-range entry: TRADING_HOURS (active)

   periodic weekdays 15:00 to 16:59

   used in: IP ACL entry

 

 Explanation:

This question combines knowledge of CBWFQ and basic knowledge of what ports traffic uses as source and destination ports.  For a detailed explanation of how a CBWFQ policy is put together, see my previous post ALU - CBWFQ Part 1.

 

When a client establishes a TCP connection to a server it selects a random "high port" to use as its source port, and it puts the well-known port for the application it is trying to reach as its destination port.  In this case, a client accessing the web server will have a source IP address of 1.1.124.0/24, a random source port, a destination IP address of 1.1.3.25, and a destination port of 80.  Conversely, the web server will generate the mirrored traffic; a source IP of 1.1.3.25, a source port of 80, a destination IP of 1.1.124.0/24, and a random destination port to match the client's random source port.

 

Note, with regards to the part of the question that requires specific access-lists, it would be worth asking the Proctor if the above access-lists are sufficiently specific, or if you need to scope it even further because the client will use a random high port as a source port.  It is not likely that the CCIE lab is testing that, it would be looking to make sure you know a server's source port is the well-known port, and the client's destination port is the well-known port.  Also, since different operating systems use a different set of "high ports," there is not a definitive answer to what a high port should be.  Reference: Wikipedia: "Ephemeral port"

 

This question is an extension of the question ALU - CBWFQ Part 2 because it adds the requirement that the QOS should only be active during a certain time range.  Since the time in a time-range command continues until the 59th second of the stated time, it is most precise to configure the time range as "periodic weekdays 15:00 to 16:59" which is 3:00:00 PM through 4:59:59 PM.  In general, the CCIE lab is not concerned with that degree of specificity.  In all likelihood, the Proctor or grading script will set two times like the above confirmation section does, and neither will be within seconds of the time-range activating.  If your lab has a question that mentions specific times, it is best to ask the proctor for clarification.

 

DocCD items to reference:

Configuration Guide (Access Control Lists: Overview and Guidelines)

class-map

policy-map

match access-group

bandwidth

service-policy out

time-range

show policy-map interface

ALU - CBWFQ Part 2

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

 

 

Question:

 

Users in the 1.1.124.0/24 subnet are accessing a stock trading web site on web server with the IP address 1.1.3.25.  Users are reporting that every afternoon, in the final minutes of trading, the responsiveness of the web server becomes very poor.  You have traced the issue down to an automated FTP transfer that occurs during this time.  Guarantee 1Mbit/sec of bandwidth for web traffic to and from the webserver across the serial link between R2 and R3.  Access-lists should be as specific as possible.

 

Note: For an added challenge, refer to ALU - CBWFQ Part 3, Time Specific QOS

 

 

Highlight below for the solution:

 

Solution:

R3:

access-list 101 remark Traffic from server to clients

access-list 101 permit tcp host 1.1.3.25 eq www 1.1.124.0 0.0.0.255

!

class-map match-all HTTP_STOCK

 match access-group 101

!   

policy-map QOS1

 class HTTP_STOCK

  bandwidth 1000

!

interface Serial1/3

  service-policy output QOS1

 

R2:

access-list 101 remark Traffic from clients to server

access-list 101 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www

!

class-map match-all HTTP_STOCK

 match access-group 101

!   

policy-map QOS1

 class HTTP_STOCK

  bandwidth 1000

!

interface Serial0/1

  service-policy output QOS1

 

Confirmation:

R2(config)#do show policy-map int

 Serial0/1

 

  Service-policy output: QOS1

 

    Class-map: HTTP_STOCK (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group 101

      Queueing

        Output Queue: Conversation 265

        Bandwidth 1000 (kbps)Max Threshold 64 (packets)

        (pkts matched/bytes matched) 0/0

        (depth/total drops/no-buffer drops) 0/0/0

 

    Class-map: class-default (match-any)

      295 packets, 18144 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 

R2(config)#do sh access-list 101

Extended IP access list 101

    10 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www

 

Explanation:

This question combines knowledge of CBWFQ and basic knowledge of what ports traffic uses as source and destination ports.  For a detailed explanation of how a CBWFQ policy is put together, see my previous post ALU - CBWFQ Part 1.

 

When a client establishes a TCP connection to a server it selects a random "high port" to use as its source port, and it puts the well-known port for the application it is trying to reach as its destination port.  In this case, a client accessing the web server will have a source IP address of 1.1.124.0/24, a random source port, a destination IP address of 1.1.3.25, and a destination port of 80.  Conversely, the web server will generate the mirrored traffic; a source IP of 1.1.3.25, a source port of 80, a destination IP of 1.1.124.0/24, and a random destination port to match the client's random source port.

 

Note, with regards to the part of the question that requires specific access-lists, it would be worth asking the Proctor if the above access-lists are sufficiently specific, or if you need to scope it even further because the client will use a random high port as a source port.  It is not likely that the CCIE lab is testing that, it would be looking to make sure you know a server's source port is the well-known port, and the client's destination port is the well-known port.  Also, since different operating systems use a different set of "high ports," there is not a definitive answer to what a high port should be.  Reference: Wikipedia: "Ephemeral port"

 

DocCD items to reference:

Configuration Guide (Access Control Lists: Overview and Guidelines)

class-map

policy-map

match access-group

bandwidth

service-policy out

show policy-map interface

ALU - CBWFQ Part 1

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

 

 

Question:

A Cisco VOIP system has recently been deployed to users in subnet 1.1.3.0/24.  They are experiencing lost packets and unacceptable delay and jitter on the serial link between R2 and R3.  Configure R2 and R3 to guarantee 256,000 bits/sec of bandwidth for RTP traffic traversing the T1.

 

 

 

 

Highlight below for the solution:

 

Solution:

R2 and R3:

class-map match-all CLASS_RTP

 match protocol rtp

!        

policy-map QOS1

 class CLASS_RTP

  priority 256

 class class-default

!

interface Serial1/3

  service-policy output QOS1

 

 

Confirmation:

R3#show policy-map interface

 Serial1/3

  Service-policy output: QOS1

    Class-map: CLASS_RTP (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: protocol rtp

      Queueing

        Strict Priority

        Output Queue: Conversation 264

        Bandwidth 256 (kbps) Burst 6400 (Bytes)

        (pkts matched/bytes matched) 0/0

        (total drops/bytes drops) 0/0

 

    Class-map: class-default (match-any)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 

 

Explanation:

Class Based Weighted Fair Queueing uses Cisco's newer modular quality of service to form QOS policies.  The first step is to create class-maps, these define what traffic will be matched.  In a class map you can match on a myriad of options; the most common being:

• Access-lists
• IP Precedence Values
• DSCP Value
• QOS-Groups   (I will cover these in a future ALU)
• Protocol using NBAR

 

In this case, since RTP encompasses a large range of UDP ports (16384 - 32767), the fastest and least error-prone way to match RTP would be to use NBAR's ability to match a protocol for this task, since all we need is a "match protocol rtp" statement in the class-map.

 

The next step to using Cisco's modular quality of service to form a QOS policy is to combine any class-maps you have into a policy-map to assign actions to traffic matching those classes.  In this case we created a policy called QOS1, and within that referenced the class-map CLASS_RTP.  Within that class there are two types of bandwidth guarantees we can give.  The first is using the "bandwidth" command.   This command allows us to designate a certain amount of bandwidth to a type of traffic, with no priority or preference to when that queue is serviced.  The other option is "priority" which designates a certain level of bandwidth, and services the priority queue before any other queues.  Essentially, that allows your highly delay and jitter sensitive RTP traffic to "cut in line" in front of any other traffic on the interface and be sent first.  Any question that mentions voice, video, or delay/jitter sensitive traffic is a clue to use a priority queue instead of a regular queue.

 

It is important to remember that Cisco's "priority" bandwidth guarantee option in CBWFQ sets a policer on the priority queue to prevent priority traffic from starving other queues on the interface.  For example, if we designate 256kbit/sec of priority bandwidth for RTP traffic and we are downloading a large file via FTP at the same time that we are sending 200kbit/sec of RTP traffic, all RTP traffic will be serviced before any FTP traffic.  However, if we initiate another few calls and are now sending 300kbit/sec of RTP traffic, all traffic above 256kbit/sec will be dropped as long as the FTP download is causing interface congestion.

 

In terms of the CCIE lab, if a question has wording such as "ensure no more than 256kbit/sec of RTP traffic is permitted during times of congestion," then you can be confident that they want you to use the "priority" command.  However, if the question states that RTP traffic should always be given priority treatment on the interface, even to the point of starving all other traffic, you will want to use the legacy priority queuing, not CBWFQ.

 

After you have created class-maps to classify your traffic, and a policy-map to assign actions to those classes, the final step to configuring CBWFQ is to assign that policy-map to the interface using the "service-policy output QOS1" command.  It is important to note that most Cisco platforms, including any you might use in the CCIE lab, do not support inbound queuing, so you can only apply CBWFQ outbound on an interface.

 

 

DocCD items to reference:

Configuration Guide (Low Latency Queueing Configuration Task List)

class-map

policy-map

match protocol

priority

service-policy out

show policy-map interface

ALU - RMON

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

During a consulting job, you discovered a small organization which has no formal NOC or NMS capability, however, they would like to have some form of alerting if thresholds are exceeded.  Configure R2 to send a SYSLOG entry with the text "Octets in Serial exceeds 10,000" to 1.1.2.114 if the number of octets coming in Interface Serial0/1 exceeds 10,000 over a 10 second period.  Send another SYSLOG message with the text "Octets in Serial no longer exceeds 5,000" when the number of octets goes below 5,000.

 

The MIB for the number of octets coming in an interface is 1.3.6.1.2.1.2.2.1.10.X where X is the ifindex value of the Interface.

 

 

 

 

Highlight below for the solution:

 

Solution:

R2:

  logging 1.1.2.114

  rmon event 1 log description "Octets in Serial exceeds 10,000" owner config

  rmon event 2 log description "Octets in Serial no longer exceeds 5,000" owner config

  rmon alarm 10 ifInOctets.3 10 delta rising-threshold 10000 1 falling-threshold 5000 2 owner config

 

 

Confirmation:

R2(config)#do ping 1.1.23.3 size 1500 repeat 750

 

Type escape sequence to abort.

Sending 750, 1500-byte ICMP Echos to 1.1.23.3, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (750/750), round-trip min/avg/max = 4/6/76 ms

*Mar  2 17:37:17.169: %RMON-5-RISINGTRAP: Rising trap is generated because the value of ifInOctets.3 exceeded the rising-threshold value 10000

*Mar  2 17:37:27.177: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of ifInOctets.3 has fallen below the falling-threshold value 5000

 

 

R2#show logging | begin Trap

    Trap logging: level informational, 38 message lines logged

        Logging to 1.1.2.114(global) (udp port 514, audit disabled,  link up), 8 message lines logged, xml disabled,

               filtering disabled

 

Rack1R2#show rmon alarms    

Alarm 10 is active, owned by config

 Monitors ifInOctets.3 every 10 second(s)

 Taking delta samples, last value was 363

 Rising threshold is 10000, assigned to event 1

 Falling threshold is 5000, assigned to event 2

 On startup enable rising or falling alarm

 

Rack1R2#show rmon events

Event 1 is active, owned by config

 Description is Octets in Serial exceeds 10,000

 Event firing causes log,

 last event fired at  0y0w1d,17:37:17,

 Current uptime       0y0w1d,17:39:14

 Current log entries:

  index  uptime              description

  1      0y0w1d,17:36:27     Octets in Serial exceeds 10,000

  2      0y0w1d,17:37:17     Octets in Serial exceeds 10,000

Event 2 is active, owned by config

 Description is Octets in Serial no longer exceeds 5,000

 Event firing causes log,

 last event fired at  0y0w1d,17:37:27,

 Current uptime       0y0w1d,17:39:14

 Current log entries:

  index  uptime              description

  1      0y0w1d,17:36:17     Octets in Serial no longer exceeds 5,000

 

 

R2#show snmp mib ifmib ifindex

FastEthernet0/0: Ifindex = 1

Loopback0: Ifindex = 8

Null0: Ifindex = 7

VoIP-Null0: Ifindex = 6

Serial0/0: Ifindex = 2

Serial0/1: Ifindex = 3

Serial0/2: Ifindex = 4

Serial0/3: Ifindex = 5

 

 

Explanation:

This question is a classic RMON question with a slight twist that it requires you to identify the ifindex value for Serial0/1.  The way to do that is to enable a SNMP community string on the router, then issue the "show snmp mib ifmib ifindex" command.  RMON questions will always need to give you the MIB value to query, but for MIB values that require the ifindex value of an interface you should know how to find the ifindex value.

 

RMON alarms have two modes of data collection, the first is absolute value.  An absolute value measure compares the SNMP value to a static value.  An example of a SNMP value that would work to compare against an absolute would be something that rises and falls, such as CPU usage, rolling five-minute averages of interface usage, or temperature.  Those values all go up and come back down.

 

The other type of RMON alarm is a delta alarm.  A delta alarm compares the current SNMP value to what the value was the last time RMON checked.  The difference, or delta of those two numbers is what is compared to the thresholds.  For example, the number of octets coming in an interface will never decrease, so comparing that number against a static value would not be useful.  However, if we compare the amount of octets that have come in the interface in the past ten seconds to a number, we have a useful statistic.

 

When identifying what type of RMON alarm to use always ask yourself if the value can ever go down.  If it can, it is likely going to be an absolute alarm.  If the value can never go down, such as in octets on an interface, seconds since last reload, or the configuration revision of a VLAN database, it is going to be a delta value.

 

The only other area of confusion for some CCIE candidates is when a RMON question requests that you forward RMON events to a SYSLOG server.  There is no magic involved there, you just issue the "logging IP" command to send all messages generated locally to the syslog server.

 

To test this alarm we can issue a ping with a high repeat count and large packet size to generate enough octets to cause the rising threshold to be exceeded.

 

 

DocCD items to reference:

Configuration Guide

rmon alarm

rmon event

logging host

ALU - SNMP Part 2

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

  

 

Question:

Your NOC has begun monitoring several SNMP values from R3. However, after a recent reboot of R3 they have complained that they needed to reconfigure the NMS because the SNMP interface identifiers changed. Prevent this from happening during future reboots.

 
 

 
 

Highlight below for the solution:

 
 

Solution:

R3:

snmp-server ifindex persist

 

 
 

Confirmation:

show snmp mib ifmib ifindex

Ethernet0/0: Ifindex = 1

Loopback0: Ifindex = 11

Null0: Ifindex = 10

VoIP-Null0: Ifindex = 9

Serial1/0: Ifindex = 5

Ethernet0/1: Ifindex = 2

Serial1/1: Ifindex = 6

Ethernet0/2: Ifindex = 3

Serial1/2: Ifindex = 7

Ethernet0/3: Ifindex = 4

Serial1/3: Ifindex = 8

 
 

 
 

Explanation:

SNMP uses ifindex identifiers to reference specific interfaces. For example, if you wanted to monitor the octets going in an interface, you would monitor MIB Iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets.X, where X is the ifindex value of the interface. Also of note is MIB paths resolve to OIDs. The OID for the above MIB is 1.3.6.1.2.1.2.2.1.10.X.

 
 

You can use the "show snmp mib ifmib ifindex" command to display the ifindex values of each interface on a router. However, without the global "snmp-server ifindex persist" command, the ifindex values will change every reboot, making your NOC folks upset.

 
 

Also of interest is the command required for this question is located in the "Cisco IOS Interface and Hardware Component Command Reference," not the Network Management section. It is quite common for Cisco to try and trick you by including a question in one section that requires a command from another. For example, it should not be surprising to have a question from an OSPF or EIGRP section that requires the use of the "backup interface" command to achieve the required behavior.

 
 

DocCD items to reference:

Configuration Guide (Scroll down to Enabling IfIndex Persistence on All Interfaces Example)

snmp-server ifindex persist

ALU - SNMP Part 1

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

Question: 

 

Your NOC is installing two new network management stations soon, their IP addresses will be 1.1.3.80 and 1.1.3.90.  Configure R3 to allow read-only SNMP access from both NMS stations using community string CISCO_RO.  Configure R3 to allow read-write SNMP access from the NMS station at 1.1.3.90 using community CISCO_RW.  Your NOC also wants you to configure R3 to send traps relating to temperature problems to 1.1.3.80 using community CISCOTRAP.

 

 

Highlight below for the solution:

 

Solution:

R3:

  access-list 10 permit 1.1.3.80

  access-list 10 permit 1.1.3.90

  access-list 20 permit 1.1.3.90

  snmp-server community CISCO_RO ro 10

  snmp-server community CISCO_RW rw 20

  snmp-server host 1.1.3.80 traps CISCOTRAP envmon

  snmp-server enable traps envmon temperature

 

Confirmation:

R3#show snmp community

 

Community name: ILMI

Community Index: cisco0

Community SecurityName: ILMI

storage-type: read-only  active

 

 

Community name: CISCOTRAP

Community Index: cisco1

Community SecurityName: CISCOTRAP

storage-type: nonvolatile        active

 

 

Community name: CISCO_RO

Community Index: cisco2

Community SecurityName: CISCO_RO

storage-type: nonvolatile        active access-list: 10

 

 

Community name: CISCO_RW

Community Index: cisco3

Community SecurityName: CISCO_RW

storage-type: nonvolatile        active access-list: 20

 

R3#show run | include trap|host_

snmp-server enable traps envmon temperature

snmp-server host 1.1.3.80 CISCOTRAP  envmon

 

 

Explanation:

This question shows the difference between read-only, read-write, and trap communities.  It also demonstrates the ability to put different access lists on each community to limit which hosts can use those communities.

 

It is very important to remember that sending traps to a host requires two separate commands, the first, "snmp-server enable traps envmon temperature" enables that trap globally; without it, no host would receive that trap.  The second command, "snmp-server host 1.1.3.80 traps CISCOTRAP envmon" enables the specific trap (envmon) to be sent to the host 1.1.3.80.  It is helpful to be able to specify some traps to go to one NMS and others to go to another NMS, and the second command allows us to do that.

 

I also included a filtered "show run" command, which is one of the best ways to quickly verify a configuration.  It is also a great way to stay sharp on your regular expression knowledge.  The command

"show run | include trap|host_" says to show the running configuration, but only include lines that include the word trap, and the word host, immediately followed by a space.  Without the underscore after host, that show command would display the "hostname Rack1R3" command.  An underscore in RegEx must be a space, the beginning, or ending of a string.  You can find more regular expression help on the Cisco Doc CD hidden under the Configuration Guides - Terminal Services - Appendixes - Regular Expressions

 

DocCD items to reference:

Configuration Guide (Scroll to How to Configure SNMP Support, Configuring SNMP Versions 1 and 2)

snmp-server community

snmp-server enable traps

snmp-server host

ALU - PPP Authentication Part 2

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

 

Your manager has recently read an article in a security magazine regarding the dangers of unencrypted authentication, and has asked you to make sure R3 will never allow unencrypted link authentication on the Serial1/3 link.

 

 

 

 

Highlight below for the solution:

 

Solution:

R3:

  interface Serial1/3

    ppp pap refuse

 

Confirmation:

R2:

  interface Serial0/1

    ppp authentication pap

 

R3:

  debug ppp authentication

! Clip

Se1/3 PPP: Authorization required

 

Explanation:

Commands like "ppp pap refuse" or "ppp chap refuse" are not often used, and are not likely to be worth more than one or two points on an exam, but if you did not know about them, or even know they exist, you could spend a half hour or more reading through the DOC CD trying to find the command.

 

It is a great idea to skim through the Configuration Guides and Command References on the DOC CD and take note of any commands with interesting features like "ppp pap refuse."  Being able to pick up a quick point or two by knowing a command like this off the top of your head will help tremendously.

 

 

DocCD items to reference:

Configuration Guide (Note, scroll down to Non-AAA Authentication Methods, Enabling CHAP or PAP Authentication, Refusing CHAP Authentication Requests

ppp pap refuse

ppp chap refuse

ALU - PPP Authentication Part 1

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

Managers are concerned about the security of the serial link between R2 and R3.  Configure R3 to send a secure challenge to R2.  R3 is expecting the username "Router2" and the password CISCO.

 

 

 

Highlight below for the solution:

 

Solution:

R3:

interface Serial1/3

  encapsulation ppp

  ppp authentication chap

  username Router2 password CISCO

 

R2:

interface Serial0/1

  encapsulation ppp

  serial restart-delay 0

  ppp chap hostname Router2

  ppp chap password CISCO

 

Confirmation:

R3#debug ppp authentication

  ! clip

  Se1/3 CHAP: O CHALLENGE id 17 len 28 from "Rack1R3"

  Se1/3 CHAP: I RESPONSE id 17 len 23 from "Router2"

(Note, the "debug ppp authentication" command can be very noisy if your authentication is not working.  It is recommended to turn off console logging, and log this debug command to the buffer and display it using "show logging")

 

Explanation:

Many CCIE candidates are used to configuring bidirectional authentication, where both routers involved challenge each other.  It is important to practice single directional authentication, where one router requires the other router to authenticate, but not vice vs.

 

PPP has two methods of authentication, CHAP and PAP.  PAP is a plain text password exchange, whereas CHAP is a secure challenge, where the password is never passed over the wire.  This question requires R3 to "send a secure challenge," which cues us to use CHAP instead of PAP. 

 

By default, CHAP will send the router's hostname, but this question requires us to use "R2" as a CHAP username, instead of the router's hostname.

 

In the above "debug ppp authentication" output we can see that R3 is sending a challenge, and R2 is responding with the username "Router2."  We can also see that R2 is not sending a challenge to R3, which is the requested behavior.

 

DocCD items to reference:

Configuration Guide (Note, scroll down to "Non-AAA Authentication Methods," "Enabling CHAP or PAP Authentication"

ppp authentication

ppp chap hostname

ppp chap password

 

ALU - BGP Aggregation Part 3

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

 

Paste the following configuration into R4:

interface Loopback2564

 ip address 25.0.64.2 255.255.255.0

interface Loopback2565

 ip address 25.0.65.2 255.255.255.0

interface Loopback2566

 ip address 25.0.66.2 255.255.255.0

interface Loopback2567

 ip address 25.0.67.2 255.255.255.0

route-map BGPOUT

  set as prepend 25 60 70 

router bgp 400

  neighbor 1.1.124.2 remote 200

  neighbor 1.1.124.2 route-map BGPOUT out

  network  25.0.64.0 mask 255.255.255.0

  network  25.0.65.0 mask 255.255.255.0

  network  25.0.66.0 mask 255.255.255.0

  network  25.0.67.0 mask 255.255.255.0

 

R2 is in AS 200, R4 is in AS 400.  R2 and R4 should peer via their FastEthernet interfaces.  R4 is advertising a series of prefixes to R3, configure R3's "show ip bgp" below.  Use one, and only access-list; that access-list must have only one line.  Any future prefixes must be accepted, and not tagged with a local preference or weight.

 

R3#show ip bgp

   Network       Next Hop  Metric LocPrf Weight Path

*> 25.0.64.0/24  1.1.124.4      0         22222 400 25 60 70 i

*> 25.0.64.0/22  0.0.0.0            2323  32768 400 25 60 70 i

*> 25.0.65.0/24  1.1.124.4      0    222      0 400 25 60 70 i

*> 25.0.66.0/24  1.1.124.4      0         22222 400 25 60 70 i

*> 25.0.67.0/24  1.1.124.4      0    222      0 400 25 60 70 i

 

 

Proctor Question:

  CCIE Candidate: Mr. Proctor, do you consider a prefix-list an access-list for this question?

  Proctor: No.

 

 

 

Highlight below for the solution:

 

Solution:

router bgp 200

 aggregate-address 25.0.64.0 255.255.252.0 as-set attribute-map BGPAGG

 neighbor 1.1.124.4 remote-as 400

 neighbor 1.1.124.4 route-map BGPIN in

 neighbor 1.1.124.4 unsuppress-map UNSUPPRESS

 

ip prefix-list BGPEVEN seq 5 permit 25.0.64.0/24

ip prefix-list BGPEVEN seq 10 permit 25.0.66.0/24

access-list 2 permit 25.0.65.0 0.0.2.255

 

route-map BGPAGG permit 10

 set local-preference 2323

 

route-map BGPIN permit 10

 match ip address 2

 set local-preference 222

route-map BGPIN permit 20

 match ip address prefix-list BGPEVEN

 set weight 22222

route-map BGPIN permit 30

 

 

Explanation:

BGP has many attributes, and a CCIE candidate should be very comfortable with changing any attribute.  This question also requires keen attention to detail, because the output of "show ip bgp" contains a lot of information.  In this case, we can see some prefixes have a local preference set, some have a weight set, and the aggregate address has a different local preference set, and contains an AS PATH.

 

The other twist in this question is the statement that you need to use a single line access list to match some prefixes.  This requires an access-list that matches even or odd addresses.  The other BGP attribute should be set using a prefix list.  The final requirement was all future prefixes should not be modified, hence the "route-map BGPIN permit 30" statement.  These settings are combined into the route-map BGPIN and put on the neighbor statement.

 

Finally, by default, the aggregate-address will strip the BGP AS Path, so since the aggregated address in this "show ip bgp" output has a BGP AS path, we need to use the "as-set" option in the aggregate-address.

 

CCIE candidates should review this type of question several times, even putting your finger on every word, to verify they have met every requirement of this question.  A question like this will be verified by looking at the "show ip bgp" output, so there is no reason you should not receive all points.

 

DocCD items to reference:

Configuration Guide

aggregate-address