The Contest

Eligibility: This Contest is open to all Cisco Certification Aspirants. Only one entry per person must be submitted.

Contest Period: Contest ends on Feb 5th 2012 at 10.00 AM PST

Prizes: The winner is entitled to receive IPexpert’s 50% Off  Coupon Code. Prizes cannot be redeemed for cash or substituted for any other items by the winner. The winner cannot assign or transfer the prize.

Enter Contest HERE - http://www.facebook.com/IPexpert?sk=app_23744633048

**Winner will be announced in our February Newsletter
** Coupon Code not valid for Instructor Led Bootcamps

Print Friendly

• Yash Joshi CCIE #31109 (Voice)

Are you a CCIE TOP GUN? If your name isn’t on THIS LIST yet, you can become a CCIE Top Gun. Simply, send us your name, CCIE#, and you can be the proud owner of the IPexpert’s CCIE Top Gun shirt shown below. Email us at ccie@ipexpert.com.

IPexpert is proud to boast 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

Question 1:

Which of these statements regarding NHRP are true? Choose two.

a. NHRP is typically used with P2P GRE interfaces
b. The NHRP network ID must match on all routers in the hub and spoke NBMA cloud
c. NHRP provides functionality similar to ARP
d. NHRP is a key ingredient in the DMVPN from Cisco Systems

Question 2:

NHRP can be broken down into two operational functions. What are these two? Choose two.

a. NHRP resolution
b. NHRP broadcasting
c. NHRP querying
d. NHRP registration

Question 1 Answer:

1. c, d

Question 2 Answer:

2. a, d

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

Obviously, the official announcement is coming soon. The RSA conference mentioned in the article, and  Cisco Live in San Diego, are certainly candidates for the official announcement.

Here is the relevant information from the post:

“The Real Life of an Expert: Introducing the New CCIE Security

CCIE Security 4.0 is unusual among security certificates for its up-to-date, real-world content. It emphasizes security competency and efficient problem solving in networks that use cloud services, carry voice and multimedia traffic, and are accessed by a variety of wireless devices.

The content, currently in development, may include real-world applications that involve:

• Securing both wireless and wired networks, including managing security policy by device and service
• Extending application awareness to security devices, moving security up to Layer 7 from the stateless packets of Layers 3 and 4, and applying policy on a per-identity basis
• Applying security policy in a network that has voice and video traffic
• Securing networks that use managed services, dual ISPs, IPv6, or IP multicast

Cisco will soon announce the blueprints for the CCIE Security 4.0 written and lab exams; the first exam will take place approximately six months later.

Although there are no prerequisites for registration, Cisco offers a preparation path through its CCNA and/or CCNP Security levels, and recommends that candidates have at least three years of hands-on network security experience.”

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

While you may consider NHRP as a simple name resolution protocol like Address Resolution Protocol (ARP), NHRP operates in a much more efficient manner. NHRP operates in a client/server type fashion. In a typical implementation, hub routers in a hub and spoke topology operate as next-hop servers (NHS). Spoke routers in the topology act as next-hop clients (NHC). It is the job of the hub router next-hop server to maintain a next-hop resolution protocol database of public interface addresses of each spoke. The hub router builds this database by accepting registrations of each spoke device’s physical IP address as each spoke boots on the network. Spoke routers also query the NHRP database for the physical addresses of the destination spokes.

Possessing the physical addresses of remote spokes allows these spoke devices to build direct tunnels with these remote spokes. This is the beauty of the next hop resolution protocol. Remote spoke routers now possess the ability to communicate directly without requiring traffic to use an intermediate hop (the hub router).

Notice that you can segment the operation of NHRP into two distinct phases. There is the registration process and the resolution process. The overall result of NHRP is the decreases the overhead placed on the hub device and spoke devices communicate directly with other spoke devices.

The example configuration below demonstrates the simplicity that makes this powerful protocol function. This blog will detail the protocol and its configuration in more depth in future posts.

R1

interface tunnel 0
 no ip redirects
 ip address 209.165.200.224 255.255.255.0
 ip nhrp map 209.165.200.225 10.0.0.2
 ip nhrp network-id 1
 ip nhrp nhs 209.165.200.225
 tunnel source fastethernet 0/0
 tunnel mode gre multipoint
 tunnel key 1
interface fastethernet 0/0
 ip address 10.0.0.1 255.0.0.0

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

Generic Routing Encapsulation (GRE)

Cisco developed the Generic Routing Encapsulation (GRE) protocol to encapsulate network layer protocols over a virtual point-to-point (P2P) link. RFC 2784 details this useful protocol.

