6.2.b Implement, optimize and troubleshoot QoS using MQC

  • 6.2.b [ii] Network based application recognition [NBAR]
  • 6.2.b [iii] Marking using IP precedence, DSCP, CoS, ECN

ripv2

put nbar on f0/0 of r2

R2#sh run | sec 0/0
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
ip nbar protocol-discovery

ping r4

R4#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

look at nbar on r2

R2#sh ip nbar protocol-d proto icmp

FastEthernet0/0

Last clearing of “show ip nbar protocol-discovery” counters 00:05:45

Input                    Output
—–                    ——
Protocol                 Packet Count             Packet Count
Byte Count               Byte Count
5min Bit Rate (bps)      5min Bit Rate (bps)
5min Max Bit Rate (bps)  5min Max Bit Rate (bps)
———————— ———————— ————————
icmp                     0                        0
0                        0
0                        0
0                        0
Total                    15                       99

make a class map for icmp on r2

R2#sh class-map ICMP-CLASS
Class Map match-all ICMP-CLASS (id 1)
Match protocol  icmp

put a policy on the class to mark it with dscp

R2#sh policy-map
Policy Map ICMP-POLICY
Class ICMP-CLASS
set dscp af41

put a service policy input on the interface

R2#sh run int f0/0
Building configuration…

Current configuration : 147 bytes
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
ip nbar protocol-discovery
duplex full
service-policy input ICMP-POLICY

R2#sh policy-map int
FastEthernet0/0

Service-policy input: ICMP-POLICY

Class-map: ICMP-CLASS (match-all)
25 packets, 2850 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: protocol icmp
QoS Set
dscp af41
Packets marked 25

prove it with wireshark also

ws_dscp

 

 

 

 

3.4.a Implement and troubleshoot RIPv2

ripv2

rip v2 is on r3 and r2, eigrp is on r1, r2 and r4…

router rip
version 2
network 0.0.0.0

redistribution occurs on r2…

R2#sh run | sec router rip
router rip
version 2
redistribute eigrp 1 metric 5
network 192.168.23.0

R2#sh run | sec eigrp
router eigrp 1
network 192.168.12.0
network 192.168.24.0
 redistribute rip metric 1 1 255 255 1500

R1#sh ip route eigrp | b Gate
Gateway of last resort is not set

D EX  3.0.0.0/8 [170/2560002816] via 192.168.12.2, 00:11:23, FastEthernet0/0
4.0.0.0/24 is subnetted, 1 subnets
D        4.4.4.0 [90/158720] via 192.168.12.2, 00:12:35, FastEthernet0/0
D EX  192.168.23.0/24
           [170/2560002816] via 192.168.12.2, 00:11:23, FastEthernet0/0
D     192.168.24.0/24 [90/30720] via 192.168.12.2, 00:14:52, FastEthernet0/0

rip authentication like eigrp uses key chains…

R3#sh run | sec key
key chain RIP
key 1
key-string cisco

R2(config-if)#do sh run int f1/0
Building configuration…

Current configuration : 166 bytes
!
interface FastEthernet1/0
ip address 192.168.23.2 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain RIP

