Re: ACL to permit Multicast

You need to think about control vs data traffic. Control could be PIM, MSDP,
etc. I would say start with that first if multicast traffic is going to be
allowed. For data, remember it is UDP and the flow is usually one way.
Testing is often done with pings in the lab, but not always reflective of a
real multicast flow (we always look for the reply, whereas a real multicast
sender does not expect one).

-hth

On Sun, Sep 13, 2009 at 2:59 PM, Mohamed El Henawy <m.henawy_at_link.net>wrote:

> not really...
> suppose that we are implanting CBAC or reflexive ACL...normally we permit
> routing protocols to pass from the two directions and maybe
> ICMP..etc...what
> if we have multicast as well...what do we need to permit in this case...
>
>
> ----- Original Message -----
> From: ALL From_NJ
> To: Mohamed El Henawy
> Cc: Aundra Browning ; Joe Astorino ; Lejoe ; Steve Lyons ; Cisco
> certification
> Sent: Monday, September 14, 2009 12:55 AM
> Subject: Re: ACL to permit Multicast
>
>
> lol ... ok, I read it wrong.
>
> For some reason I read it and figured you were trying to block mcast.
>
> Once you assign an ACL, you will need to define permited traffic since the
> unwritten deny is at the end. Is this what you are asking?
>
> You can easily test this w/ 2 routers running EIGRP between them. Permit
> ping but not telnet ... and make sure that eigrp stays up, etc ...
>
> HTH
>
>
>
>
> On Sun, Sep 13, 2009 at 4:46 PM, Mohamed El Henawy <m.henawy_at_link.net>
> wrote:
>
> my 1st question was about if I have to deny certain type of traffic bet
> 2
> routers or between some routers and one destination router as per security
> question and the 2 or more routers running multicast...I have not seen it
> before but who knows
> my understanding that if I permit ip between the interfaces that is
> running multicast then that will be the best option...
>
>
>
> ----- Original Message -----
> From: ALL From_NJ
> To: Aundra Browning
> Cc: Joe Astorino ; Lejoe ; Steve Lyons ; Mohamed El Henawy ; Cisco
> certification
> Sent: Monday, September 14, 2009 12:36 AM
> Subject: Re: ACL to permit Multicast
>
>
> The ACL discussion is pretty interesting.
>
> If the question is to permit or not permit mcast on an interface, I
> suppose you could simply deny all mcast traffic and permit everything else.
>
> A gotcha ... (thinking out loud here) ... is that routing protocols
> use
> mcast as well. Be careful how you write the ACL ...
>
> Another thought is to block igmp, autorp, bsr, or use a neighbor
> filter.
> here is the output for an extended acl:
>
> R1(config)#ip access-list extended pim
> R1(config-ext-nacl)#deny ?
> <0-255> An IP protocol number
> ahp Authentication Header Protocol
> eigrp Cisco's EIGRP routing protocol
> esp Encapsulation Security Payload
> gre Cisco's GRE tunneling
> icmp Internet Control Message Protocol
> igmp Internet Gateway Message Protocol
> ip Any Internet Protocol
> ipinip IP in IP tunneling
> nos KA9Q NOS compatible IP over IP tunneling
> ospf OSPF routing protocol
> pcp Payload Compression Protocol
> pim Protocol Independent Multicast
> tcp Transmission Control Protocol
> udp User Datagram Protocol
> !
> R1(config-ext-nacl)#deny pim ?
> A.B.C.D Source address
> any Any source host
> host A single source host
>
> HTH,
>
> Andrew
>
>
>
>
> On Sun, Sep 13, 2009 at 5:19 PM, Aundra Browning
> <aundra.browning_at_earthlink.net> wrote:
>
> Hi Guys....
>
> Just have to be careful here - assuming we are referring to matching
> IP
> Multicast traffic w/an ACL.....you would have to match on the
> destination
> address as 224.0.0.0 - 239.255.255.255 wouldn't be a source address.
> Think
> the below was meant to show:
>
> permit ip any 224.0.0.0 15.255.255.255
>
> Hth...
>
> Aundra (Andre) Browning
> CCIE #21901 (R&S)
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On
> Behalf
> Of Joe
> Astorino
> Sent: Sunday, September 13, 2009 3:34 PM
> To: Lejoe
> Cc: Steve Lyons; Mohamed El Henawy; Cisco certification
> Subject: Re: ACL to permit Multicast
>
>
> this is always a good one as well to permit the entire IP multicast
> range...
> permit ip 224.0.0.0 15.255.255.255
>
> On Sun, Sep 13, 2009 at 9:16 AM, Lejoe <styran_at_gmail.com> wrote:
>
> > Hi,
> >
> > Adding to Steve's post,
> > - CGMP frames are Ethernet frames, so you cant match it in an IP
> ACL.
> >
> >
> >
>
> http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_n
> ote0918<http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_n%0Aote0918>
> 6a00800b0871.shtml#cgmp
> > - MSDP (TCP port 639)
> > - MOSPF (Multicast Extensions to OSPF)
> > - Auto-RP, BSR, Anycast RP ( All use PIM + IGP)
> > - IPv6 MLD ( uses ICMPv6, IP protocol 58)
> > http://www.faqs.org/rfcs/rfc2710.html
> >
> > HTH
> >
> > Lejoe
> >
> >
> >
> > On Sun, Sep 13, 2009 at 10:58 PM, Steve Lyons
> <charter21p5_at_gmail.com>
> > wrote:
> >
> > > Copying Group:
> > >
> > > PIM is only one protocol within the suite of protocols. Keep in
> mind
> > there
> > > is also CGMP, IGMP, MSDP, MOSPF, Auto-RP, BSR, Anycast-RP, and
> in
> IPV6
> > MLD.
> > > There are also a range of multicast addresses you could allow:
> > >
> > > http://www.iana.org/assignments/multicast-addresses/
> > >
> > > Steve Lyons
> > >
> > > On Sun, Sep 13, 2009 at 7:43 AM, Mohamed El Henawy
> <m.henawy_at_link.net
> > > >wrote:
> > >
> > > > Assuming that the Source ip is already permitted ofcourse
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Mohamed El Henawy
> > > > To: Cisco certification
> > > > Sent: Sunday, September 13, 2009 2:32 PM
> > > > Subject: ACL to permit Multicast
> > > >
> > > >
> > > > Hello Group ,
> > > >
> > > > short question...
> > > > if I need to permit multicast on the interface is
> access-list
> x
> > permit
> > > > pim
> > > > any any is enough ?
> > > >
> > > >
> > > > Thanks :)
> > > >
> > > >
> > > > 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
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Regards,
>
> Joe Astorino - CCIE #24347 R&S
> Technical Instructor - IPexpert, Inc.
> Cell: +1.586.212.6107
> Fax: +1.810.454.0130
> Mailto: jastorino_at_ipexpert.com
>
>
> 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
>
>
> _____________________________________________________________________
> __
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com
>
>
>
> --------------------------------------------------------------------------
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.94/2367 - Release Date:
> 09/13/09 05:50:00
>
>
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com
>
>
>
>
> -----------------------------------------------------------------------------
> -
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.94/2367 - Release Date: 09/13/09
> 05:50:00
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Bryan Bartik
CCIE #23707 (R&S), CCNP
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com
Blogs and organic groups at http://www.ccie.net