GRE is desirable anytime routers must be “tricked” into handling packets they would otherwise normally not handle. For example, multicast traffic cannot be natively protected by IP Security (IPSec), so GRE can encapsulate this traffic initially, and then it can be protected by an IPSec VPN.

GRE uses IP protocol type 47.

Multipoint Generic Routing Encapsulation (mGRE)

The “classic” GRE tunnel described above is considered a point-to-point structure. Multipoint Generic Routing Encapsulation (mGRE) relaxes this concept to include multiple destinations in the GRE process.

Consider the classic and popular hub and spoke topology. Perhaps GRE needs to function in this environment. For each new additional spoke that might be added, a new P2P GRE tunnel must be constructed. This new tunnel would need its own logical IP subnet. This leads to an obvious waste of IP address space, and perhaps far worse, it leads to excessive overhead on the hub device.

Multipoint GRE arrives to the rescue. Thanks to this GRE technique, the hub and spoke devices may use a single tunnel. This tunnel is one logical IP subnet. At this point, you can consider this design and functionality similar to a non-broadcast multi-access (NBMA) technology like Frame-Relay.

With mGRE, you need a name resolution mechanism that can map the logical tunnel IP addresses to the underlying physical IP addresses in the topology. This is what the Next Hop Reachability Protocol (NHRP) is used for. I will cover this important technology in an upcoming blog post.

mGRE and NHRP are critically important for mastery in the CCIE Security 3.0 because they are two of the necessary protocol components used in the construction of the Dynamic Multipoint VPN (DMVPN).

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

1) CCNA 5 Day Bootcamp Bundle

2) $1499 CCIE 5 Day Bootcamp Promotion

3) CCIE Voice 5-Lab Handbook for v3.0 Lab Exam

4) IPv4/6 Multicast Operations & Troubleshooting

5) Buy a Bundle, Save a Bundle Solutions

6)$999 CCIE Blended Learning Solution Promotion

7). CCIE Lab Prepration eBooks

8) 40% off Complete CCNA Video on Demand Courses

9) 30% off Complete CCNP Video on Demand Courses

10) BOGO Rack Time – Buy One Get One Free vRack Session!

Print Friendly

• Chris Martin CCIE #34310 (Voice)
• Jose Valverde CCIE #34305 (Voice)

Chris Martin CCIE# 34310:

“Well its official, got my results in this morning, CCIE # 34310.  Just want to give a big thanks to everyone here in Online Study List for a great community in which to strive toward this goal over the last year.  Thanks to Vik Malhi and IPexpert for the great CCIE Voice VoDs, CCIE Voice 5 Day Bootcamp,  and Proctor Labs rack rentals. I cannot imagine myself achieving success without your products and ongoing support.  A big shout out to my boot camp  buddies from 11/11/11, keep your head down and don’t give up, I am sure you will all make it!

Now time for a break.. and maybe a real book, that isn’t a SRND or Cisco Press…”

Jose Valverde CCIE# 34305:

“Just wanted to say thank you to Vik Malhi for all of your tips and tricks. I was able to pass my lab exam this past Tuesday. Without your CCIE Voice Bootcamp it definitely would have been harder.”

If you have ever used any of IPexpert’s training materials (Videos, Bootcamp, vLectures, or Proctor Labs vRacks) and have passed your CCIE Lab and are not on THIS LIST, you can get this IPexpert “CCIE Top Guns” t-shrit for FREE.  Email us at ccie@ipexpert.com, let us know your shirt size, mailing address, name and CCIE #.

IPexpert is proud to boast 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

Chapter Challenge: BSR Sample Trouble Tickets Solutions

The following section includes the solutions to the three Trouble Tickets presented in the previous section. Figure 9-11 provides a flowchart that outlines a “quick fire” approach to isolating and remediating issues associated with BSR.

Figure 9-11: BSR Quick Fire Troubleshooting Flowchart

Trouble Ticket #1 Solution

Your supervisor has brought to your attention that the C-BSR routers R2 and R7 do not agree on the identity of the BSR. You must correct the issue.

Step 1 – Fault Verification:

R2 and R7 are the C-BSRs that are of interest in this trouble ticket:

R2#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
 BSR address: 192.1.2.2 (?)
 Uptime:      00:59:48, BSR Priority: 200, Hash mask length: 0
Next bootstrap message in 00:00:12

R7#show ip pim bsr
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
 BSR address: 192.1.7.7 (?)
 Uptime:      03:35:07, BSR Priority: 255, Hash mask length: 0
 Next bootstrap message in 00:00:53

