Help with IP Multicast Boundaries

I'm struggling a bit with multicast.  I have been working on the multicast boundaries lab for a long time trying to get my head around it, and as a last resort I post here, hoping someone can help me understand :)

Anyway, I have followed ALL parts of the lab in terms of setting up the RP, and the mapping agents, the auto-rp listener and all interfaces for this lab as required.  In my frustration (and I NEVER do this) I went to the "answer" or the configuration to try and work out what the heck I did wrong in my config and it was basically exactly the same, EXCEPT I have done one thing different.

In my understanding of ip multicast boundaries, if I EXCLUDE (DENY) an IP range in a standard ACL what I have denied in the ACL should NOT be permitted out the interface (or in other words the OIL should not contain the group in the deny statement).

I have setup R5 as follws:

R5#sh run | sec access-list|pim|boundary

int G1.58

 ip multicast boundary BOUNDARY out

ip pim autorp listener

ip access-list standard BOUNDARY

 deny   232.0.0.0 7.255.255.255

 permit any

R5#


but if I setup a source on R4 to ping R10 (l0 has joined the group) on group, say 232.2.2.2, I get a response / reply.  I would have thought, based on all the other router configs in this lab being setup correctly in accordance with the config in the workbook, that shouldnt be able to "ping" that reciever with the boundary command I have used above!  Does that make sense?


I havent tried the filter-autorp option yet - I started with this above and got stuck on it and refuse to budge until I get it.  But I dont.


Cheers

Comments

  • Hi BrandNZ and All,

    I cheked INE workbook, and its explanation appears on the mark.  block inbound joins, block outbound mpackets.

    Boundary should be preventing *,G tree being built from R6 to R8.  I'm not that great with troubleshooting, but I'ld first check whether tree is built end-to-end.  R5 should be blocking joins for group.

    If tree end-to-end, check that ACL for any registered hits.  If no hits I'ld remove ACL, clear ip mroute * on R5.  to see whether it's functional then (block all groups).

    If it does block, maybe try a numbered ACL.

  • Perhaps, but with having the command set to out as I have done in my example I would have expected that any source would not be able to reach the reciever down the tree.  It would be stopped at R5 on the outgoing interface - or at least the outgoing interface would not be in the OIL.  As it is now I can "ping" the reciever and this does not make sense to me why.

  • Hi BradNZ, 

    you are absolutely correct, shouldn't be happening

    R1--|--R2--|--R3--|--R4

    Rcvr(R1)--------Boundary out(R3)---------RP(R4)

    "debug ip pim" on your R5 showing anything like this?     Using IOS 12.3(5) on GNS3

    R3#

    *Mar  1 05:23:25.906: PIM(0): Received v2 Join/Prune on FastEthernet1/0 from 155.1.23.2, to us

    *Mar  1 05:23:25.910: PIM(0): No addition to olist at scoped boundary

    R3#

    R3#show ip access-lists

    Standard IP access list 10

        10 deny   any (33 matches)       <<< PIM joins

    R3:  ip multicast boundary 10 out 

    EDIT NOTE:  ip multicast boundary is controlling routing by adjusting OIL for that group range.  I've taken the liberty of extending range to include all groups for testing.  Also, I am using a numbered ACL, as those acls I'm accustomed to using (I've tricked myself into thinking that I have better luck with numbered ACLs when called by older commands such as ip multicast boundary).

    Just came across this URL:

    http://brbccie.blogspot.com/2012/11/ip-multicast-boundary.html

Sign In or Register to comment.