From: Nathan Casassa (ncasassa@xxxxxxxxxxx)
Date: Thu May 31 2001 - 22:32:21 GMT-3
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:30:58 GMT-3