Re: Inverse ARP and Subinterfaces

From: Alan Simpkins (alan_simpkins@xxxxxxxxx)
Date: Wed Aug 30 2000 - 17:20:09 GMT-3


   
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),
> DLCI
> > > 200 (MEDIUM)
> > > > > DLCI 300 (NORMAL), DLCI 400 (LOW)
> > > > > Serial0.2 (up): ip 202.1.1.1 dlci
> > > 500(0x1F4,0x7C40), dynamic,
> > > > > broadcast,, status defined,
> active
> > > > > Serial0 (up): ipx A.0000.0c01.1235 dlci
> > > 300(0x12C,0x48C0), static,
> > > > > broadcast,
> > > > > CISCO, status defined, active
> > > > > Serial0 (up): appletalk 300.1 dlci
> > > 200(0xC8,0x3080), static,
> > > > > broadcast,
> > > > > CISCO, status defined, active
> > > > > RTRB#ping 202.1.1.1
> > > > >
> > > > > Type escape sequence to abort.
> > > > > Sending 5, 100-byte ICMP Echos to 202.1.1.1,
> > > timeout is 2 seconds:
> > > > > !!!!!
> > > > > Success rate is 100 percent (5/5),
> round-trip
> > > min/avg/max = 56/59/60 ms
> > > > > RTRB#
> > > > >
> > > > > as you'll see, everything else apart from
> s0.2
> > > is static and no inverse
> > > > > arped...
> > > > >
> > > > > Simon
> > > > >
> > > > > -----Original Message-----
> > > > > From: mark salmon
> [mailto:masalmon@cisco.com]
> > > > > Sent: Wednesday, August 30, 2000 2:31 PM
> > > > > To: ccielab@groupstudy.com
> > > > > Subject: Inverse ARP and Subinterfaces
> > > > >
> > > > > HAs anyone been able to get inverse arp to
> work
> > > with frame relay
> > > > > multipoint subinterfaces? According to
> Caslow,
> > > multipoint subinterfaces
> > > > > do inverse arp by default. I have not been
> able
> > > to set it up that way
> > > > > in a hub and spoke environment (both sides
> > > multipoint subinterfaces).
> > > > >
> > > > > Any ideas?
> > > > > --
> > > > >
> > > > > Mark Salmon
> > > > > Project Engineer
> > > > > Cisco Professional Services
>
=== message truncated ===



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:33 GMT-3