R3#debug ip rip
RIP protocol debugging is on
R3#
*Apr 17 14:37:23.399: RIP: sending v2 update to 224.0.0.9 via FastEthernet1/0 (192.168.23.3)
*Apr 17 14:37:23.399: RIP: build update entries
*Apr 17 14:37:23.403:   3.0.0.0/8 via 0.0.0.0, metric 1, tag 0
R3#
*Apr 17 14:37:25.399: RIP: sending v2 update to 224.0.0.9 via Loopback0 (3.3.3.3)
*Apr 17 14:37:25.399: RIP: build update entries
*Apr 17 14:37:25.403:   1.0.0.0/8 via 0.0.0.0, metric 6, tag 0
*Apr 17 14:37:25.403:   4.0.0.0/8 via 0.0.0.0, metric 6, tag 0
*Apr 17 14:37:25.407:   192.168.12.0/24 via 0.0.0.0, metric 6, tag 0
*Apr 17 14:37:25.411:   192.168.23.0/24 via 0.0.0.0, metric 1, tag 0
*Apr 17 14:37:25.411:   192.168.24.0/24 via 0.0.0.0, metric 6, tag 0
*Apr 17 14:37:25.423: RIP: ignored v2 packet from 3.3.3.3 (sourced from one of our addresses)
R3#
*Apr 17 14:37:36.311: RIP: received packet with MD5 authentication
*Apr 17 14:37:36.311: RIP: received v2 update from 192.168.23.2 on FastEthernet1/0
*Apr 17 14:37:36.315:      1.0.0.0/8 via 0.0.0.0 in 5 hops
*Apr 17 14:37:36.315:      4.0.0.0/8 via 0.0.0.0 in 5 hops
*Apr 17 14:37:36.319:      192.168.12.0/24 via 0.0.0.0 in 5 hops
*Apr 17 14:37:36.319:      192.168.24.0/24 via 0.0.0.0 in 5 hops
R3#un all
All possible debugging has been turned off

 

3.5.f [ii] unequal-cost (EIGRP)

note: the bandwidth of the interfaces have been artificially adjusted for illustration

eigrp_unequal_costs

r1#sh ip proto
Routing Protocol is “eigrp 123″
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 123
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
0.0.0.0
Routing Information Sources:
Gateway         Distance      Last Update
(this router)         90      00:34:41
192.168.2.2           90      00:01:20
192.168.3.2           90      00:01:20
192.168.1.2           90      00:01:20
Distance: internal 90 external 170

r1#sh ip eigrp topo
IP-EIGRP Topology Table for AS(123)/ID(1.1.1.1)

Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status

P 1.1.1.0/24, 1 successors, FD is 128256
via Connected, Loopback0
P 3.3.3.0/24, 1 successors, FD is 3142400
via 192.168.1.2 (3142400/156160), Serial0/0
via 192.168.2.2 (5642496/156160), Serial0/1
via 192.168.3.2 (20642560/156160), Serial0/2

the feasible distance is established at 3142400, hence s0/0 is the successor route.  for s0/1 the feasible distance is nearly twice that of s0/0.

since the default variance is 1, the ip routing table will only display the successor.

if the variance is doubled (2 X 3142400) the ip routing table will now recognize near equal cost routes:

r1(config-router)#do sh run | b router
router eigrp 123
variance 2
network 0.0.0.0
no auto-summary

r1(config-router)#do sh ip route | b Gate
Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
3.0.0.0/24 is subnetted, 1 subnets
D       3.3.3.0 [90/5642496] via 192.168.2.2, 00:01:06, Serial0/1
                [90/3142400] via 192.168.1.2, 00:01:06, Serial0/0

3.1.b Identify, implement and troubleshoot IPv6 addressing and subnetting

The two all zeros

::/0 default address

::/128 unspecified

A Global Unicast is a unicast address that is globally unique (Aunicast address identifies a single device)

Link Local Unicast is an address whose scope is confined to a single link; non-routable

Anycast address represents a service rather than a device and often appears on multiple devices

Multicast addresses identify a set of devices; multicast group

A multicast packet has a unicast address as the source with a multicast address as it’s destination. A multicast address can never appear as a packet’s source address

The all nodes multicast is the same as ipv4 broadcast

http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6_basic/configuration/15-mt/ip6-uni-routing.html#GUID-F02E803E-C395-484A-82B3-22F79CCB2279

3.5.f [i] equal-cost (EIGRP)

eigrp_equal_cost

equal cost over two paths from r1 to network 192.168.23.0/24…

