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

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

BSR debug Command Tools

As a quick reference, here are the debug command tools utilized in this chapter. This section utilizes the BSR topology in Figure 9-9 for all example output.

Figure 9-9: A Sample BSR Topology

debug COMMAND:
debug ip mpacket [vrf vrf-name] [detail | fastswitch] [access-list] [group]

This command displays multicast packets that are received and sent on the device.

Where:

• vrf – optional; specifies the name of the multicast VRF instance
• detail – optional; displays IP header and MAC information
• fastswitch – optional; displays IP packet information in the fast path
• access-list – optional; restricts the output per the specified access-list

EXAMPLE OUTPUT:
IP(0): s=172.16.24.4 (FastEthernet0/0) d=224.9.9.9 id=7, ttl=254, prot=1, len=114(100), mroute olist nullIP(0): s=172.16.24.4 (FastEthernet0/0) d=224.9.9.9 id=8, ttl=254, prot=1, len=114(100), mroute olist null
IP(0): s=172.16.24.4 (FastEthernet0/0) d=224.9.9.9 id=9, ttl=254, prot=1, len=114(100), mroute olist null

debug COMMAND:
debug ip pim [vrf vrf-name] [bsr]

This command displays the mappings for the PIM group to the active Rendezvous Point(s).

Where:

• vrf – optional; specifies the name of the multicast VRF instance

EXAMPLE OUTPUT:
R4#debug ip pim bsr
PIM-BSR debugging is on
R4#
PIM-BSR(0): 192.1.2.2 bootstrap forwarded on FastEthernet0/1
PIM-BSR(0): 192.1.2.2 bootstrap forwarded on Serial0/0/0.1
PIM-BSR(0): bootstrap (192.1.2.2) on non-RPF path Serial0/0/0.1 or from non-RPF neighbor 172.16.24.2 discarded 

R2#debug ip pim bsr
PIM-BSR(0): RP-set for 224.0.0.0/4
PIM-BSR(0):   RP(1) 192.1.7.7, holdtime 150 sec priority 0
PIM-BSR(0):   RP(2) 192.1.5.5, holdtime 150 sec priority 0
PIM-BSR(0): Bootstrap message for 192.1.2.2 originated
R2#
PIM-BSR(0):  RP 192.1.5.5, 1 Group Prefixes, Priority 0, Holdtime 150
R2#
PIM-BSR(0):  RP 192.1.7.7, 1 Group Prefixes, Priority 0, Holdtime 150
R2# 

R5#debug ip pim bsr
PIM-BSR(0): Build v2 Candidate-RP advertisement for 192.1.5.5 priority 0, holdtime 150
PIM-BSR(0):  Candidate RP's group prefix 224.0.0.0/4
PIM-BSR(0): Send Candidate RP Advertisement to 192.1.2.2
R5#

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

Print Friendly

BSR show Command Tools

As a quick reference, here are the show command tools utilized in this chapter. This section utilizes the BSR topology in Figure 9-8 for all example output.

Figure 9-8: A Sample BSR Topology

show COMMAND:

show ip pim [vrf vrf-name] bsr-router

This command displays information about a bootstrap router (BSR)

Where:

• vrf – optional; specifies the name of the multicast VRF instance

EXAMPLE OUTPUT:
R1#show ip pim bsr-router
PIMv2 Bootstrap information
 BSR address: 192.1.2.2 (?)
 Uptime:      00:26:57, BSR Priority: 0, Hash mask length: 0
 Expires:     00:01:12

show COMMAND:
show ip pim [vrf vrf-name] rp-hash {group-address | group-name}

This command displays the mappings for the PIM group to the active Rendezvous Point(s).

Where:

• vrf – optional; specifies the name of the multicast VRF instance
• group-address – the multicast group address

EXAMPLE OUTPUT:
 R4#show ip pim rp-hash 224.9.9.9
 RP 192.1.7.7 (?), v2
 Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 03:32:33, expires: 00:01:27
 PIMv2 Hash Value (mask 0.0.0.0)
 RP 192.1.7.7, via bootstrap, priority 0, hash value 390961567
 RP 192.1.5.5, via bootstrap, priority 0, hash value 119808709

show COMMAND:
show ip pim [vrf vrf-name] rp mapping [rp-address]

This command displays the mappings for the PIM group to the active Rendezvous Point(s).

Where:

• vrf – optional; specifies the name of the multicast VRF instance
• rp-address – optional; allows the specification of a specific RP IP address in order to filter the output

EXAMPLE OUTPUT:
 R4#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.1.7.7 (?), v2
Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 03:45:33, expires: 00:01:29
RP 192.1.5.5 (?), v2
Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 03:45:47, expires: 00:01:30

show COMMAND:

show ip rpf [vrf vrf-name] {route-distinguisher | source-address [group-address] [rd route-distinguisher]} [metric]

