From: Mike Gutknecht (mike@xxxxxxxxxxxxx)
Date: Fri Jun 01 2001 - 02:35:40 GMT-3
I would argue that you do not want to rely on inverse arp at the hub. You
may get extra address/dlci mappings that you do not intend. (e.g. Perhaps
there are extra dlci's that the frame switch is pushing toward you.) When
you turn on inverse-arp, you are at the mercy of the frame switch being
configured to only send you dlci's that you expected. Turning off inverse
arp and using frame maps offers you more control and I think that is a very
defensible argument.
-Mike G
-----Original Message-----
From: Jared Carter [mailto:jared@carter.net]
Sent: Thursday, May 31, 2001 6:53 PM
To: Nathan Casassa; . ..
Cc: ccielab@groupstudy.com
Subject: Re: OSPF & ip ospf net non-bro
No, I agree totally that the spokes will need the fram map statements to the
other spoke (and to the hub in case the box is rebooted), I was speaking
really on a seperate tangent.
Because the hub has a direct connection to each spoke, it will always be
able to inverse-arp for their addresses. If this is the case, then the fram
map statements are unnecessary.
Take a look at Caslow first Edition page 134. It sets up an example with
Multipoint Subinterface at the hub and physical interfaces at the spokes,
just like we have here.
On the next page, he says "For the hub, notice how everything is minimally
configured. Notice how all of the map statements in 'sh frame map' are
dynamic [inverse-arp]. They could have been replaced with static map
statements but it's not necessary."
This is why I was asking if a proctor may deduct points for commands that
worked perfectly, but were not necessary.
/Jared
----- Original Message -----
From: "Nathan Casassa" <ncasassa@gnilink.net>
To: "Jared Carter" <jared@carter.net>; ". .." <subinterface@yahoo.com>
Cc: <ccielab@groupstudy.com>
Sent: Thursday, May 31, 2001 9:32 PM
Subject: RE: OSPF & ip ospf net non-bro
> Jared - Yes, I believe your way off base.
> Was speaking of the spokes that require the frame-map statements. Inverse
> arp won't arp over to the other side of the hub router, just the local
side.
> To be safe, don't use inverse arp unless forced to do so. Inverse arp is
> simply an extension of regular arp and the structure is similar. Just
like
> a router won't forward an arp request, it won't forward an inverse arp
> request over to another router to retrieve the Q.922 address information.
>
> I am a little tired tonight so please respond if any inaccuracies exist in
> my babbling.
>
>
>
> Nathan Casassa
> Network Engineering/Architecture
> Verizon Global Networks, Inc.
>
>
>
>
> > -----Original Message-----
> > From: Jared Carter [mailto:jared@carter.net]
> > Sent: Thursday, May 31, 2001 8:08 PM
> > To: . ..; Casassa, Nathan
> > Cc: ccielab@groupstudy.com
> > Subject: Re: OSPF & ip ospf net non-bro
> >
> >
> > In this situation, the hub does not need the frame map statements
> > because he
> > can inverse-arp for each spoke's layer 3 address. I can see a proctor
> > taking off points for the extra (and unnesessary) commands.
> >
> > Am I way off base here?
> >
> > /Jared
> >
> > ----- Original Message -----
> > From: ". .." <subinterface@yahoo.com>
> > To: "Casassa, Nathan" <ncasassa@gnilink.net>
> > Cc: <ccielab@groupstudy.com>
> > Sent: Thursday, May 31, 2001 7:25 PM
> > Subject: RE: OSPF & ip ospf net non-bro
> >
> >
> > > You're right. Thanks. Also Thanks to Chuck and
> > > others.
> > >
> > > That worked.
> > >
> > >
> > > --- "Casassa, Nathan" <ncasassa@gnilink.net> wrote:
> > > > So encap failed means ..... ? This should be pretty
> > > > visible -- How about a
> > > > frame-map statement, or maybe some cool local
> > > > policies?
> > > >
> > > > -----Original Message-----
> > > > From: . .. [mailto:subinterface@yahoo.com]
> > > > Sent: Thursday, May 31, 2001 2:52 PM
> > > > To: Chuck Larrieu; ccielab@groupstudy.com
> > > > Subject: RE: OSPF & ip ospf net non-bro
> > > >
> > > >
> > > > Good info Chuck. The frame maps on the spokes are
> > > > pointing to the hub. Looks ok
> > > > The deb ip pac is showing a encap failed. I'll
> > > > pursue
> > > > it further. As far as the docs go. Caslow touches
> > > > on
> > > > this and says to use Broadcast or P-to-MP, and the
> > > > archives were vague too. I've been working on this
> > > > one for most of the day. Thanks again.
> > > >
> > > >
> > > >
> > > >
> > > > --- Chuck Larrieu <chuck@cl.cncdsl.com> wrote:
> > > > > Look at the next hop addresses on your spokes.
> > > > What
> > > > > are they?
> > > > >
> > > > > Do a show frame map. What is the output? Compare
> > > > > that to the next hop
> > > > > addresses.
> > > > >
> > > > > Do a debug ip packet and then ping from one spoke
> > > > to
> > > > > the other. What is the
> > > > > error you are getting? Why?
> > > > >
> > > > > This is well documented, in Caslow, in the
> > > > archives,
> > > > > in lots of other
> > > > > places. And it is critical that you understand the
> > > > > issue and how to correct
> > > > > it.
> > > > >
> > > > > Chuck
> > > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com
> > > > > [mailto:nobody@groupstudy.com] On Behalf Of . ..
> > > > > Sent: Thursday, May 31, 2001 2:18 PM
> > > > > To: ccielab@groupstudy.com
> > > > > Subject: OSPF & ip ospf net non-bro
> > > > >
> > > > > ok, there have been several of these posts and
> > > > > instances in the archives but I've yet to see a
> > > > > comprehensive answer. I understand the
> > > > > characteristics of ospf non-bro nets and forming
> > > > > adjaciencies but I still don't know why the spokes
> > > > > can't ping each other. The routes are in the
> > > > table.
> > > > >
> > > > > Scenario...
> > > > > r3
> > > > > /
> > > > > r5--fr
> > > > > \
> > > > > r4
> > > > >
> > > > > ===> r5 (hub) <===
> > > > > interface Serial0.3 multipoint
> > > > > ip address 140.11.51.5 255.255.255.0
> > > > > ip ospf network non-broadcast
> > > > > ip ospf hello-interval 10
> > > > > ip ospf priority 10
> > > > > frame-relay map ip 140.11.51.3 103 broadcast
> > > > > frame-relay map ip 140.11.51.4 104 broadcast
> > > > >
> > > > > router ospf 1
> > > > > network 140.11.51.0 0.0.0.255 area 0
> > > > > neighbor 140.11.51.3 priority 1 poll-interval 30
> > > > > neighbor 140.11.51.4 priority 1 poll-interval 30
> > > > >
> > > > > r5# sh ip ro
> > > > > O 140.11.33.1/32 [110/1786] via 140.11.51.3,
> > > > > 00:17:23, Serial0.3
> > > > > O 140.11.44.1/32 [110/1786] via 140.11.51.4,
> > > > > 00:17:23, Serial0.3
> > > > > C 140.11.51.0/24 is directly connected,
> > > > > Serial0.3
> > > > >
> > > > > =====> r3 & r4 (basically the same, except the
> > > > > obvious) <===
> > > > >
> > > > > interface loopback 0
> > > > > ip address 140.11.33.1 255.255.255.0
> > > > > (r4's loop is 140.11.44.1/24)
> > > > >
> > > > > interface Serial0
> > > > > ip address 140.11.51.3 255.255.255.0
> > > > > encapsulation frame-relay
> > > > > ip ospf network non-broadcast
> > > > > ip ospf hello-interval 10
> > > > > frame-relay map ip 140.11.51.5 301 broadcast
> > > > >
> > > > > router ospf 1
> > > > > network 140.11.33.0 0.0.0.255 area 0
> > > > > network 140.11.51.0 0.0.0.255 area 0
> > > > > neighbor 140.11.51.5 priority 10 poll-interval 30
> > > > >
> > > > > r3# sh ip ro
> > > > > C 140.11.33.0/24 is directly connected,
> > > > > Loopback0
> > > > > O 140.11.44.1/32 [110/65] via 140.11.51.4,
> > > > > 00:20:58, Serial0
> > > > > C 140.11.51.0/24 is directly connected,
> > > > > Serial0
> > > > >
> > > > > as you can see, both loopbacks show up in the
> > > > > spoke's
> > > > > routing tables but the spokes can't ping each
> > > > other.
> > > > > the DR is the hub already.
> > > > >
> > > > > Please help.
> > > > > Thanks in advance.
> > > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:16 GMT-3