Task 5.1 - Mcast helper map, did yours work?

Hi Guys,

Did anyone/everyone get this working? It was re-assuring to see that the solution guide mirrored both the config and verification methods I used, but mine doesn't work. The mcast arrives at R3 but debugging at R3 and R2 shows now broadcasts coming through. Not sure what I could be missing and can't think of how to troubleshoot any more than the SG does. I can ping the 129.1.23.255 address and the other side responds, so broadcast is ok across the link. Mcast is arriving at R3 ok as per the debugs, just no broadcasts being sent or received across the link...


R3


interface Serial1/2
 ip address 129.1.13.3 255.255.255.0
 ip pim dense-mode
 ip multicast helper-map 225.25.25.25 129.1.23.255 Mcast2Bcast
 encapsulation ppp
 ppp authentication pap


interface Serial1/3
 ip address 129.1.23.3 255.255.255.0
 ip directed-broadcast
 encapsulation ppp
 ppp authentication pap

Extended IP access list Mcast2Bcast
    10 permit udp any any eq 31337

ip forward-protocol udp 31337

R2

interface Serial0/1
 ip address 129.1.23.2 255.255.255.0
 ip pim dense-mode
 ip multicast helper-map broadcast 225.25.25.25 Mcast2Bcast
 encapsulation ppp
 no ip mroute-cache
 ppp pap sent-username PPP password 0 CISCO


Extended IP access list Mcast2Bcast
    10 permit udp any any eq 31337

ip forward-protocol udp 31337

 

Comments

  • Hi Beefheadboy,

       Well i'm not sure what you're doing wrong but it works when tested with the solution guide.

    Regards,

  • Ok, I did this again and the only time I started seeing the mcast packets coming through in the debugs was after I enabled the "control disable" switch on the IP SLA.

    Without this I could see the packets coming in as mcast to R3 but nothing going out. However once we added the above switch to the IP SLA command, suddenly we saw the bcast packets leaving R3 and arriving at R2.

    Why does this control disable switch make a difference? Anyone know?

  • Hi,

       The SG uses the "control disable" option. I think this it is needed to disable the control protocol as you have no responder configured;control protocol is used to signal the responder to enbable the destination port.

    Hope it helps,

     

  • My 3560 ios does not support broadcast 255.255.255.255 as the destination address, so I use traceroute instead and it works fine.

    I see the mpacket coming in R2 from vlan 17, however, it said it is not a RPF interface

    *Mar  3 00:36:34.264: IP(0): s=129.1.7.7 (Serial0/1) d=225.25.25.25 id=0, ttl=252, prot=17, len=48(44), not RPF interface
    *Mar  3 00:36:39.272: IP(0): s=129.1.7.7 (Serial0/1) d=225.25.25.25 id=0, ttl=252, prot=17, len=48(44), not RPF interface

    Rack1R2#sh ip route 129.1.17.7
    Routing entry for 129.1.17.0/24
      Known via "eigrp 200", distance 90, metric 21026560, type internal
      Redistributing via eigrp 200
      Last update from 129.1.23.3 on Serial0/1, 1d21h ago
      Routing Descriptor Blocks:
      * 129.1.23.3, from 129.1.23.3, 1d21h ago, via Serial0/1

    I am trying to understand what this means, please correct me if I am wrong.

    As you can see from above "sh ip route" the outgoing unicast route to vlan 17 does match up with the incoming mcast packet, they are both using Serial0/1, so it should pass RPF check;

    I guess the reason why R2 marked this as not RPF interface is becasue R2 and R3 are not PIM adj neighbor (R3's s1/3 does not enable with PIM dense).  Am I correct?  Comments?

    Hmmm...I think I know the problem, I looked it again and found that for some reasons SW1 is sourcing the interface from 129.1.7.7 instead of 129.1.17.7, but the funny thing is that 129.1.7.7 does not exist in SW1 or any where in the network.  I am still looking...

    Sorry folks, please discard this post, my bad, it was me, I made a config mistake to create all this confusions, SG is working correctly.

  • http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/command/sla_s2.html#GUID-9EE8CCC2-0092-4D4F-9B19-0F8FE559BAAE

     

    The "control disable" option allows the packets to be sent to the specified destination without first verifying that there's a responder. I even had the SLA responder enabled on SW4 and it still didn't work. Then I thought about it... whenever SW4 is contacted by SW1 (unicast to multicast), it cannot respond with a multicast source address!! So this control communication will never be established, and the targeted udp packets will never be sent.

  • The verification for this task could also be done via DNS but just need to change the allowed udp ports from 31337 to 53 for verification purpose.

  •  

    I did the same test as yours...

    What I found is when not using "control disable" option, packets are forwarding to port udp 1967, whatever port you put as destination one into your sla configuration
     if you put "ip forward-protocol udp 1967" you'll see it working

     

    Obviously, it is much better when using control disable so we can see the real port used on remote side

     

    http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/command/sla_s2.html#GUID-9EE8CCC2-0092-4D4F-9B19-0F8FE559BAAE

     

    The "control disable" option allows the packets to be sent to the specified destination without first verifying that there's a responder. I even had the SLA responder enabled on SW4 and it still didn't work. Then I thought about it... whenever SW4 is contacted by SW1 (unicast to multicast), it cannot respond with a multicast source address!! So this control communication will never be established, and the targeted udp packets will never be sent.

     

  • Is there any reason that we setup a chain of helper-maps?  I just had R3 set the destination address to the destination broadcast.  IP SLA shows that this works fine.

    Can anyone comment on why it might NOT work?


    (config-if) ip multicast helper-map 225.25.25.25 192.10.18.255 acl-helper


Sign In or Register to comment.