These two C-BSRs each think they are the BSR in this topology. This verifies that the problem actually exists.

Step 2 – Fault Isolation:

The next course of action is to use the mtrace utility to rule out the possibility of an RPF issue. Make certain to perform this process in both directions, first from R2 toward R7, then from R7 toward R2.

R2#mtrace 192.1.2.2 192.1.7.7
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 192.1.7.7 via RPF
From source (?) to destination (?)
Querying full reverse path...
0  192.1.7.7
-1  172.16.67.7 PIM  [192.1.2.0/24]
-2  172.16.67.6 PIM  [192.1.2.0/24]
-3  172.16.26.2 PIM  [192.1.2.0/24]
-4  192.1.2.2

There are no problems in the path from R2 to R7. Now reverse the testing:

R7#mtrace 192.1.7.7 192.1.2.2
Type escape sequence to abort.
Mtrace from 192.1.7.7 to 192.1.2.2 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  192.1.2.2
-1  172.16.26.2 PIM  [192.1.7.0/24]
-2  172.16.26.6 PIM  [192.1.7.0/24]
-3  172.16.67.7 PIM  [192.1.7.0/24]
-4  192.1.7.7

This output indicates that there are no Reverse Path Forwarding errors in the path between the C-BSRs. With this confirmed, the next step in the process is to utilize debug ip pim bsr on all candidate-BSRs and the devices in the path between them.

R2#debug ip pim bsr
PIM-BSR(0): Bootstrap message for 192.1.2.2 originated
R6#debug ip pim bsr
PIM-BSR(0): 192.1.2.2 bootstrap forwarded on FastEthernet0/0
R7#debug ip pim bsr
PIM-BSR(0): bootstrap dropped

The verification clearly demonstrates that R2 generates a Bootstrap message. R6 forwards that Bootstrap message, and R7 drops it. This means that either there is a PIM neighborship issue or a filter/border/boundary command on R7. The FastEthernet0/0 interface of R7 is the only interface capable of receiving any BSR messages from R2 (192.1.2.2). The quickest method to verify this is to execute the show run interface FastEthernet0/0 command on R7:

R7#show run interface FastEthernet0/0
Building configuration...
Current configuration : 135 bytes
!
interface FastEthernet0/0
 ip address 172.16.67.7 255.255.255.0
 ip pim bsr-border
 ip pim sparse-mode
 duplex auto
 speed auto
end

The ip pim bsr-border command under the interface stops the BSR messages as they arrive at or exit R7. This has unquestionably isolated our fault.

Step 3 – Fault Remediation:

In this scenario, the ip pim bsr-border command needs to be removed.

R7(config)#interface FastEthernet0/0
R7(config-if)#no ip pim bsr-border

Step 4 – Verification of Remediation

Once the error has been isolated and remediated it is highly recommended to verify that the Trouble Ticket has been repaired using the same method of the initial fault verification.

R2#show ip pim bsr-router
PIMv2 Bootstrap information
 BSR address: 192.1.7.7 (?)
 Uptime:      00:01:51, BSR Priority: 255, Hash mask length: 0
 Expires:     00:01:18
This system is a candidate BSR
 Candidate BSR address: 192.1.2.2, priority: 200, hash mask length: 0

R7#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
 BSR address: 192.1.7.7 (?)
 Uptime:      04:14:14, BSR Priority: 255, Hash mask length: 0
 Next bootstrap message in 00:00:46

Both the C-BSRs agree that R7 is the BSR (based on the priority of 255), and R2 is continuing to announce itself as a C-BSR should R7 fail.

Trouble Ticket #2 Solution

After solving Trouble Ticket #1, your supervisor has observed that a new C-BSR (R5) that has just been introduced in the network does not agree with R2 and R7 regarding the identity of the Bootstrap Router. Correct this issue.

Step 1 – Fault Verification:
R2 and R7 are the C-BSRs that are of interest in this trouble ticket:

R2#show ip pim bsr-router
PIMv2 Bootstrap information
 BSR address: 192.1.7.7 (?)
 Uptime:      00:01:51, BSR Priority: 255, Hash mask length: 0
 Expires:     00:01:18
This system is a candidate BSR
 Candidate BSR address: 192.1.2.2, priority: 200, hash mask length: 0 

R7#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
 BSR address: 192.1.7.7 (?)
 Uptime:      04:14:14, BSR Priority: 255, Hash mask length: 0
 Next bootstrap message in 00:00:46

