Re: Frame Map /Inverse arp

From: Brian Van Benschoten (vader@xxxxxxxxxxxx)
Date: Sat Oct 16 1999 - 14:03:36 GMT-3


   
Is just "no frame inverse-arp" sufficient

in my test rack it seems to disable inverse arp for all protocols
----- Original Message -----
From: Lawrence C. Broadnax <lcbroadn@swbell.net>
To: 'Peter Van Oene' <vantech@sympatico.ca>; <ccielab@groupstudy.com>
Sent: Tuesday, October 12, 1999 7:33 PM
Subject: RE: Frame Map /Inverse arp

> Just remember to add to following two commands to any frame configuration
before you configure any frame map statements:
>
> no arp frame-relay
> no frame inverse-arp
>
> -----Original Message-----
> From: Peter Van Oene [SMTP:vantech@sympatico.ca]
> Sent: Monday, October 11, 1999 2:42 PM
> To: ccielab@groupstudy.com
> Subject: Re: Frame Map /Inverse arp
>
> Bruce describes a scenario where you are installing frame on an interface
> for the first time, which will be the case should you have to config frame
> on the ccie lab exam.
>
> In this case, the first frame command you can type on an interface is
encaps
> frame. As soon as you do this, inverse arp will resolve any relevant
remote
> addresses (this can be verified by show frame map). If you subsequently
add
> a frame map statement, this map statement will disable inverse arp for the
> dlci and protocol that the map contains. However, it will not remove the
> dynamic address that you have already learned. Hence, if your map is
wrong,
> your circuit may work because inverse arp has produced the correct info.
> More often, you will have a couple maps for the same protocol and the same
> dlci, but you may forget to add one site. When you test your
connectivity,
> inverse arp will mask the fact that your config is not correct. However,
> when you reboot, inverse arp will be disabled and any config problems
> related to frame map statements will begin to cause problems.
>
> The big problem is, you likely won't reboot the router for some time and
> when you do, frame map statement issues may not be top of mind and you'll
> likley end up spending a fair amount of time figuring out whats up with
your
> net. The key point is, when you add maps, double check that they are
> inclusive. You may try a clear frame (clears the inverse arp table) to
> ensure that you have a valid config.
>
> Regards,
>
> Peter Van Oene
> Senior Systems Engineer
> UNIS LUMIN Inc.
> www.unislumin.com
>
> ----- Original Message -----
> From: Manjeet Chawla <mchawla@asanet.com>
> To: <ccielab@groupstudy.com>
> Sent: Sunday, October 10, 1999 6:47 PM
> Subject: Frame Map /Inverse arp
>
>
> > Hi everyone !
> >
> > I have a frame relay map/inverse arp question. As per Caslow, page 118
> > under "A Word of Caution...." paragaph-1; it says:
> >
> > If a router is reload, inverse arp will be disabled for any DLCI that is
> > used with any frame relay map statements....
> >
> >
> > I have three routers (plus a router as FR Switch):
> >
> > Routers Spoke-1 and Spoke-2 connect to Hub router (via FR switch).
> >
> > Spoke-1 and 2 cannot ping each other as no map exists. If I am
> > understanding it right, If I use FR map on Spoke-1 and 2 and reload the
> > spokes, the inverse arp will be disabled on the spokes and under "show
> > FR map" I should see only the static map (and no dynamic). Well, I see
> > both static (to other spoke) and dynamic (to the hub).
> > Am I mis-interpretting the book ?
> >
> > My configs and FR MAP outputs are as below:
> >
> >
> > Thanks all for your helo in advance.
> > Manjeet Chawla
> >
> >
> >
> >
> > SWITCH:
> > interface Serial0
> > no ip address
> > encapsulation frame-relay
> > no fair-queue
> > frame-relay intf-type dce
> > frame-relay route 102 interface Serial1 201
> > frame-relay route 103 interface Serial2 301
> > !
> > interface Serial1
> > no ip address
> > encapsulation frame-relay
> > frame-relay intf-type dce
> > frame-relay route 201 interface Serial0 102
> > !
> > interface Serial2
> > no ip address
> > encapsulation frame-relay
> > frame-relay intf-type dce
> > frame-relay route 301 interface Serial0 103
> > !
> > end
> >
> >
> > HUB:
> > interface Serial0
> > ip address 172.16.3.3 255.255.255.0
> > encapsulation frame-relay
> > no fair-queue
> > clockrate 2000000
> >
> > Hub#sh fr map
> > Serial0 (up): ip 172.16.3.1 dlci 102(0x66,0x1860), dynamic,
> > broadcast,, status defined, active
> > Serial0 (up): ip 172.16.3.2 dlci 103(0x67,0x1870), dynamic,
> > broadcast,, status defined, active
> > Hub#
> >
> >
> > SPOKE-1:
> > interface Serial0
> > ip address 172.16.3.1 255.255.255.0
> > encapsulation frame-relay
> > no ip mroute-cache
> > no fair-queue
> > clockrate 2000000
> > frame-relay map ip 172.16.3.2 201
> > !
> > end
> >
> > Sh frame map
> > Serial0 (up): ip 172.16.3.2 dlci 201(0xC9,0x3090), static,
> > <------------------------
> > CISCO, status defined, active
> > Serial0 (up): ip 172.16.3.3 dlci 201(0xC9,0x3090), dynamic,
> > <--------------------
> > broadcast,, status defined, active
> >
> >
> >
> > SPOKE-2
> > interface Serial0
> > ip address 172.16.3.2 255.255.255.0
> > encapsulation frame-relay
> > no fair-queue
> > clockrate 2000000
> > frame-relay map ip 172.16.3.1 301
> > !
> >
> > spoke-2#sh fr map
> > Serial0 (up): ip 172.16.3.1 dlci 301(0x12D,0x48D0), static,
> > <---------------------
> > CISCO, status defined, active
> > Serial0 (up): ip 172.16.3.3 dlci 301(0x12D,0x48D0), dynamic,
> > <----------------
> > broadcast,, status defined, active
> > spoke-2#
> >
> >



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