From: Lee Donald (Lee.Donald@t-systems.co.uk)
Date: Tue Jul 12 2005 - 04:58:20 GMT-3
He's only asking a question, no need for name calling.
-----Original Message-----
From: cacca mucca [mailto:caccamucca@hotmail.com]
Sent: 11 July 2005 17:09
To: netsteps@rediffmail.com; ccielab@groupstudy.com
Subject: RE: (Brian's) IE Lab15 Task 5.21
Brian,
I feel your pain when you have to deal with bone heads like us.
>From: "Amit Jain" <netsteps@rediffmail.com>
>Reply-To: "Amit Jain" <netsteps@rediffmail.com>
>To: "Group Study" <ccielab@groupstudy.com>
>Subject: (Brian's) IE Lab15 Task 5.21
>Date: Mon, 11 Jul 2005 20:52:36 +0530
>
>Great Brian's...now the ball is in your court :-)
>
>Amit Jain
>----- Original Message -----
>From: "John Matus" <jmatus@pacbell.net>
>To: "Amit Jain" <netsteps@rediffmail.com>; "Arun Kumar Arumuganainar"
><aarumuga@hotmail.com>; <silamoni@yahoo.com>
>Cc: <ccielab@groupstudy.com>
>Sent: Monday, July 11, 2005 12:11 PM
>Subject: Re: IE Lab15 Task 5.21
>
>
> > although i've not read up on the implementation of p2p non broadcast, i
> > think the jist of the solution is that a 'p2p' non-broadcast is
>inherently
> > more secure than a non p2p non-broadcast circuit.....but again, i've not
> > read up on the technology. there is probably somthing happening at
>layer
>2
> > that makes it more secure. i'm sure answer is in the wording of the
> > question, because it does seem that setting up a non-broadcast medium w/
> > neighbor statement, as well as preventing hello's w/ a passive inteface
> > command, would fulfill the task requirements.....but only Brian know's
>the
> > answer ;-P
> >
> >
> > Regards,
> >
> > John D. Matus
> > MCSE, CCNP
> > Office: 818-782-2061
> > Cell: 818-430-8372
> > jmatus@pacbell.net
> > ----- Original Message -----
> > From: "Amit Jain" <netsteps@rediffmail.com>
> > To: "Arun Kumar Arumuganainar" <aarumuga@hotmail.com>;
><silamoni@yahoo.com>
> > Cc: <ccielab@groupstudy.com>
> > Sent: Sunday, July 10, 2005 11:29 PM
> > Subject: Re: IE Lab15 Task 5.21
> >
> >
> > > Thanks Arun, but still I cannot relate your answer to my questions. In
>my
> > > Diagram
> > >
> > > R3 ----frame-relay----R5 ------isdn-------R4
> > >
> > > Do you call this hub and spoke, if they are connected together through
> > > different WAN topology??
> > > R3 and R5 are on non-broadcast default mode for which neighbor
>statement
> > > is
> > > configured.
> > > R5 and R4 are on point-to-point mode as what i seee from "sh ip ospf
>inter
> > > bri0/0"
> > >
> > > Ques asked to prevent hello packets to anyone hooking on to this
>topology.
> > > Sol says that configure point-to-multipoint non-broadcast on all the
> > > routers.
> > > My Ques : Why to configure point-to-multipoint non-broadcast when the
> > > default network type between R3 and R5 is non-br and sending unicast
>(so
> > > nobody can hook on this segment and see hello) AND
> > > Why to configure point-to-multipoint non-broadcast between R5 and R4
>when
> > > default network type point-to-point will prevent leaking of hellos, as
>the
> > > hellos will only go to other side.
> > >
> > > What am I missing?
> > >
> > > AMit
> > >
> > > ----- Original Message -----
> > > From: "Arun Kumar Arumuganainar" <aarumuga@hotmail.com>
> > > To: <silamoni@yahoo.com>
> > > Cc: <ccielab@groupstudy.com>
> > > Sent: Sunday, July 10, 2005 5:14 PM
> > > Subject: Re: IE Lab15 Task 5.21
> > >
> > >
> > >> For Fram Relay Networks , Default Mode in Frame Relay Network is NBMA
>.
> > >> But this will work only with Fully Meshed network .In Hub and Spoke
> > >> topology full connectivity can not be achived . Spoke routers will
>only
> > >> be able to ping Hub router and none of the other spoke routers.
> > >>
> > >> Note :In the above scenario OSPF neighborship will get established .
> > >> Routing table will get populated as normal . But however ,
>connectivity
> > >> alone will not be there across the Spokes .This Problem will also be
>seen
> > >> in Partially meshed networks as well .
> > >>
> > >> By making the Network type Point to Multipoint you can over come this
> > >> problem . Actually if you inspect the routing table on the point to
> > >> Multipoint network , you will be able to observe host route ( Route
>with
> > >> /32 Bit mask ) for all connected IP address . This will enable
>routing
> > >> possible between spokes !!!
> > >>
> > >> Pls. Note : You could add broadcast keyword appended to point to
> > >> Multipoint . In case you are not allowed to configure broadcast key
>word
> > >> then you will have manually configure neighbour statement . This will
> > >> enable OSPF packets to unicasted over the FR Cloud .
> > >>
> > >> Hope this helps.
> > >>
> > >> Thanks and Regards
> > >> Arun
> > >>
> > >> >From: Sila Moni <silamoni@yahoo.com>
> > >> >Reply-To: Sila Moni <silamoni@yahoo.com>
> > >> >To: Amit Jain <netsteps@rediffmail.com>, Group Study <>
> > >> >Subject: Re: IE Lab15 Task 5.21
> > >> >Date: Sat, 9 Jul 2005 05:52:29 -0700 (PDT)
> > >> >
> > >> >There are two issues that I see from this scenario.
> > >> >
> > >> >1. Typically, you would use the neighbor statement on
> > >> >the hub. Since it is on R3 (spoke), it will create
> > >> >some problems. Are you allowed to put the neighbor
> > >> >statement on R4 as well?
> > >> >
> > >> >2. P-T-M non-broadcast is used in NBMA with virtual
> > >> >circuits of differing speeds (e.g. ISDN and FR).
> > >> >Here, assigning cost to the neighbor is optional.
> > >> >
> > >> >
> > >> >--- Amit Jain <netsteps@rediffmail.com> wrote:
> > >> >
> > >> > > Hi
> > >> > >
> > >> > > In the task, R3 and R5 are connected through frame
> > >> > > relay and R4 and R5 through
> > >> > > ISDN
> > >> > >
> > >> > > R3
> > >> > > -
> > >> > > -
> > >> > > - FR -
> > >> > > -
> > >> > >
> > >> > > R4 - -ISDN - - R5
> > >> > >
> > >> > > Now the ospf area 345 is running on FR and ISDN
> > >> > > links and network type
> > >> > > non-broadcast between R3 and R5, with neighbor
> > >> > > command on R3.
> > >> > > Task requirement is to configure all adjacencies in
> > >> > > area 345 in such a manner
> > >> > > that other devices on segment cannot recieve OSPF
> > >> > > hello packets.
> > >> > > The solution given is that the network type on ISDN
> > >> > > and FR segment be changed
> > >> > > to point-to-multipoint (with ofcourse neighbor
> > >> > > statements)
> > >> > >
> > >> > > My ques is why we need to change it to
> > >> > > point-to-multpoint from non-broadcast
> > >> > > on FR segment ? When the netwrk type is
> > >> > > non-broadcast we are sending packets
> > >> > > as unicast only, so why specifically change to
> > >> > > p-to-multipoint ?? (Only
> > >> > > difference will be no DR/BDR elec and host route)
> > >> > >
> > >> > > Also the ISDN segment is network type point-to-point
> > >> > > so anyways the hello
> > >> > > packets will only go to the other side ?? What am i
> > >> > > missing.
> > >> > >
> > >> > > Could not get the answer from IE website posts.
> > >> > >
> > >> > > Thanks
> > >> > > Amit Jain
> > >> > >
> > >> > >
> > >>
> >_______________________________________________________________________
> > >> > > Subscription information may be found at:
> > >> > > http://www.groupstudy.com/list/CCIELab.html
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >____________________________________________________
> > >> >Sell on Yahoo! Auctions no fees. Bid on great items.
> > >> >http://auctions.yahoo.com/
> > >> >
> > >>
> >_______________________________________________________________________
> > >> >Subscription information may be found at:
> > >> >http://www.groupstudy.com/list/CCIELab.html
> > >>
> >
> >>
>------------------------------------------------------------------------
> > >>
> > >> Looking for a date? Meet interesting singles like you Sign up with
> > >> Match.com
> > >>
> > >>
>_______________________________________________________________________
> > >> Subscription information may be found at:
> > >> http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
>_______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:29 GMT-3