From: John Underhill (stepnwlf@magma.ca)
Date: Wed Jun 16 2004 - 14:27:51 GMT-3
This is semantics: The OSPF process still has to read the multicast packets
to check the authentication signature, so, it IS processing multicast
packets. If you read the original post, it seems that denying the adjacency
via authentication is not what he was asking:
<Quote>Need your help in the following problem:
Having two routers on the same ethernet segment, asked to drop
multicast traffic betwen the two routers. Meanwhile make sure that adjacency
will still be established between the two routers.</Quote>
If you are using authentication to 'drop the mcast packets', it does not
complete the second half of the question:
'make sure that adjacency will still be established between the two
routers.'
----- Original Message -----
From: "ali" <asayyed@atheer.net.sa>
To: "John Underhill" <stepnwlf@magma.ca>; "Godswill Oletu" <oletu@inbox.lv>;
"Dan" <dans@danbsd.a.la>; "Karim" <karim_ccie@hotmail.com>
Cc: <ccielab@groupstudy.com>
Sent: Wednesday, June 16, 2004 2:20 AM
Subject: RE: OSPF over broadcast - drop mulitcast.
> I think by doing this,, the router accept multicast packet just from neigh
> router ( adjacency router ) and will drop any another multicast packet if
it
> is not have the same key
>
>
> Ali
>
> -----Original Message-----
> From: John Underhill [mailto:stepnwlf@magma.ca]
> Sent: Tuesday, June 15, 2004 9:15 PM
> To: ali; Godswill Oletu; Dan; Karim
> Cc: ccielab@groupstudy.com
> Subject: Re: OSPF over broadcast - drop mulitcast.
>
> How do you think that authentication process is being handled? With MD5 on
> broadcast networks, the cryptographic hash value is being applied to
> multicast LSAs that are evaluated on a per packet basis by the OSPF
process,
> (signed LSAs). So you have not 'eliminated multicasts' on the interface,
> only denied the adjacency. The only way you are going to create an ospf
> adjacency without any multicast traffic given the media type, is by
> specifying the non-broadcast network type, either on its own or with
> point-to-multipoint, (which uses 'psuedo broadcasts' - or directed
> unicasting). Without the ability to exchange protocol information,
(because
> you have say, used an acl or some other means to block multicast traffic),
> authentication options become irrelevant, as with the absence of protocol
> exchange the routers will never get far enough into the adjacency process
to
> check security identifiers. Once you have eliminated the need for
multicast
> traffic on the link by using the non-broadcast method, you can filter
> inbound multicast addresses with an access-list if the exam stipulates
that
> you do so.
>
> ----- Original Message -----
> From: "ali" <asayyed@atheer.net.sa>
> To: "John Underhill" <stepnwlf@magma.ca>; "Godswill Oletu"
<oletu@inbox.lv>;
> "Dan" <dans@danbsd.a.la>; "Karim" <karim_ccie@hotmail.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Tuesday, June 15, 2004 1:06 PM
> Subject: RE: OSPF over broadcast - drop mulitcast.
>
>
> > What about if we create authentication between them .. which will stop
any
> > multicast unless from authenticated interface
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> John
> > Underhill
> > Sent: Monday, June 14, 2004 9:24 PM
> > To: Godswill Oletu; Dan; Karim
> > Cc: ccielab@groupstudy.com
> > Subject: Re: OSPF over broadcast - drop mulitcast.
> >
> > Why not just change the ospf network type to non-broadcast? Non
broadcast
> > uses directed unicasts to exchange routing information..
> > An adjacency using the broadcast model and deb ip packet, shows the
> > multicast traffic:
> >
> > R2#clear ip ospf pr
> > Reset ALL OSPF processes? [no]: y
> > R2#
> > 00:29:49: IP: s=172.16.40.2 (local), d=224.0.0.5 (Ethernet0), len 68,
> > sending br
> > oad/multicast
> > 00:29:50: IP: s=172.16.40.1 (Ethernet0), d=224.0.0.5, len 68, rcvd 0
> >
> > Change the network type to non-broadcast, clear the process and this is
> what
> > you see:
> >
> > R2#clear ip ospf pr
> > Reset ALL OSPF processes? [no]: y
> > R2#
> > 00:27:17: IP: s=172.16.40.2 (local), d=172.16.40.1 (Ethernet0), len 68,
> > sending
> > 00:27:18: IP: s=172.16.40.2 (local), d=172.16.40.1 (Ethernet0), len 128,
> > sending
> > 00:27:18: %OSPF-5-ADJCHG: Process 110, Nbr 201.1.1.1 on Ethernet0 from
> FULL
> > to D
> > OWN, Neighbor Down: Interface down or detached
> > 00:27:21: IP: s=172.16.40.1 (Ethernet0), d=172.16.40.2, len 84, rcvd 0
> >
> > You can clearly see that updates are now being unicast between neighbor
> > addresses.
> >
> > ----- Original Message -----
> > From: "Godswill Oletu" <oletu@inbox.lv>
> > To: "Dan" <dans@danbsd.a.la>; "Karim" <karim_ccie@hotmail.com>
> > Cc: <ccielab@groupstudy.com>
> > Sent: Monday, June 14, 2004 1:25 PM
> > Subject: Re: OSPF over broadcast - drop mulitcast.
> >
> >
> > > OSPF uses multicast address 224.0.0.5 and 224.0.0.6 to form adjacency
> and
> > > send their hello packets.
> > >
> > > Why not try to apply these access-list to the interfaces between both
> > > routers.
> > >
> > > R(config)#Access-list 1 permit 224.0.0.5 0.0.0.0
> > > R(config)#Access-list 1 permit 224.0.0.6 0.0.0.0
> > > R(config)#Access-list 1 deny 224.0.0.0 0.255.255.255
> > > R(config)#Access-list 1 permit any any
> > >
> > > The above access-list should work, however note that:
> > >
> > > All routers uses : 224.0.0.1
> > > EIGRP uses 224.0.0.10
> > > RIPv2 uses 224.0.0.9
> > >
> > > So, you may have to adjust your access-list to accommodate other
routing
> > > protocols running in your environment.
> > >
> > > my 0.02 cents
> > >
> > > ----- Original Message -----
> > > From: "Dan" <dans@danbsd.a.la>
> > > To: "Karim" <karim_ccie@hotmail.com>
> > > Cc: <ccielab@groupstudy.com>
> > > Sent: Monday, June 14, 2004 2:38 AM
> > > Subject: Re: OSPF over broadcast - drop mulitcast.
> > >
> > >
> > > > Maybe using tunnel interface between the two?
> > > >
> > > >
> > > > Karim wrote:
> > > >
> > > > >Hi all,
> > > > >
> > > > >Need your help in the following problem:
> > > > >
> > > > >Having two routers on the same ethernet segment, asked to drop
> > multicast
> > > > >traffic betwen the two routers. Meanwhile make sure that adjacecny
> will
> > > still
> > > > >established between the two routers.
> > > > >
> > > > >I was thinking about a passive interface on both routers but
passive
> > > interface
> > > > >will drop the adjacency. So would it be solved with passive plus
> > neighbor
> > > > >command on both routers ?? Any ideas ??? am I thinking in the right
> > > direction
> > > > >??
> > > > >
> > > > >Thanks in advance,
> > > > >Karim.
> > > > >
> > > >
> >_______________________________________________________________________
> > > > >Please help support GroupStudy by purchasing your study materials
> from:
> > > > >http://shop.groupstudy.com
> > > > >
> > > > >Subscription information may be found at:
> > > > >http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:41 GMT-3