ATM to Frame-Relay config 1

[flojr13]

Hello all!

I currently have to Cisco Routers, a 7200 in Los Angeles and a 2600 in San Diego. Currently, both are connected over a frame-relay network. We are migrating the LA side to an ATM DS-3, but keeping frame-relay on the remote side.

During a recent attempt to migrate SD, the SBC engineer determined that everything was working (SD exchanging LMIs, LA receving OAM replies). Interfaces on both sides showing up/up. (No ACLs being used).

My problem is neither router could ping each other. A 'debug ip icmp' on the SD side shows icmp requests being recv'd (when ping is originated from LA), and replies being sent, but they never get back to LA.

Doing my research, the best I can come up with is that there is some sort of encapsulation mismatch. Please take a look at the configs below and let me know what you think.

Thanks!

-Flo

--------------
Florencio Umel Jr.
Network Engineer
Novacoast Inc.
--------------

LA 7200 Config:
interface ATM2/0
description -- ATM DS3 to WAN via SBC --
no ip address
atm scrambling cell-payload
atm framing cbitplcp
no atm ilmi-keepalive
!
interface ATM2/0.3 point-to-point
description -- ATM to SAN DIEGO --
ip address 10.253.3.1 255.255.255.0
pvc SDATM 1/55
protocol ip 10.253.3.2
vbr-nrt 3632 3632 1
oam-pvc manage
encapsulation aal5snap
-----
SD Config:

interface Serial0/0
description - Frame to LA
ip address 10.253.3.2 255.255.255.0
encapsulation frame-relay
no ip mroute-cache
logging event dlci-status-change
ipx network F03
no fair-queue
frame-relay interface-dlci 16
frame-relay lmi-type ansi

 

[l1carter]

Flo -

I have lots of experience in the FR/ATM areana. We have converted over 100 of our remote locations to a similar technology. Just a couple of things...

1. Telco needs to have your ATM pvc configured to TRANSLATIONAL since this is a FRATM circuit. You would probably be supprised how many times SBC has missed that here in Missouri.

2. oam-pvc manage - this command is probably left there becasue you had OAM configured at one time. Now that you are using a FRATM solution your TELCO will have to provide OAM keepalives if your interface is to go up/up which you said it is. This is because frame-relay does not use OAM Cells for its keep alives.

3. This has worked a time or two.. On your frame relay configuration configure your frame encapsulation like this:

encapsulation frame-relay IETF

You would be supprised but if you have Cisco encapsulation the default. FRATM can cause the very problem you are talking about packets making it to one end and failing on the return path.

Some good commands to use for FRAME and ATM are listed below:



FRAME RELAY

show frame pvc
show frame lmi

ATM

show atm pvc vpi/vci
this shows good input/output packets:


look below for sample working configurations

ATM Side...

interface ATM8/0/0.2383 point-to-point
description To R-SJFredricks Serial0/1.1 43.---.001482..SUV
bandwidth 1536
ip address x.x.x.57 x.x.x.x
pvc 2/383
protocol ip y.y.y.58 broadcast
protocol ipx 9BE2D8.00b0.6452.0fe0 broadcast
vbr-nrt 1500 1500 32
encapsulation aal5snap
!
ipx network 9BE2DC


FRAME-RELAY side...
interface Serial0/1
description r-dc-7513 atm8/0/0.2383 (43.----.001482..SUV)
no ip address
encapsulation frame-relay IETF
fair-queue
frame-relay lmi-type ansi
!
interface Serial0/1.1 point-to-point
description to r-dc-7513 atm8/0/0.2383 (43.----.001482..SUV)
bandwidth 1536
ip address y.y.y.58 255.255.255.252
ipx network 9BE2DC
frame-relay interface-dlci 383