From: John Underhill (stepnwlf@magma.ca)
Date: Wed Jun 16 2004 - 15:20:28 GMT-3
Now your overlooking this part of the question:
'asked to drop multicast traffic betwen 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 1:33 PM
Subject: RE: OSPF over broadcast - drop mulitcast.
> I didn't see any mismatch ..
> The second half of the question asking u to make sure the adjacency will
> still ......
> If u create ospf auth per interface not per area ( I mean in both Ethernet
> interface in both routers )
> The adjec will up and u will prevent the multi from oituside
> ??
> Ali
>
> -----Original Message-----
> From: John Underhill [mailto:stepnwlf@magma.ca]
> Sent: Wednesday, June 16, 2004 8:28 PM
> To: ali; Godswill Oletu; Dan; Karim
> Cc: ccielab@groupstudy.com
> Subject: Re: OSPF over broadcast - drop mulitcast.
>
> 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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:41 GMT-3