From: Chia Kim Seng, NWSpec, SCS-Networks (chiaks@xxxxxxxxxxxxxxxxxxxxxx)
Date: Fri May 05 2000 - 03:09:10 GMT-3
When your spoke reloaded, the reloaded spoke router will only know how
to reach the other spoke but not to the Hub due to the static map
statement being specified. The dynamic mapped to Hub that previously
the reloaded spoke had will be lost. But to the Hub, it will still
maintain the inverse arp to the two spoke.
Therefore, based on your scenario after the spoke being reloaded. The
Hub still know how to map the two remote spoke routers' ip address to
the local DLCI. The reloaded spoke router on the other hand will only
knows the static map of the other spoke's ip address to the local
DLCI.
Hopes that helps.
May all beings be happy.
Kim Seng
-----Original Message-----
From: John Conzone [mailto:jkconzone@home.com]
Sent: Friday, May 05, 2000 7:54 AM
To: ccielab
Subject: Inverse arp (again)
I know this has been covered before, but I would like to ask the
question in my own way.
I've been re-reading Caslow's section on Frame Relay, and how if
you configure a map statement for IP on a DLCI, the inverse arp will
be disabled for that protocol (IP) and that DLCI, should the router be
reloaded.
So in his diagram you have a hub with 2 spokes. The hub and spokes
have inverse arp mapping to each other, and can reach each other
without map statments. To get the spokes to talk, we need map
statements from each spoke to the other spoke, referencing the same
DLCI that the iarp mapping from spoke to hub uses. The spokes can
talk.
Now one of the spokes is reloaded. Here's my question. The IP
mapping between that reloaded spoke and the hub goes away, cause it
was iarp. Correct? Now iarp is a 2 way thing, right? In other
words, the reloaded spoke and the hub would both lose the iarp mapping
to each other, not just the reloaded spoke.
Now even though the hubs have a mapping to each other, they can't
talk because they talk through the hub, and the hub can't reach one
spoke.
Sorry, but I am revisiting Frame and routing over Frame for the
third, but not neccessarily the last, time!
Thanks again ahead of time for all of your help!
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:23:27 GMT-3