Re: how to properly verify a broadcast to multicast-helper?

Hi,

Thanks for the responses.
I saw this blog but i cannot configure the udpecho to be send to
255.255.255.255, that's why i came here. ;)

RSRack1R6(config-sla-monitor)#type udpEcho dest-ipaddr ?
  Hostname or A.B.C.D IP address or hostname, broadcast disallowed

What would the reason be that my broadcast isnt being converted with my
current config?
Afaik i configured everything correctly. Does the ip multicast helper-map
only work on 255.255.255.255 or something?

2009/5/26 nAyYAR <nyrhh_at_hotmail.co.uk>

>
> Hi,
>
> Have a look on the IE blog, it discusses the test options and config. Great
> detail there.
>
>
> http://blog.internetworkexpert.com/2008/05/06/understanding-the-ip-multicast-helper-map-command/
>
> Cheers.
> --------------------------------------------------
> From: "Wouter Prins" <wp_at_null0.nl>
> Sent: Monday, May 25, 2009 7:48 PM
> To: "Cisco certification" <ccielab_at_groupstudy.com>
> Subject: how to properly verify a broadcast to multicast-helper?
>
> hey all,
>>
>> i was wondering how you can verify a broadcast to multicast helper-map? i
>> labbed this up and i noticed that i cannot send an ip sla with a udpecho
>> to
>> the broadcast address (255.255.255.255) as this is disallowed.
>>
>> So i thought i would send the udpecho to the ip broadcast address of that
>> subnet: 174.1.26.255 and it is properly send out:
>>
>> *Mar 1 02:22:52.391: UDP: Random local port generated 49538, network 1
>> *Mar 1 02:22:52.395: Reserved port 49538 in Transport Port Agent for UDP
>> IP
>> type 1
>> *Mar 1 02:22:52.395: UDP: sent src=174.1.26.6(49538),
>> dst=174.1.26.255(3434), length=24
>>
>> Now on the router configured for the broadcast to multicast conversion i
>> configured the following on the interface receiving these udpecho's:
>>
>> RSRack1R2#
>> interface FastEthernet0/0
>> description "facing ip sla router"
>> ip address 174.1.26.2 255.255.255.0
>> ip broadcast-address 174.1.26.255
>> ip pim sparse-mode
>> ip multicast helper-map broadcast 226.26.26.26 100
>> no ip mroute-cache
>> end
>> interface Serial1/0
>> description "this interface should have the converted broadcast"
>> ip address 174.1.23.2 255.255.255.0
>> ip pim sparse-mode
>> no ip mroute-cache
>> frame-relay map ip 174.1.23.3 203 broadcast
>> no frame-relay inverse-arp
>> end
>>
>> RSRack1R2#show access-list 100
>> Extended IP access list 100
>> 10 permit udp any any eq 3434
>> RSRack1R2#show run | incl forward
>> ip forward-protocol nd
>> ip forward-protocol udp 3434
>> RSRack1R2#show deb
>> Generic IP:
>> IP multicast packets debugging is on
>> UDP:
>> UDP packet debugging is on
>> RSRack1R2#
>> RSRack1R2#show ip pim rp-hash 226.26.26.26
>> RP 150.1.1.1 (?), v2v1
>> Info source: 150.1.3.3 (?), elected via Auto-RP
>> Uptime: 01:35:23, expires: 00:02:53
>> PIMv2 Hash Value (mask 0.0.0.0)
>> RP 150.1.1.1, via Auto-RP
>> RSRack1R2#show ip rpf 150.1.1.1
>> RPF information for ? (150.1.1.1)
>> RPF interface: Serial1/0
>> RPF neighbor: ? (174.1.23.3)
>> RPF route/mask: 150.1.1.0/24
>> RPF type: unicast (ospf 1)
>> RPF recursion count: 0
>> Doing distance-preferred lookups across tables
>> RSRack1R2#
>>
>> I dont see any packets being forwarded (RP-mappings are fine and no RPF
>> failures occuring).
>>
>> Anyone who has a better idea on verifying this and perhaps why this is not
>> working? :)
>>
>> --
>> Wouter Prins
>> wp_at_null0.nl
>> 0x301FA912
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>>

-- 
Wouter Prins
wp_at_null0.nl
0x301FA912
Blogs and organic groups at http://www.ccie.net