This command displays information that IP multicast routing uses to perform the Reverse Path Forwarding (RPF) check for a multicast source

Where:

• vrf – optional; specifies the name of the multicast VRF instance
• route-distinguisher - Route distinguisher (RD) of a VPNv4 prefix; entering the route-distinguisher argument displays RPF information related to the specified VPN route
• source-address - IP address or name of a multicast source for which to display RPF information
• group-address - optional; IP address or name of a multicast group for which to display RPF information
• rd route-distinguisher - optional; displays the Border Gateway Protocol (BGP) RPF next hop for the VPN route associated with the RD specified for the route-distinguisher argument
• metric - optional; displays the unicast routing metric

EXAMPLE OUTPUT:
 R5#show ip rpf 192.1.2.2
RPF information for ? (192.1.2.2)
 RPF interface: FastEthernet0/1
 RPF neighbor: ? (172.16.45.4)
RPF route/mask: 192.1.2.0/24
 RPF type: unicast (eigrp 100)
 RPF recursion count: 0
 Doing distance-preferred lookups across tables

show COMMAND:

show ip pim [vrf vrf-name] neighbor [interface-type interface-number]

This command displays information about Protocol Independent Multicast (PIM) neighbors discovered by PIM version 1 router query messages or PIM version 2 hello messages.

Where:

• vrf – optional; specifies the name of the multicast VRF instance
• interface-type – optional; restricts the output to information about PIM neighbors reachable on the specified interface

EXAMPLE OUTPUT:
 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.45.5 FastEthernet0/1 01:17:41/00:01:25 v2    1 / DR S
172.16.46.6 Serial0/0/0.1   01:16:39/00:01:19 v2    1 / S

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

Print Friendly

Section 1 General Networking
1.10 Networking Basics

1.11 IPv4
1.12 IPv6

1.20 OSI Layers
1.30 TCP/IP Protocols

1.31 TCP
1.32 UDP
1.33 ICMP
1.34 ARP

1.40 LAN Switching

1.41 VTP
1.42 VLANs
1.43 Spanning Tree
1.44 Trunking

1.50 Routing Protocols

1.51 RIP
1.52 EIGRP
1.53 OSPF
1.54 BGP

1.60 Tunneling Protocols

1.61 GRE
1.62 NHRP

1.70 IP Multicast

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

Print Friendly

	What’s included in our CCIE R&S Bundle Promotion? CCIE R&S 4.0 Lab Preparation Workbook, Volume 1 (eBook) Detailed Solution Guide, CCIE R&S Volume 1 (eBook) CCIE R&S 4.0 Lab Preparation Workbook, Volume 2 (eBook) Detailed Solution Guide, CCIE R&S Volume 2 (eBook) CCIE R&S 4.0 Lab Preparation Workbook, Volume 3 (eBook) Detailed Solution Guide, CCIE R&S Volume 3 (eBook) CCIE R&S 4.0 Lab Video On Demand (Streaming) Student Handbook for CCIE R&S VOD (eBook) Topology Book for CCIE R&S VOD (eBook) 25 – 8 Hour CCIE R&S vRack Vouchers Retail Price: $2246 Weekend Promotion Price $699
	What’s included in our CCIE Voice Bundle Promotion? CCIE Voice 3.0 Lab Preparation Workbook, Volume 1 (eBook) Detailed Solution Guide, CCIE Voice Volume 1 (eBook) CCIE Voice 3.0 Lab Preparation Workbook, Volume 2 (eBook) Detailed Solution Guide, CCIE Voice Volume 2 (eBook) CCIE Voice 3.0 Lab Video On Demand (Streaming) Student Handbook for CCIE Voice VOD (eBook) Topology Book for CCIE Voice VOD (eBook) 25 – 8 Hour CCIE Voice vRack Vouchers Retail Price $2296 Weekend Promotion Price $799
	What’s included in our CCIE Security Bundle Promotion? CCIE Security 3.0 Lab Preparation Workbook, Volume 1 (eBook) Detailed Solution Guide, CCIE Security Volume 1 (eBook) CCIE Security 3.0 Lab Preparation Workbook, Volume 2 (eBook) Detailed Solution Guide, CCIE Security Volume 2 (eBook) CCIE Security 3.0 Lab Video On Demand (Streaming) Student Handbook for CCIE Security VOD (eBook) Topology Book for CCIE Security VOD (eBook) 25 – 8 Hour CCIE Security vRack Vouchers Retail Price $2047 Weekend Promotion Price $699

Note:

• Offer ends Monday, January 23rd, 2011 at 5:00 PM EST
• Valid for all new orders only, and orders must be placed through website (not called in or ordered via telephone).
• Cannot be combined with any other promotion or discount.
• Video on Demand Course & vRacks will be issued to your account Monday morning.

Print Friendly