From: Alan Simpkins (alan_simpkins@xxxxxxxxx)
Date: Wed Aug 30 2000 - 18:06:45 GMT-3
Assuming you have that option, and I and I especially
agree with your statement about the broadcast
parameter. That can be tricky if you are not pying
close attention to what is going on.
--- mark salmon <masalmon@cisco.com> wrote:
> With OSPF, as long as you use ip ospf network point
> to multipoint, you
> should be ok. The problem may arise if you use the
> broadcast option
> before you set a OSPF priority of 0 for non meshed
> interfaces. If all
> interfaces are fully meshed, that should not be a
> problem.
>
> Alan Simpkins wrote:
> >
> > Because Inverse-arp only works about 85% of the
> time
> > IMHO, and personal experience. In addition
> Inverse-arp
> > leaves much to chance such as using pvcs, that you
> may
> > not want used for a connection. If you have a
> fully
> > meshed core, with multiple connections between say
> > router a and b, using inverse-arp how can you
> insure
> > you are using pvc 100 vice 110to get from router a
> to
> > b? In addition I have seen several issues with
> OSPF
> > using Inverse-arp where adjacencies are not
> properly
> > created. This is just my personal experience,
> others
> > may vary.
> >
> > --- Sam Munzani <sam@chinet.com> wrote:
> > > On HUB router using Multipoint why not? Since it
> > > will learn remote
> > > networks by Inverse-ARP there would be no need
> to
> > > have Frame-relay
> > > maps. This saves a lot of typing time if you
> have
> > > many spokes with IP,
> > > IPX, Apple, Dec and god knows what other
> protocols
> > > they may ask for.
> > >
> > > Without using Inverse-ARP you will end up having
> > > 10-12 map statements.
> > >
> > > For spokes,
> > > I am strongly in favor of using Static maps.
> > >
> > > Sam
> > >
> > > On Wed, 30 Aug 2000, Alan Simpkins wrote:
> > >
> > > > Having taken the lab 3 times now, and being
> > > scheduled
> > > > for #4, I would recommend against using
> > > inverse-arp,
> > > > except where required if at all.
> > > >
> > > > --- Shaun Nicholson <Shaun.Nicholson@kp.org>
> > > wrote:
> > > > > Another issue with inverse arp what if you
> have
> > > a
> > > > > fully meshed frame relay network but you are
> not
> > > > > allowed to use all of the PVC's.
> > > > > Inverse arp will use the all the DLCI's
> > > available
> > > > > and you could end up using a PVC you are not
> > > allowed
> > > > > too and not be awair of what you've done.
> > > > > Think about it in the pressure of the lab
> > > > > environment you see its up and you can ping
> so
> > > you
> > > > > dont bother doing a sh frame map or sh frame
> pvc
> > > and
> > > > > you've lost points without realizing it.
> > > > > Map statements mean you avoid using the PVC
> you
> > > are
> > > > > not allowed to use.
> > > > >
> > > > > I agree with the Frame-relay map,
> frame-relay
> > > map,
> > > > > frame-relay map ...... statement.
> > > > >
> > > > > Way too many issues with the inverse arp in
> the
> > > lab.
> > > > >
> > > > > Shaun
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > kbaumgar@cisco.com on 08/29/2000 11:55:00 PM
> > > > > To: masalmon@cisco.com@Internet
> > > > > cc: ccielab@groupstudy.com@Internet
> (bcc: Shaun
> > > > > Nicholson/MD/KAIPERM)
> > > > > Subject: Re: Inverse ARP and Subinterfaces
> > > > >
> > > > > My recommendation is to not depending on
> > > inverse
> > > > > arp when doing
> > > > > the lab. It can be something problematic to
> get
> > > > > things working and
> > > > > you can waste a lot of time trying to get
> things
> > > to
> > > > > work.
> > > > >
> > > > > I know of someone that spend 1/2 of the
> first
> > > day
> > > > > just trying to
> > > > > get framerelay working and pinging between
> > > routers.
> > > > > And didn't even
> > > > > get to finish most of the questions because
> of
> > > this.
> > > > >
> > > > > The recommend I heard from some which I
> agree
> > > with
> > > > > is
> > > > > Frame-relay map, frame-relay map,
> frame-relay
> > > map
> > > > > ...
> > > > >
> > > > > - Kevin
> > > > >
> > > > > >
> > > > > > No can do you are using map statements.
> My
> > > > > contention is to use inverse
> > > > > > arp. I realize that you can use map
> > > statements to
> > > > > achieve
> > > > > > reachability. I wish ot use inverse arps
> on
> > > the
> > > > > hub router.
> > > > > >
> > > > > > Simon Baxter wrote:
> > > > > > >
> > > > > > > Yip, just added it just for you!!
> > > > > > >
> > > > > > > interface Serial0
> > > > > > > ip address 192.1.1.2 255.255.255.0
> > > > > > > encapsulation frame-relay
> > > > > > > no ip mroute-cache
> > > > > > > ip policy route-map policy
> > > > > > > frame-relay traffic-shaping
> > > > > > > frame-relay priority-dlci-group 1 100
> 200
> > > 300
> > > > > 400
> > > > > > > frame-relay map bridge 400 broadcast
> > > > > > > frame-relay map ip 192.1.1.1 100
> broadcast
> > > > > > > frame-relay map ipx A.0000.0c01.1235
> 300
> > > > > broadcast
> > > > > > > frame-relay map appletalk 300.1 200
> > > broadcast
> > > > > > > no frame-relay inverse-arp
> > > > > > > frame-relay qos-autosense
> > > > > > > !
> > > > > >
> > > > > > > interface Serial0.2 multipoint
> > > > > > > ip address 202.1.1.2 255.255.255.0
> > > > > > > cdp enable
> > > > > > > frame-relay interface-dlci 500
> > > > > > > !
> > > > > > >
> > > > > > > RTRB#
> > > > > > > RTRB#show frame map
> > > > > > > Serial0 (up): bridge dlci
> 400(0x190,0x6400),
> > > > > static,
> > > > > > > broadcast,
> > > > > > > CISCO, status defined,
> active
> > > > > > > Serial0 (up): ip 192.1.1.1 dlci
> > > > > 100(0x64,0x1840), static,
> > > > > > > broadcast,
> > > > > > > CISCO, status defined,
> active
> > > > > > > Priority DLCI Group 1, DLCI 100
> (HIGH),
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:33 GMT-3