From: Shaun Nicholson (Shaun.Nicholson@xxxxxx)
Date: Wed Aug 30 2000 - 10:30:38 GMT-3
Another issue with inverse arp what if you have a fully meshed frame relay netw
ork 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 ca
n 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 ...... state
ment.
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
> > Phone:773-695-8235
> > Pager:800-365-4578
> > email: masalmon@cisco.com
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:32 GMT-3