r1#sh ip route 192.168.23.0
Routing entry for 192.168.23.0/24
Known via “eigrp 1″, distance 90, metric 30720, type internal
Redistributing via eigrp 1
Last update from 192.168.12.2 on FastEthernet0/0, 00:05:49 ago
Routing Descriptor Blocks:
* 192.168.13.3, from 192.168.13.3, 00:05:49 ago, via FastEthernet1/0
Route metric is 30720, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
192.168.12.2, from 192.168.12.2, 00:05:49 ago, via FastEthernet0/0
Route metric is 30720, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

this can also be viewed from the topology table…

r1#sh ip eigrp topo 192.168.23.0
IP-EIGRP (AS 1): Topology entry for 192.168.23.0/24
State is Passive, Query origin flag is 1, 2 Successor(s), FD is 30720
Routing Descriptor Blocks:
192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0×0
Composite metric is (30720/28160), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
192.168.13.3 (FastEthernet1/0), from 192.168.13.3, Send flag is 0×0
Composite metric is (30720/28160), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

eigrp defaults load sharing across equal cost paths…

r1#sh ip route | b Gate
Gateway of last resort is not set

C    192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
C    192.168.13.0/24 is directly connected, FastEthernet1/0
2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/156160] via 192.168.12.2, 00:10:07, FastEthernet0/0
3.0.0.0/24 is subnetted, 1 subnets
D       3.3.3.0 [90/156160] via 192.168.13.3, 00:10:07, FastEthernet1/0
D    192.168.23.0/24 [90/30720] via 192.168.13.3, 00:10:09, FastEthernet1/0
                     [90/30720] via 192.168.12.2, 00:10:09, FastEthernet0/0

3.5.d [i] General operations

  • 3.5.d [ii] Topology table, update, query, active, passive
  • 3.5.d [iii] Stuck in active

Simulataneous Router Discovery/Route Exchange

 

Router comes up and sends hellos

Reply from neighbor includes update

Acks are sent

Update process occurs in the opposite direction

 

eigrp

 

EIGRP DUAL

 

The lowest cost route is calculated by adding the cost between the next hop router and the destination (Reported Distance, RD), and the cost between the local router and the next hop. This sum is the Feasible Distance (FD).

feasibledistance

 

The successor is the next hop router to the destination that the local router has chosen. Multiple successors may exist if they provide equal cost paths.

 

If a backup path to the destination exists it may become a feasible successor. To qualify, this next hop router must report an RD that is less than the FD of the successor.

feasiblesuccessor2

In the above diagram, the successor is the route through the NextHop because the feasible distance is 1 + 1, the least cost path to the destination. The route through the Backup becomes a feasible successor because its RD of 1 is less than the FD of the successor, thus meeting the Feasibility Condition, RD<FD. In this case, the least cost path (LocalRouter to NextHop to Destination) will be the only route represented in the IP Routing Table. The Backup path however, will be represented as a Feasible Successor in the EIGRP Topology table.

 

Note: in the above diagram the cost values are artificial representations of a dual metric for simplicity. The actual calculated metric is much more complex. For instance, all things being equal the topology below creates 2 equal cost paths to the destination router’s loopback, 4.4.4.4/24

 

LocalRouter#sh ip route eigrp

4.0.0.0/24 is subnetted, 1 subnets

D 4.4.4.0 [90/154112] via 192.168.13.3, 00:28:28, FastEthernet1/0

[90/154112] via 192.168.12.2, 00:28:28, FastEthernet0/0

D 192.168.24.0/24 [90/26112] via 192.168.12.2, 00:28:28, FastEthernet0/0

D 192.168.34.0/24 [90/26112] via 192.168.13.3, 00:28:28, FastEthernet1/0

90 is the AD of Eigrp, and 154112 is the calculated metric (equal cost paths in this case, therefore both reside in the IP Routing table and will be load balanced)

eigrp_net

LocalRouter#sh ip eigrp topo

(truncated)

 

P 4.4.4.0/24, 2 successors, FD is 154112

via 192.168.13.3 (154112/153856), FastEthernet1/0

via 192.168.12.2 (154112/153856), FastEthernet0/0

 

