From: Antonio Sabella (Antonio.Sabella@xxxxxxxxxxx)
Date: Mon Oct 11 1999 - 16:20:39 GMT-3
One thing to do is to configure the interface w/the frame-map info BEFORE you
do your "no shut". This way, it will use the static mapping right off the
start.
Antonio Sabella
12 days to San Jose
nobody@groupstudy.com on 10/11/99 02:14:04 PM
To: ccielab@groupstudy.com@internet@WTAXE
cc:
Subject: Re: Frame Map /Inverse arp
The somewhat annoying thing is that if the dynamic map is initially built via
inverse-arp, you'll get the message 'address already in use' when you go
to add your static map (via the frame map command). So, you have to jump
out of config mode, 'clear frame', 'show frame map' (just to make sure), jump
back into config mode, then, finally add your 'frame map' statements! Just
a little more typing but not that big of a deal.
Good Luck!
mark
Peter Van Oene wrote:
> 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:52 GMT-3