From: anbu shanmugam (anbushan@xxxxxxxxx)
Date: Tue Nov 23 1999 - 18:51:10 GMT-3
hi,
oops!! iam sorry i thought replying to any mail
will go to the list.
peace!!!
thanks
shan
--- Priscilla Oppenheimer <cilla@priscilla.com> wrote:
> Why didn't you send this to the list? It sounds like
> the solution. It was someone else who was asking,
> not me.
>
> Priscilla
>
>
> At 06:59 AM 11/23/1999 -0800, anbu shanmugam wrote:
> >hi,
> >
> >try configuring
> >
> >appletalk local-routing
> >
> >on all routers in
> >the multipoint subnet.
> >
> >it worked for me.
> >
> >shan
> >
> >--- Priscilla Oppenheimer <cilla@priscilla.com>
> wrote:
> >> I think you may be right that there is no
> solution.
> >> In IP, we know the router can take in packets on
> an
> >> interface and send them back out the same
> interface,
> >> because we have commands such as "ip route-cache
> >> same interface." But there doesn't seem to be an
> >> equivalent parameter for "appletalk route-cache."
> >>
> >> I hope somebody else is following this train and
> can
> >> advise?
> >>
> >> Priscilla
> >>
> >>
> >> At 06:05 PM 11/22/1999 -0600, Steve Dispensa
> wrote:
> >> >First off, yes, I used appletalk pings. There
> was
> >> IP configured on the
> >> >interface also, and it worked fine. In fact,
> all
> >> three frame interfaces
> >> >were part of the same IP subnet - just like the
> >> appletalk config.
> >> >
> >> >Second, I searched around on CCO, and that
> >> paragraph appears verbatim in
> >> >several places, but it is the only paragraph to
> >> explain it this way. It
> >> >seems like the descriptions on the reference
> pages
> >> are a lot clearer.
> >> >
> >> >The lab required a single subinterface, so the
> >> multiple-subinterface thing
> >> >is out. That does seem like the most logical
> >> config, though. Chalk it up
> >> >to lab-isms. The lab required that the frame
> relay
> >> interfaces be configured
> >> >on the same appletalk network, so that would
> >> require a single logical
> >> >interface on A.
> >> >
> >> >During the brief troubleshooting that I did
> before
> >> moving on, I created
> >> >static frame maps and did some packet tracing on
> >> the pings. I confirmed
> >> >that the pings from B to C were in fact reaching
> A,
> >> but A wasn't
> >> >re-packaging them into frames and sending them
> to
> >> C. IP does this well - a
> >> >frame relay interface will "unpack" an IP
> datagram,
> >> look at its destination
> >> >address, and put it back on the wire if it needs
> to
> >> be sent on a different
> >> >PVC. I guess Cisco just didn't build that
> >> functionality into AppleTalk?
> >> >
> >> >The more I think about it, the more I think that
> >> this config just won't
> >> >work. That would explain why its solution is
> >> mysteriously missing from the
> >> >solutions packet I was given.
> >> >
> >> > - Steve
> >> >
> >>
>
>>----------------------------------------------------------------------------
> >> >--------
> >> >#include <dispensa.mwis.net/std_disclaimer.h>
> >> >
> >> >
> >> >----- Original Message -----
> >> >From: Priscilla Oppenheimer
> <cilla@priscilla.com>
> >> >To: <cisco@groupstudy.com>
> >> >Sent: Monday, November 22, 1999 4:57 PM
> >> >Subject: Re: Appletalk split-horizon
> >> >
> >> >
> >> >> It sounds like the CCO explanation is a bit
> >> garbled, but the issue has to
> >> >do with split horizon, which has to do with
> routing
> >> protocols, as I think
> >> >you know. AppleTalk RTMP requires split horizon
> and
> >> Cisco doesn't officially
> >> >support you turning it off.
>
> >> >>
> >> >> In your example, Router A won't send RTMP
> routing
> >> updates that reference B
> >> >or C networks out its serial port because it
> >> received them on its serial
> >> >port. So B never learns about C, and vice versa,
> >> which explains your
> >> >inablity to do AppleTalk pings. (I'm assuming
> you
> >> tested this with AppleTalk
> >> >pings, since your subject line mentions
> AppleTalk?
> >> If it was actually an IP
> >> >issue, let us know.)
> >> >>
> >> >> But if you set up Router A with two
> >> subinterfaces, one for each link, then
> >> >you'll be OK, because the split horizon rule is
> >> based on subinterfaces then,
> >> >not actual interfaces.
> >> >>
> >> >> The other solution is to use EIGRP for
> AppleTalk,
> >> in which case turning of
> >> >split horizon is supported.
> >> >>
> >> >> Priscilla
> >> >>
> >> >> At 04:12 PM 11/22/1999 -0600, Steve Dispensa
> >> wrote:
> >> >> >From
> >> >>
> >>
>
>>>http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/112cg_cr/4c
> >> >b
> >> >> >ook/4cfrelay.htm on CCO:
> >> >> >
> >> >> >"Additionally, certain protocols such as
> >> AppleTalk and transparent
> >> >bridging
> >>
> >> >> >cannot be supported on partially meshed
> networks
> >> because they require
> >> >"split
> >> >> >horizon," in which a packet received on an
> >> interface cannot be
> >> >transmitted
> >> >> >out the same interface even if the packet is
> >> received and transmitted on
> >> >> >different virtual circuits."
> >> >> >
> >> >> >If I'm reading this right, it's saying that
> all
> >> packets (not just routing
> >> >> >updates) are blocked by split-horizon, which
> is
> >> a pretty significant
> >> >> >departure from its usual meaning.
> >> >> >
> >> >> >I was just asked to do this in a practice lab
> >> with the following
> >> >> >configuration:
> >> >> >
> >> >> > A
> >> >> > / \
> >> >> > B C
> >> >> >
> >> >> >This is a frame cloud with PVC's from A-B and
> >> A-C. A had a single serial
> >> >> >point-multipoint subinterface supporting both
> >> PVCs. I added static frame
> >> >> >map statements on all three routers, but I
> could
> >> never get B to ping C.
> >> >A,
> >> >> >B, and C were configured as part of the same
> >> network, per the lab
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:21:55 GMT-3