R5#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
 BSR address: 192.1.5.5 (?)
 Uptime:      04:15:26, BSR Priority: 255, Hash mask length: 0
 Next bootstrap message in 00:00:33

R2 and R7 agree that R7 is the BSR, but R5 is reporting itself as the BSR in the topology. This verifies that the problem actually exists.

Step 2 – Fault Isolation:

In order to verify that RPF issues are not at fault, use the mtrace utility. Perform this check in both directions, first from R2 toward R5, and then in reverse.

R2#mtrace 192.1.2.2 192.1.7.7
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 192.1.7.7 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  192.1.7.7
-1  172.16.67.7 PIM  [192.1.2.0/24]
-2  172.16.67.6 PIM  [192.1.2.0/24]
-3  172.16.26.2 PIM  [192.1.2.0/24]
-4  192.1.2.2 

R5#mtrace 192.1.5.5 192.1.2.2
Type escape sequence to abort.
Mtrace from 192.1.5.5 to 192.1.2.2 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  192.1.2.2
-1  172.16.24.2 PIM  [192.1.5.0/24]
-2  172.16.24.4 PIM  [192.1.5.0/24]
-3  172.16.45.5 PIM  [192.1.5.0/24]
-4  192.1.5.5

Next is the verification of the BSR messaging. Use the debug ip pim bsr command on R2, R4 and R5:

R2#debug ip pim bsr
PIM-BSR debugging is on
R2#
PIM-BSR(0): 192.1.7.7 bootstrap forwarded on Loopback0
PIM-BSR(0): 192.1.7.7 bootstrap forwarded on GigabitEthernet0/0

R2 is sending BSR announcements out the Gi0/0 interface directed to R4.

R4#debug ip pim bsr
PIM-BSR debugging is on
R4#
PIM-BSR(0): 192.1.7.7 bootstrap forwarded on Serial0/0/0.1
PIM-BSR(0): 192.1.7.7 bootstrap forwarded on Loopback0

We see that R4 is forwarding BSR messages from R7 out the Serial0/0/0.1 and on Loopback0, but not out FastEthernet 0/0 toward R5. The next step is to examine PIM neighbor relationships and inspect for multicast boundaries/filters.

R4#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
 S - State Refresh Capable
Neighbor            Interface                Uptime/Expires     Ver   DR
Address                                               Prio/Mode
172.16.24.2       FastEthernet0/0   22:34:25/00:01:23  v2    1 / S
172.16.46.6       Serial0/0.1       22:35:35/00:01:17  v2    1 / S
172.16.45.5       FastEthernet0/1   22:35:14/00:01:06  v1    1 / DR S

Looking carefully at this output on R4 demonstrates that PIM version 2 neighbor relationships have formed across the FastEthernet0/0 and Serial0/0/0.1 interfaces, but a PIM version 1 neighbor relationship has formed across FastEthernet0/1 toward R5. BSR requires the use of PIM-SM version 2 in order to operate. This has isolated our fault.

Step 3 – Fault Remediation:

In this scenario, ip pim version 2 needs to be configured between R4 and R5:

R4(config)#int f0/1
R4(config-if)#no ip pim version 1
R5(config)#int f0/1
R5(config-if)#no ip pim version 1

Step 4 – Verification of Remediation

Once the error has been isolated and remediated, it is highly recommended to verify that the Trouble Ticket has been repaired using the same method used to verify the fault initially:

R2#show ip pim bsr-router
PIMv2 Bootstrap information
 BSR address: 192.1.7.7 (?)
 Uptime:      00:36:11, BSR Priority: 255, Hash mask length: 0
 Expires:     00:01:58
This system is a candidate BSR
 Candidate BSR address: 192.1.2.2, priority: 200, hash mask length: 0

R7#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
 BSR address: 192.1.7.7 (?)
 Uptime:      04:48:37, BSR Priority: 255, Hash mask length: 0
 Next bootstrap message in 00:00:23 

R5#show ip pim bsr-router
PIMv2 Bootstrap information
 BSR address: 192.1.7.7 (?)
 Uptime:      00:02:06, BSR Priority: 255, Hash mask length: 0
 Expires:     00:02:03
This system is a candidate BSR
 Candidate BSR address: 192.1.5.5, priority: 250, hash mask length: 0

All three C-BSRs agree that R7 is the BSR.

Trouble Ticket #3 Solution

Your supervisor has notified you that R1 is not receiving any RP-set information from the BSR. You must correct this issue.

Step 1 – Fault Verification:
R1 is the router of interest in this trouble ticket:

R1#sh ip pim rp mapping
PIM Group-to-RP Mappings
R1#