To create the scenario in the earlier topology use the delay command in interface configuration mode (delay is the recommended method for manipulation).

 

LocalRouter(config-if)#int f1/0 (connection to Backup in the diagram)

LocalRouter(config-if)#delay 3

 

LocalRouter#sh ip route eigrp

4.0.0.0/24 is subnetted, 1 subnets

D 4.4.4.0 [90/154112] via 192.168.12.2, 00:02:04, FastEthernet0/0

D 192.168.24.0/24 [90/26112] via 192.168.12.2, 00:02:04, FastEthernet0/0

D 192.168.34.0/24 [90/26368] via 192.168.12.2, 00:02:04, FastEthernet0/0

 

 

LocalRouter#sh ip eigrp topo

IP-EIGRP Topology Table for AS(1)/ID(192.168.12.1)

 

Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,

r – reply Status, s – sia Status

 

P 4.4.4.0/24, 1 successors, FD is 154112

via 192.168.12.2 (154112/153856), FastEthernet0/0

via 192.168.13.3 (154624/153856), FastEthernet1/0

 

Note: the feasibility condition has been met RD<FD.

 

All of this means that if the successor route goes down, the feasible successor will assume responsibilty for the destination without a query, it simply gets promoted to the IP Routing Table.

 

LocalRouter(config-if)#shut

LocalRouter(config-if)#

*Mar 1 03:11:24.311: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.12.2 (FastEthernet0/0) is down: interface down

LocalRouter(config-if)#

*Mar 1 03:11:26.295: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down

*Mar 1 03:11:27.295: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

LocalRouter(config-if)#do sh ip route eigrp

D 192.168.12.0/24 [90/27136] via 192.168.13.3, 00:00:15, FastEthernet1/0

4.0.0.0/24 is subnetted, 1 subnets

D 4.4.4.0 [90/154624] via 192.168.13.3, 00:00:15, FastEthernet1/0

D 192.168.24.0/24 [90/26880] via 192.168.13.3, 00:00:15, FastEthernet1/0

D 192.168.34.0/24 [90/26624] via 192.168.13.3, 00:00:15, FastEthernet1/0

 

If the interface recovers, that route with its better metric returns to the IP Routing table as successor.

 

LocalRouter(config-if)#no shut

LocalRouter(config-if)#

*Mar 1 03:13:07.139: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

LocalRouter(config-if)#

*Mar 1 03:13:07.727: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacency

*Mar 1 03:13:08.139: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

LocalRouter(config-if)#do sh ip route eigrp

4.0.0.0/24 is subnetted, 1 subnets

D 4.4.4.0 [90/154112] via 192.168.12.2, 00:00:04, FastEthernet0/0

D 192.168.24.0/24 [90/26112] via 192.168.12.2, 00:00:04, FastEthernet0/0

D 192.168.34.0/24 [90/26368] via 192.168.12.2, 00:00:04, FastEthernet0/0

 

EIGRP Queries

 

Passive is the stable condition for a route, as below.

 

LocalRouter#sh ip eigrp topo

IP-EIGRP Topology Table for AS(1)/ID(192.168.12.1)

 

Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,

r – reply Status, s – sia Status

 

P 4.4.4.0/24, 1 successors, FD is 154112

 

If there is a change in the topology as was demonstrated above, EIGRP will check for the presence of a feasible successor. If one is not found, a query will be initiated. This is known as going active. When a route becomes active the router multicasts queries to its neighbors for a valid route to the subnet. A neighbor receiving such a query

 

A note on auto-summary:

Command History

 

Release

Modification

10.0

This command was introduced.

12.2(8)T

The command default behavior changed to disabled.

 

Remember to check the version of EIGRP in use. Prior to 12.2(8)T the no auto-summary command was necessary for EIGRP to be used classlessly (VLSM).

 

 

 

3.5.c [ii] Classic metric

Composite Metric

 

