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

Apologies for that Wouter thut that might be of help - apparently not.
i've tested the multicast-helper command on the subnet broadcast address, if
I recollect correctly I had to change the bcst addr under the router
interfaces facing the LAN (on both sides) + enabled directed broadcast
(both ends) + re-mapped TTL (at bcst source) + joined the group at remote
end (serial interface).
Test with NTP broadcast service.
Step back and take another look, must be something easily overlooked that
could be breaking it.
--------------------------------------------------
From: "Wouter Prins" <wp_at_null0.nl>
Sent: Tuesday, May 26, 2009 8:15 AM
To: "nAyYAR" <nyrhh_at_hotmail.co.uk>
Cc: <ccielab_at_groupstudy.com>
Subject: 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue May 26 2009 - 12:04:25 ART