cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

7219
Views
0
Helpful
6
Replies
Beginner

Multicast and access lists

I am confused a little with the way access lists work when applied to multicast traffic. In different documents the examples for configuring multicast boundary (and the range of group addresses advertised by RPs) are showing at least two ways of applying ACLs. For instance, to define boundary on interface it could be something like that:

acccess-list 101 permit any 239.1.1.0 0.0.0.255

interface ethernet0/0

ip address 10.2.2.2 255.255.255.0

ip pim sparse-mode

ip multicast-boundary 101

That makes sense to me. 

But more often it is presented as something like this:

acccess-list 1 permit 239.1.1.1

interface ethernet0/0

ip address 10.2.2.2 255.255.255.0

ip pim sparse-mode

ip multicast-boundary 1

Which frankly does not make sense to me. Because in standard ACLs and in extended ACLs without explicit source/destination entry the IP entry is treated as a source entry. So the second configuration looks like allowing packets from 10.2.2.2 to anything and denies everything else. But since we don't send traffic FROM multicast address, we send it TO it, this configuration would deny all the multicast traffic. 

Somebody suggested that as soon as we deal with multicast traffic the original definition of ACL action is thrown out of the window and as soon as router recognizes the IP as multicast address it is always treated as destination only. I never saw this mentioned in any of the CISCO (or none-cisco) documentation. But assuming this is the case does it mean that the following entries will be treated the same way, no matter what?

access-list 101

permit host 224.1.1.1

permit any 224.1.1.1 0.0.0.0

permit 224.1.1.1 0.0.0.0 any

Could somebody clarify it?

Thanks

 

6 REPLIES 6
Beginner

Sorry, correction - in the

Sorry, correction - in the above I meant that packets would go not from '10.2.2.2', but from '239.1.1.1'. Just mistyping. 

Hall of Fame Master

There is a flaw in your

There is a flaw in your understanding which centers on this statement: "Because in standard ACLs and in extended ACLs without explicit source/destination entry the IP entry is treated as a source entry." This understanding reflects the usual use of access lists to filter packets on interfaces. But access lists can be used for other purposes and in some of those purposes the address in the statndard access list is not necessarily the source address. For example a standard access list is frequently used in a distribute list and in this case the address in the ACL is not the source. Or a standard access list can be used in ip access-class out on the vty and in this case the IP address given is the destination address.

So in the command that is defining the boundary for multicast the address given in a standard access list is the multicast network for the boundary7 and not the source address.

HTH

Rick

If you found this post helpful, please let the community know by clicking the helpful button!
By doing so, and until end of January, you are helping Doctors Without Borders
Highlighted
Beginner

Thanks, Rick. I do understand

Thanks, Rick. I do understand that in some cases ACL is not listing specifically either destination or source (contrary to the packet filtering usage), like for instance in routing policies. And permit or deny sometimes mean just apply or not to apply particular policy to the traffic, not really 'permit' or 'deny' traffic. But the problem here is that 'boundary' generally speaking IS the filtering case. So it is rather confusing. Particularly, that then why in some cases the source/destination form is still used?

Thats why I love ACLs so much. Each time you need to 'figure out' the meaning of the ACL in particular case, as its meaning is different instead of been clearly defined (at least in documentation. Maybe?).

Still the question remains, are these entries all equivalent then? Because I've seen all of them applied on boundaries ( maybe because Im not the only one confused? -:))

access-list 101

permit host 224.1.1.1

permit any 224.1.1.1 0.0.0.0

permit 224.1.1.1 0.0.0.0 any

permit 224.1.1.1 0.0.0.0

Hall of Fame Master

I agree that it is easy for

I agree that it is easy for things to become confusing when we talk about access lists. But it seems to me that when we are attempting to define a multicast boundary that we are really talking about a single address no matter which form of access list we use. So your example with the extended access list uses permit ip any which essentially ignores the "source" address and focuses on the"destination" address.

And to answer your remaining question no those entries are not equivalent.

These two are equivalent (and are not valid syntax for access-list 101)

 permit host 224.1.1.1

permit 224.1.1.1 0.0.0.0

and the other two entries are not equivalent since one ignores the "source" part and the other ignores the "destination" by specifying any.

HTH

Rick

If you found this post helpful, please let the community know by clicking the helpful button!
By doing so, and until end of January, you are helping Doctors Without Borders
Beginner

So the valid forms, if I

So the valid forms, if I understand correctly what you said, (and identical at that) would be 

permit ip host 224.1.1.1            or 

permit ip any host 224.1.1.1    

Or not? Seems you are saying that are not identical. If multicast address in ACL for boundary is always treated as a destination then these two got to be identical in function - both allow traffic to 224.1.1.1 to pass through. Otherwise, whats the difference? 

The main problem though is that aside from the both forms above I saw in documentation there is also an 'opposite' form (though not seen as often). For example, this is from ACL applied to boundary in production environment which I cant figure out if is 'OK' or outright wrong (its on asr9000 core router) and another ACl that is applied to Rendezvous Point:

..............................................

 80 permit ipv4 239.128.0.0 0.0.255.255 any
90 permit ipv4 239.129.0.0 0.0.255.255 any

...............................................

10 deny ipv4 host 224.0.1.39 any
20 deny ipv4 host 224.0.1.40 any
30 permit ipv4 any any
................................................


 Thats where it all started - I could not make sense of it and started to look into documentation. To no avail :-). 

And thanks for taking time on this.

Hall of Fame Master

There were some things I was

There were some things I was not sure about so I have looked through several sets of documentation on multicast boundary. I have found several references that are specific in saying that multicast boundary uses standard (not extended) access list. These are probably reflecting earlier implementations or perhaps certain platforms. And clearly when using a standard access list the address and mask refer to the multicast addresses (so in a way you could consider these as destination addresses).

And I found some references that indicate that multicast boundary can use either standard or extended access list. These are probably reflecting more recent versions of code or perhaps different platforms. With the extended access list you can specify the source sending the packet as well as the multicast group to which it is sent. So the meaning of the fields in the extended access list are pretty much what we are used to in terms of source and destination addresses. 

I have not found any reference that shows something like 

80 permit ipv4 239.128.0.0 0.0.255.255 any
90 permit ipv4 239.129.0.0 0.0.255.255 any

as being valid and I must assume that they were created by someone who did not understand the config very well. And I assume that these access lists are probably not having the result that was intended for them.

HTH

Rick

If you found this post helpful, please let the community know by clicking the helpful button!
By doing so, and until end of January, you are helping Doctors Without Borders
CreatePlease to create content
Content for Community-Ad