EIGRP uses a composite metric of bandwidth and delay by default similar to IGRP but modifed by a factor of 256. This combination is known as the feasible distance. http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#eigrpmetrics

 

Although bandwidth and delay are the recommended values commonly used for manipulation, there are a total of 5:

 

Bandwidth: in kilobytes, a value that can be adjusted per interface using the bandwidth command. Use with caution as this can affect other protocols as well.

 

Delay: in microseconds, adjusted using the delay command. Delay is the preferred value adjustment.

 

Reliability: as an integer value between 1 and 255. 1 is unreliable; 255 most reliable.

 

Load: as an integer value between 1 and 255. 1 is least loaded.

 

MTU: as a byte value; the least value recorded in the path. MTU is maximum transmission unit and is not used in the calculation.

 

Default integer values:

 

K1 = 1 K2 = 0 K3 = 1 K4 = 0 K5 = 0

 

Metric calculation (actual):

 

metric = [K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]

 

Equation after default K5 (0) value:

 

[K1 * bandwidth + (K2 * bandwidth)/(256 - load) + K3 * delay]

 

And further given K2 = 0 (per the default):

 

metric = bandwidth + delay

 

Important; the reasons an EIGRP adjacency will not form other than a physical link problem:

 

Mismatched AS, not in the same subnet and mismatched K values.

 

3.5.c [iii] Wide metric

from:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/15-sy/ire-15-sy-book/ire-wid-met.html#GUID-080B6671-721F-4286-B198-90C8D74A1211

EIGRP Wide Metrics

The Enhanced Interior Gateway Routing Protocol (EIGRP) composite cost metric (calculated using the bandwidth, delay, reliability, load, and K values) is not scaled correctly for high-bandwidth interfaces or Ethernet channels, resulting in incorrect or inconsistent routing behavior. The lowest delay that can be configured for an interface is 10 microseconds. As a result, high-speed interfaces, such as 10 Gigabit Ethernet (GE) interfaces, or high-speed interfaces channeled together (GE ether channel) will appear to EIGRP as a single GE interface. This may cause undesirable equal-cost load balancing. To resolve this issue, the EIGRP Wide Metrics feature supports 64-bit metric calculations and Routing Information Base (RIB) scaling that provide the ability to support interfaces (either directly or via channeling techniques like port channels or ether channels) up to approximately 4.2 terabits.

Note

The 64-bit metric calculations work only in EIGRP named mode configurations. EIGRP classic mode uses 32-bit metric calculations.


To accommodate interfaces with bandwidths above 1 gigabit and up to 4.2 terabits and to allow EIGRP to perform path selections, the EIGRP composite cost metric formula is modified. The paths are selected based on the computed time. The time that information takes to travel through links is measured in picoseconds. The interfaces can be directly capable of these high speeds, or the interfaces can be bundles of links with an aggregate bandwidth greater than 1 gigabit.

Metric = [(K1*Minimum Throughput + {K2*Minimum Throughput} / 256-Load) + (K3*Total Latency) + (K6*Extended Attributes)]* [K5/(K4 + Reliability)]

Default K values are as follows:

  • K1 = K3 = 1
  • K2 = K4 = K5 = 0
  • K6 = 0

The EIGRP Wide Metrics feature also introduces K6 as an additional K value for future use.

By default, the path selection scheme used by EIGRP is a combination of throughput (rate of data transfer) and latency (time taken for data transfer), and the formula for calculating the composite cost metric is as follows:

Composite Cost Metric = (K1*Minimum Throughput) + (K3*Total Latency)

Minimum Throughput = (107* 65536)/Bw), where 65536 is the wide-scale constant.

Total Latency for bandwidths below 1 gigabit = (Delay*65536)/10, where 65536 is the wide-scale constant.

Total Latency for bandwidths above 1 gigabit = (107* 65536/10)/ Bw, 65536 is the wide-scale constant.

3.5.c [ii] Classic metric

from:

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enhanced-interior-gateway-routing-protocol-eigrp/whitepaper_C11-720525.html