R1 is not receiving the C-RP RP-set information from the BSR. This verifies that the problem actually exists.

Step 2 – Fault Isolation:

To ensure that BSR messages have made it to all PIM devices, use the mtrace utility. Make certain to perform this process from the C-RPs to the BSR.

R4#mtrace 192.1.4.4 192.1.7.7
Type escape sequence to abort.
Mtrace from 192.1.4.4 to 192.1.7.7 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  192.1.7.7
-1  172.16.67.7 PIM  [192.1.4.0/24]
-2  172.16.67.6 PIM  [192.1.4.0/24]
-3  172.16.26.2 PIM  [192.1.4.0/24]
-4  172.16.24.4 PIM  [192.1.4.0/24]
-5  192.1.4.4

There are no problems in the path from R4 to R7. Now repeat the test from R6 to R7:

R6#mtrace 192.1.6.6 192.1.7.7
Type escape sequence to abort.
Mtrace from 192.1.6.6 to 192.1.7.7 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  192.1.7.7
-1  172.16.67.7 PIM  [192.1.6.0/24]
-2  172.16.67.6 PIM  [192.1.6.0/24]
-3  192.1.6.6

This indicates that there are no RPF errors. Next, execute the debug ip pim bsr command on R1, R4, R5, R2, R6 and R7.

R1#debug ip pim bsr
PIM-BSR debugging is on
R1#
R1#

The output on R1 indicates it is not receiving any BSR messages on Fa0/0 from R5. On R5:

R5#debug ip pim bsr
PIM-BSR debugging is on
R5#
PIM-BSR(0): 192.1.7.7 bootstrap forwarded on Loopback0
PIM-BSR(0): 192.1.7.7 bootstrap forwarded on FastEthernet0/0
R5#

R5 is forwarding BSR messages from R7 out FastEthernet0/0 toward R1. The previous output on R1 indicated that no BSR messages are arriving. The next verification is to look for RPF failures on R1.

R1#sh ip rpf 192.1.7.7
RPF information for ? (192.1.7.7) failed, no route exists
R1#

The issue is an RPF failure on R1 toward R5. This is best verified by examining the PIM-SM neighbors on R1:

R1#sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
 S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
R1#

There is no neighbor relationship between R1 and R5. A show run interface FastEthernet0/0 command will reveal the issue.

R1#sh run interface FastEthernet 0/0
Building configuration...
Current configuration : 96 bytes
!
interface FastEthernet0/0
 ip address 172.16.15.1 255.255.255.0
 duplex auto
 speed auto
end

Looking carefully at this output on R1 demonstrates that PIM-SM version 2 is not enabled on FastEthernet0/0.

Step 3 – Fault Remediation:

In this scenario, ip pim sparse-mode needs to be configured on FastEthernet0/0.

R1(config)#int f0/0
R1(config-if)#ip pim sparse-mode
Step 4 - Verification of Remediation

Once the error has been isolated and remediated, it is highly recommended to verify that the Trouble Ticket has been repaired using the same method used to verify the fault initially.

R1#sh ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
 RP 192.1.6.6 (?), v2
 Info source: 192.1.7.7 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 00:00:15, expires: 00:02:13
 RP 192.1.4.4 (?), v2
 Info source: 192.1.7.7 (?), via bootstrap, priority 255, holdtime 150
 Uptime: 00:00:15, expires: 00:02:12

R1 now has the complete C-RP RP-set information as expected.

Print Friendly

Chapter Challenge: BSR Sample Trouble Tickets

The following section includes three sample Trouble Tickets designed to challenge the troubleshooting skills that have been developed in all previous sections of this chapter. These Trouble Tickets were designed using the Routing & Switching rental racks at www.ProctorLabs.com with the initial configurations provided in the file MCAST-CH9-BSR-TT-INITIAL.txt. Keep in mind these sample Trouble Tickets were also tested against home practice racks and the most popular router emulators.

The network topology used in this section is shown in Figure 9-10 below:

Figure 9-10: The Chapter Challenge Topology

Trouble Ticket #1

Your supervisor has brought to your attention that the C-BSR routers R2 and R7 do not agree on the identity of the BSR. You must correct the issue.

Trouble Ticket #2

After solving Trouble Ticket #1, your supervisor has observed that a new C-BSR (R5) that has just been introduced in the network does not agree with R2 and R7 regarding the identity of the Bootstrap Router. Correct this issue.

Trouble Ticket #3

Your supervisor has notified you that R1 is not receiving any RP-set information from the BSR. You must correct this issue.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly