From: Peter Whittle (peter@xxxxxxxxxxxxxxxxxxxxxxxxxxx)
Date: Tue Dec 04 2001 - 20:44:32 GMT-3
Chuck,
As Scott says I think that you need a DCE cable for the Cisco and to set
it up as the clock source.
The handshakes are showing nothing doing from the other end, i.e. no-
clock, & hware not ready.
I do not see a particular problem with the Cisco acting as a Frame-Relay
switch even in a back to back configuration.
1) Configure the Cisco as a switch:
'frame-relay switch' under global config
2) Configure the serial for frame relay.
'encapsulation frame-relay ietf' (the 3 Com is unlikely to
understand Cisco's form of IP in frame relay.)
3) Configure the clock rate (You only need to do this if the
Cisco is physical DCE)
'clock rate 64000'
4) Define frame relay interface type (actually LMI end for DCE (UNI-
network) NB this is independent of whether the Cisco is the physical DCE
and supplies the clock, it decides who will do LMI polls - normally the
UNI-user end (intf-type DTE in Cisco terms))
'frame-relay intf-type dce
5) Define the LMI type to use (You will have to use either CCITT Q.933
Annex A, or ANSI T.1.617 Annex D to talk to the 3 COM)
'lmi-type q933a'
6) Configure IP address on serial i/f in the normal way
7) either use frame-relay map ip ... or use frame-relay interface-dlci +
inverse arp in the normal way.
------------------
Show int s0
Should show both the physical as 'up' and the lmi as 'up'
Until you get the physical up then your wasting you time with every
thing else - check the pin outs and who is the dce / dte and that the
dce is providing clock.
You can run the Frame-Relay back to back by setting one end to be a
frame-relay switch (you are not going to do any frame relay switching,
there are no 'frame-relay route ...' statements!)
However, Cisco routers will only allow you to change the lmi intf-type
from UNI-user (dte) to UNI-network (dce) or to NNI (nni) if the router
is configured as a frame relay switch first!
Both routers must agree on lmi type, one end is UNI-user, the other is
UNI-network (switch). One end must physically be a DCE (providing
clock) though in our lab scenarios it is normally the switch it needn't
be.
(R1)-----------(R2)
Physical DCE DTE
clock rate
64000
FR UNI-user (dte) UNI-network (dce)
lmi type Q933a Q933a
dlci 16 16 NB must match on both ends
as we don't have a switch.
ip 10.1.1.1 10.1.1.2
I hope that this helps.
Peter
In message <296E48F89386B44A8BB87378A7054D56419B21@tnex1.tn.get>,
Pilkinton, Scott <SPilkinton@gaylordentertainment.com> writes
>Chuck,
>
>I believe your first problem is with your cabling. You will need a DCE
>cable on the Cisco side coupled together with your DTE cable connecting
>to the 3com side.
>
>If you're only going to use the two routers I don't believe you will
>have much success setting the Cisco up as a frame switch. You would
>need at least two routers hanging off the 2500 in order to switch
>to/from. However, you can setup PPP encapsulation between the two and
>you then should have a valid back-to-back config.
>
>Scott
>
>-----Original Message-----
>From: Church, Chuck [mailto:cchurch@USTA.com]
>Sent: Tuesday, December 04, 2001 11:57 AM
>To: 'ccielab@groupstudy.com'
>Cc: Trombly, Jeff
>Subject: OT - 3Com router back-to-back with 2500
>
>Anyone,
>
> I've got a 3Com Netbuilder II router I'm trying to use back to
>back
>with a 2500 router. I'm using the V.35 port on the 3Com, and a standard
>sync serial on the Cisco. The cable is a V.35 DTE, so the 3Com should
>be
>providing the clock. I want to try frame relay, using the Cisco as the
>frame switch. But the interfaces stay down on both sides. I've told
>the
>3Com to be the DCE side, using the clock - test mode setting. I tried
>using
>PPP on both sides as well, but I think it's a signaling problem, not a
>frame
>or PPP problem. Has anyone done this before? On the Cisco side, I've
>got
>DCD=down DSR=down DTR=up RTS=up CTS=down. I'm not sure what the 3Com is
>showing, because I'm not really sure where to find that. Any help would
>be
>appreciated.
>
>TIA,
>Chuck Church
-- Peter Whittle
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:37 GMT-3