• Delay (measured in 10s of microseconds)

• Bandwidth (measured in kilobytes per second)

• Reliability (in numbers ranging from 1 to 255; 255 being the most reliable)

• Load (in numbers ranging from 1 to 255; 255 being saturated)

Various constants (K 1 through K 5) are able to be set by a user to produce varying routing behaviors. However by default, only delay and bandwidth are used in the weighted formula to produce a single 32bit metric:

 

 

Note: Default K values are: K1 = K3 = 1 and K2 = K4 = K5 = 0
When K5 is equal to 0 then [K5/( K4 + reliability)] is defined to be 1

Use of the default constants effectively reduces the formula above to:

3.2.b Implement and troubleshoot IPv4 protocol independent multicast

and 1.1b cef…

ccieordie_pim

note the below output:

r1#sh ip route 192.168.46.6
Routing entry for 192.168.46.0/24
Known via “ospf 1″, distance 110, metric 3, type intra area
Last update from 192.168.13.3 on FastEthernet1/0, 00:52:16 ago
Routing Descriptor Blocks:
192.168.13.3, from 6.6.6.6, 00:52:16 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1
* 192.168.12.2, from 6.6.6.6, 00:52:16 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1

http://ccieordie.com/?p=365

There is also an asterisk (*) next to one of the block entries. This corresponds to the active route that is used for new traffic.

i wouldn’t be so sure about this… ospf can load balance across equal paths, although it actually relies on cef to achieve this…

the trace from r5 to r6 is always preferring the route through r3…

this is where this command becomes useful to get the true picture of what cef is doing:

r1#sh ip cef exact-route 192.168.12.1 192.168.46.6
192.168.12.1    -> 192.168.46.6   : FastEthernet0/0 (next hop 192.168.12.2)
r1#sh ip cef exact-route 192.168.13.1 192.168.46.6
192.168.13.1    -> 192.168.46.6   : FastEthernet0/0 (next hop 192.168.12.2)
r1#sh ip cef exact-route 192.168.15.1 192.168.46.6
192.168.15.1    -> 192.168.46.6   : FastEthernet1/0 (next hop 192.168.13.3)

if pim is disabled on r3 (either interface) the rpf will fail…

unicast routing is still fine:

R5#trace 192.168.46.6

Type escape sequence to abort.
Tracing the route to 192.168.46.6

1 192.168.15.1 16 msec 20 msec 12 msec
2 192.168.13.3 28 msec 36 msec 28 msec
3 192.168.34.4 52 msec 44 msec 52 msec
4 192.168.46.6 60 msec 48 msec 72 msec

R5#mtrace 192.168.15.5 192.168.46.6 224.1.1.1
Type escape sequence to abort.
Mtrace from 192.168.15.5 to 192.168.46.6 via group 224.1.1.1
From source (?) to destination (?)
Querying full reverse path…
0  192.168.46.6
-1  192.168.24.4 PIM  [192.168.15.0/24]
-2  192.168.34.3 None Multicast disabled [192.168.15.0/24]

that’s fairly obvious… but sh ip rpf isn’t being truthful:

r1#sh ip rpf 192.168.46.6
RPF information for ? (192.168.46.6)
RPF interface: FastEthernet1/0
RPF neighbor: ? (192.168.13.3)
RPF route/mask: 192.168.46.0/24
RPF type: unicast (ospf 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables

turning pim back on r3 int f1/0:

R5#mtrace 192.168.46.6
Type escape sequence to abort.
Mtrace from 192.168.46.6 to 192.168.15.5 via RPF
From source (?) to destination (?)
Querying full reverse path…
0  192.168.15.5
-1  192.168.15.5 PIM  [192.168.46.0/24]
-2  192.168.15.1 PIM  [192.168.46.0/24]
-3  192.168.13.3 PIM  [192.168.46.0/24]
-4  192.168.34.4 PIM  [192.168.46.0/24]
-5  192.168.46.6