AppleTalk over PPP with Cisco Dial-in Router

[DrDeke]

Do any of you remember anything about setting up dial-in equipment to support AppleTalk-over-PPP? I am trying to get this working on a Cisco 3845 for use with older Mac clients but am running into an issue where although the router successfully forwards AppleTalk packets from the dialup clients toward Ethernet-connected clients, it fails to forward packets from the Ethernet segment toward the PPP sessions, emitting errors like:

Async1/0: encapsulation failed AT packet: enctype PPP, size 34
%AT-7-DEBUGMSG: AppleTalk debug: Packet discarded,src 1.3-Unknown,dst 2.1-AEP,AEP,encapsulation failed

I've got a full writeup of the issue here including full configurations and debugging output, and would be very grateful if any of you have any insight into what I might be doing wrong. It would be really fun to get this working; I've never seen a classic Mac connect to an AppleTalk network over dialup before .

 

[cheesestraws]

Disclaimer: never run AT on a Cisco, only IP, so this may be wildly wrong, but:

Async1/0: encapsulation failed AT packet: enctype PPP, size 34

it looks like the appletalk packet has been constructed here but stuffing it into PPP has failed, so I'd start by looking at your PPP configuration here. What do the interface details of the PPP interface look like? Is there a packet size limit/MTU somewhere that needs to be set?

edit: also, what version of IOS are you running?

 

[DrDeke]

Greetings,

The PPP interfaces are configured as follows:

interface Group-Async0
ip unnumbered Loopback3
encapsulation ppp
dialer in-band
dialer idle-timeout 0
dialer-group 5
appletalk client-mode
async mode interactive
peer default ip address pool async
ppp authentication chap
ppp multilink
group-range 1/0 1/23
end

The MTU on the PPP interfaces has been using the default, which is 1500 bytes. I tried changing it to 512 by adding "mtu 512" to the Group-Async 0 configuration just now, and keep getting the same "encapsulation failed AT packet" errors. I'm really puzzled at this point about what the problem could be.

 

[DrDeke]

edit: also, what version of IOS are you running?

I have tried 12.4(25)d and 12.3(11)T10 so far and found the exact same behavior on both versions.

 

[cheesestraws]

Looking at your stackexchange post, you've posted debug output of PPP *authentication* and AppleTalk packets, but not PPP data plane. I don't know what the appropriate incantation is to get frame-level PPP output but there probably is one: this might be worth getting.

The reason I ask is that the "encap failed" pretty much means that the L3 packet can't be shoved into the L2 frame for some reason, often because some information is missing: so I wouldn't expect you to see any sensible debug output in the appletalk debug logs, you'll need to look at the PPP logs.

 

[DrDeke]

Why didn't I think of that?!

The available debug ppp options on the router are:

ypsi-c3845-1#debug ppp ?
authentication CHAP/PAP/MSCHAP/EAP authentication
bap BAP protocol transactions
cbcp Callback Control Protocol negotiation
elog PPP ELOGs
error Protocol errors and error statistics
forwarding PPP layer 2 forwarding
mppe MPPE Events
multilink Multilink activity
negotiation Protocol parameter negotiation
packet Low-level PPP packet dump

I started off by turning on debug ppp error, debug ppp forwarding, and debug ppp packet. With these options enabled, when I sent AppleTalk packets from the Mac over the PPP link, I got output like the following:

Feb 4 18:32:05.463: As1/1 PPP: I pkt type 0x0029, datagramsize 34 link[appletalk]
Feb 4 18:32:06.211: As1/1 PPP: I pkt type 0x0029, datagramsize 34 link[appletalk]
Feb 4 18:32:06.211: As1/1 PPP: I pkt type 0x0029, datagramsize 34 link[appletalk]
Feb 4 18:32:06.951: As1/1 PPP: I pkt type 0x0029, datagramsize 34 link[appletalk]
Feb 4 18:32:06.951: As1/1 PPP: I pkt type 0x0029, datagramsize 34 link[appletalk]

That makes sense to me; 0x0029 is the PPP protocol field value for AppleTalk. Unfortunately, when attempting to send AppleTalk packets from an Ethernet-connected host through the router over the PPP link (as well as from the router itself over the PPP link), I got no debugging output at all.

At this point, in case I was misunderstanding any of the available debugging options, I tried turning all of the PPP debugging options on:

ypsi-c3845-1#debug ppp authentication
PPP authentication debugging is on
ypsi-c3845-1#debug ppp bap
BAP general debugging is on
ypsi-c3845-1#debug ppp cbcp
PPP Callback Control Protocol debugging is on
ypsi-c3845-1#debug ppp elog ?
cps PPP elogs to measure cps
detailed PPP detailed elogs
keepalive PPP keepalive elogs
negotiation negotiation elog

ypsi-c3845-1#debug ppp elog cps
PPP Elogs for measuring CPS debugging is on
ypsi-c3845-1#debug ppp elog detailed
PPP Detailed Elogs debugging is on
ypsi-c3845-1#debug ppp elog keepalive
PPP Keepalive Elogs debugging is on
ypsi-c3845-1#debug ppp elog negotiation
PPP Negotiation Elogs debugging is on
ypsi-c3845-1#debug ppp error
PPP protocol errors debugging is on
ypsi-c3845-1#debug ppp forwarding
PPP forwarding events debugging is on
ypsi-c3845-1#debug ppp mppe ?
detailed MPPE Packet Details
events MPPE Events
packets MPPE Packets

ypsi-c3845-1#debug ppp mppe de
ypsi-c3845-1#debug ppp mppe detailed
MPPE Packet Details debugging is on
ypsi-c3845-1#debug ppp mppe events
MPPE Events debugging is on
ypsi-c3845-1#debug ppp mppe packets
MPPE Packets debugging is on
ypsi-c3845-1#debug ppp mu
ypsi-c3845-1#debug ppp multilink ?
data First bytes of multilink packet
events Multilink events
fragments Multilink fragments

ypsi-c3845-1#debug ppp multilink data
First bytes of multilink packet debugging is on
ypsi-c3845-1#debug ppp multilink events
Multilink events debugging is on
ypsi-c3845-1#debug ppp multilink fragments
Multilink fragments debugging is on
ypsi-c3845-1#debug ppp negotiation
PPP protocol negotiation debugging is on
ypsi-c3845-1#debug ppp packet
PPP packet display debugging is on

Unfortunately, this did not produce any relevant additional output. Out of desperation (and in thinking that there should be some additional debugging flags that might shine some light on this problem, but not having any idea what they might be), I tried running debug all. The router crashed a few seconds after I did that (despite having very little activity going on). I will power cycle it and try it again, but am less than hopeful that it will help.

 

[cheesestraws]

Sorry, lost track of this thread. Not that I have much useful to add. :-/

I tried running debug all. The router crashed a few seconds after I did that

The part of me that used to run Cisco stuff in production instinctively winced at this :-D.