Comments on: Understanding the IP Multicast Helper-Map Command

By: Proxy Tunnel

Proxy Tunnel — Mon, 16 Jun 2008 03:40:22 +0000

So has anyone other than the poster given this a try, if so what was your result ?

By: mpi

mpi — Tue, 03 Jun 2008 11:21:16 +0000

Thank you very much for the breakdown, is there a way you can do something similar for what they call router on a stick on multicast?

It will be great if you could explain the reachability issues for auto-rp with NBMA and all those ” weird” register-stop messages

By: Barooq

Barooq — Thu, 08 May 2008 23:39:38 +0000

Traceroute is UDP?

I really need some research :S
Anyway thanks a lot.

By: Brian McGahan, CCIE #8593

Brian McGahan, CCIE #8593 — Thu, 08 May 2008 20:21:45 +0000

As an alternative if your version doesn’t support broadcast SLA you can use extended traceroute:

Rack20R1#traceroute
Protocol [ip]:
Target IP address: 255.255.255.255
Source address: 173.20.12.1
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]: 1000
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]: 33434
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 255.255.255.255

By: Brian McGahan, CCIE #8593

Brian McGahan, CCIE #8593 — Thu, 08 May 2008 20:18:00 +0000

Barooq,

Apparently this was filed as a bug and changed. Per the bug toolkit:

CSCin97871 Bug Details
Invalid source address 255.255.255.255 accepted in all IP SLA probes

Symptom:
——-

Operation parameters such as the source-ipaddress and destination-ipaddress
can be configured using an all broadcast address as a valid input.
This is however incorrect as operations cannot currently handle responses
from multiple destinations for a single request.

Conditions:
———

No special conditions exist and all operations that include
source-ipaddress and/or destination-ipaddress accept the erronous input.

Workaround:
———-

Do not configure broadcast addresses for source and destination.

By: Brandon Carroll

Brandon Carroll — Thu, 08 May 2008 06:48:46 +0000

As always another informative post! I look forward to some security posts soon. Anything in the works?

By: Barooq

Barooq — Wed, 07 May 2008 20:17:19 +0000

Brian
I am unable to use Ip SLA monitor for testing purposes in 12.4 IOS as the command doesnt take a 255.255.255.255 address in destination address. While it works in 12.3 IOS.
The question is how can I test it if I get the IOS where I cant schedule SLA with destination address 255.255.255.255?

By: Brian McGahan, CCIE #8593

Brian McGahan, CCIE #8593 — Wed, 07 May 2008 19:36:28 +0000

No, R2 would act as the last hop router, with the “ip multicast helper-map 224.1.2.3″ followed by the directed broadcast of the link to R3. R3 would be the first hop router with the “ip multicast helper-map broadcast 224.1.2.3″ command on the link facing R2.

By: Nizami

Nizami — Wed, 07 May 2008 18:27:21 +0000

then R2 acts as first hop router.
on its interface to R3
ip multicast helper-map broadcast _GrAddr_ _ACL_

on R3 interace leading to R2
ip directed broadcast
on R3 interface leading to R4
ip multicast helper-map _GrAddr_ _broadcast address of segment between R2-R3_ _ACL_
am i right?

By: Brian McGahan, CCIE #8593

Brian McGahan, CCIE #8593 — Wed, 07 May 2008 15:43:42 +0000

It would be the same design logic. If you have SW1 sending a multicast to R2, R2 could convert this to a directed broadcast to the link to R3, then R3 could take the broadcast and convert it back into a multicast. The only thing that is changing is the placement of the first hop and last hop router.

By: Nizami

Nizami — Wed, 07 May 2008 05:38:26 +0000

thanks,Brian.Great explanation.
but what if we have
SW1-R1-R2-R3-R4-SW2

and PIM is enabled on all interfaces,except R3 interface leading to R2.
then how to use multicast-helper to get traffic from SW1 to SW2?