Damon, I'm afraid there is something wrong with your specific implementation. I, personally, can't think of an instance where a router doesn't respond to an icmp request on any of it's interfaces. Others, please chime in if that's inaccurate.
At any rate, I mocked it up in GNS3 to make sure there weren't any funky software bugs.
Basic configurations were set up on the interfaces with each router having it's router number as the
lo0 interface address (i.e. R1 -
22.214.171.124). For verification, here's the rip routing table.
R1#show ip route rip
126.96.36.199/32 is subnetted, 1 subnets
R 188.8.131.52 [120/1] via 10.1.1.2, 00:00:07, FastEthernet0/0
184.108.40.206/32 is subnetted, 1 subnets
R 220.127.116.11 [120/1] via 10.3.3.3, 00:00:26, FastEthernet0/1
10.0.0.0/24 is subnetted, 3 subnets
R 10.2.2.0 [120/1] via 10.3.3.3, 00:00:26, FastEthernet0/1
[120/1] via 10.1.1.2, 00:00:07, FastEthernet0/0
When pinging the multicast address of
18.104.22.168, 3 replys came back;
R2 sent a reply,
R3 sent a reply, and
R1 replied to itself because it is also listening for that address.
R1#debug ip icmp
ICMP packet debugging is on
R1#ping 22.214.171.124 source lo0 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 126.96.36.199, timeout is 2 seconds:
Packet sent with a source address of 188.8.131.52
*Mar 1 00:15:41.163: ICMP: echo reply sent, src 184.108.40.206, dst 220.127.116.11
*Mar 1 00:15:41.163: ICMP: echo reply rcvd, src 18.104.22.168, dst 22.214.171.124 <--- R1 Response
*Mar 1 00:15:41.179: ICMP: echo reply rcvd, src 10.1.1.2, dst 126.96.36.199 <--- R2 Response
*Mar 1 00:15:41.179: ICMP: echo reply rcvd, src 10.3.3.3, dst 188.8.131.52 <--- R3 Response
Reply to request 0 from 184.108.40.206, 8 ms
Reply to request 0 from 10.3.3.3, 24 ms
Reply to request 0 from 10.1.1.2, 20 ms
Pinging a multicast address will generate a response from participants listening to that address.
ip multicast-routingenabled on your routers?