Using a Cisco 2500 as a bridge

[treborvfr]

Hi,

I'm trying to use a Cisco 2500 as a very simple bridge to get a 2MB ADSL connection to a remote location. However I am having problems getting the two 2500's to talk to each other.

They are connected via a Nokia multiplexer using an X21 connection on Serial0 of the 2500's.

(The comms route was in use for many years until a few weeks ago using the same type of router but configured as routers.)

When I plug my laptop into the Console port of the 2500 I see the following messages:

%LINEPROTO-5-UPDOWN: Line protocol on Serial0, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Serial0, changed state to down

%LINEPROTO-5-UPDOWN: Line protocol on Serial0, changed state to up

etc.

The state changes every few seconds.

The details below may give someone in the know a clue as to what is wrong.

From Show running-config:

interface Ethernet0

no ip address

no ip route-cache

no ip mroute-cache

no mop enabled

bridge-group 1

bridge-group 1 priority 200

interface Serial0

no ip address

no ip route-cache

no ip mroute-cache

bridge-group 1

bridge-group 1 priority 200

and from show interfaces:

Ethernet0 is up, line protocol is up

Hardware is Lance, address is 0000.0c0a.3b99 (bia 0000.0c0a.3b99)

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255

Encapsulation ARPA, loopback not set, keepalive set (10 sec)

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:27, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

151 packets input, 36993 bytes, 0 no buffer

Received 151 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

0 input packets with dribble condition detected

4508 packets output, 301337 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

Serial0 is down, line protocol is down

Hardware is HD64570

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation HDLC, loopback not set, keepalive set (10 sec)

Last input 00:05:37, output 00:05:37, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0 (size/max/drops); Total output drops: 0

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/1/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

573 packets input, 12606 bytes, 0 no buffer

Received 573 broadcasts, 0 runts, 0 giants, 0 throttles

6 input errors, 6 CRC, 0 frame, 0 overrun, 0 ignored, 1 abort

2549 packets output, 152921 bytes, 0 underruns

0 output errors, 0 collisions, 425 interface resets

0 output buffer failures, 0 output buffers swapped out

383 carrier transitions

DCD=down DSR=down DTR=down RTS=down CTS=down

(Note I had unplugged the serial0 at the time of this print out)

Any help would be greatly appreciated, but please keep it simple, I'm a networking numpty!

(I have attached the whole of "show tech-support" print out)

Bob

[Richard Burts]

Since it is the serial interface that is bouncing it is hard to diagnose anything in the output generated while the serial interface was unplugged.

If the attached is the whole show tech-support I am surprised that there is no show controller serial output (but maybe it is because the interface was unplugged).

From the little bit of information that you give I would guess that the issue has to do with the Nokia multiplexer. The flapping line protocol up, line protocol down reflects failure of keepalives on the interface and is sometimes related to problems with clocking on the interface.

If you can provide any better information perhaps we could do a more effective diagnosis.

HTH

Rick

[treborvfr]

Hi Rick,

Thanks for the reply.

I disconnected the serial port because the updown error messages kept interspersing with what I was typing and the results that were generated.

How do I turn the up/down messages off? (and back on again!)

I don't think it is the Nokia link, as I said, that part of the circuit has not been touched and was working fine last time it was in use.

The only thing that has changed are the 2500 routers, they were removed when our company Intranet was upgraded to an 8MB circuit. Recently I found a use for the old 2MB circuit (for a private network) so the routers were reconfigured by our network guy (who, unfortunately, is currently on vacation) to provide the simple bridge I require for this new use.

I have carried out a remote loop back at the far end on the Nokia mux and the 2500 serial interface at my end stays up. (By the way, I'm the Telecomms Eng. on an offshore Gas Platform, know a bit about networks but not much!).

Earlier today I had someone ashore connect to the console on the onshore 2500, from what we can tell the configuration is set up the same as the offshore one.

One thing we considered was a clock/timing source. From what I can see there isn't one set at either end. Should one be set for this type of connection (X21)? The Nokia doesn't provide timing, it just passes the signal through.

I have reconnected the serial cable and done another two 'sh tech' one when the line protcol 'up' and the other when it was 'down', which I have attached. Fortunately once it is running the up/down messages don't interupt (but i would still like to know how to switch it off and on :-) )

Thanks again for your help.

Bob

[treborvfr]

I just realised that in those runs there was no no 'show controller serial' so I've run this seperately:

OFFSHORE_HEY_DSL#sh cont serial

HD unit 0, idb = 0x9D894, driver structure at 0xA2618

buffer size 1524 HD unit 0, X.21 cable

cpb = 0x1, eda = 0x4800, cda = 0x4814

RX ring with 16 entries at 0x4014800

00 bd_ptr=0x4800 pak=0x0A5020 ds=0x401E5B0 status=80 pak_size=22

01 bd_ptr=0x4814 pak=0x0A4AB0 ds=0x401D188 status=80 pak_size=0

02 bd_ptr=0x4828 pak=0x0A53C0 ds=0x401F320 status=80 pak_size=0

03 bd_ptr=0x483C pak=0x0A4E50 ds=0x401DEF8 status=80 pak_size=0

04 bd_ptr=0x4850 pak=0x0A4C80 ds=0x401D840 status=80 pak_size=0

05 bd_ptr=0x4864 pak=0x0A48E0 ds=0x401CAD0 status=80 pak_size=0

06 bd_ptr=0x4878 pak=0x0A4710 ds=0x401C418 status=80 pak_size=0

07 bd_ptr=0x488C pak=0x0A4540 ds=0x401BD60 status=80 pak_size=0

08 bd_ptr=0x48A0 pak=0x0A4370 ds=0x401B6A8 status=80 pak_size=0

09 bd_ptr=0x48B4 pak=0x0A41A0 ds=0x401AFF0 status=80 pak_size=0

10 bd_ptr=0x48C8 pak=0x0A3FD0 ds=0x401A938 status=80 pak_size=0

11 bd_ptr=0x48DC pak=0x0A3E00 ds=0x401A280 status=80 pak_size=0

12 bd_ptr=0x48F0 pak=0x0A3C30 ds=0x4019BC8 status=80 pak_size=0

13 bd_ptr=0x4904 pak=0x0A3A60 ds=0x4019510 status=80 pak_size=0

14 bd_ptr=0x4918 pak=0x0A3890 ds=0x4018E58 status=80 pak_size=0

15 bd_ptr=0x492C pak=0x0A36C0 ds=0x40187A0 status=80 pak_size=0

16 bd_ptr=0x4940 pak=0x0A34F0 ds=0x40180E8 status=80 pak_size=0

cpb = 0x1, eda = 0x5014, cda = 0x5014

TX ring with 2 entries at 0x4015000

00 bd_ptr=0x5000 pak=0x000000 ds=0x4046148 status=80 pak_size=28

01 bd_ptr=0x5014 pak=0x000000 ds=0x000000 status=80 pak_size=0

02 bd_ptr=0x5028 pak=0x000000 ds=0x000000 status=80 pak_size=0

0 missed datagrams, 0 overruns

0 bad datagram encapsulations, 0 memory errors

0 transmitter underruns

0 residual bit errors

HD unit 1, idb = 0xA6288, driver structure at 0xAB008

buffer size 1524 HD unit 1, No cable

cpb = 0x2, eda = 0x3140, cda = 0x3000

RX ring with 16 entries at 0x4023000

00 bd_ptr=0x3000 pak=0x0ADBE4 ds=0x402CDB0 status=00 pak_size=0

01 bd_ptr=0x3014 pak=0x0ADA14 ds=0x402C6F8 status=00 pak_size=0

02 bd_ptr=0x3028 pak=0x0AD844 ds=0x402C040 status=00 pak_size=0

03 bd_ptr=0x303C pak=0x0AD674 ds=0x402B988 status=00 pak_size=0

04 bd_ptr=0x3050 pak=0x0AD4A4 ds=0x402B2D0 status=00 pak_size=0

05 bd_ptr=0x3064 pak=0x0AD2D4 ds=0x402AC18 status=00 pak_size=0

06 bd_ptr=0x3078 pak=0x0AD104 ds=0x402A560 status=00 pak_size=0

07 bd_ptr=0x308C pak=0x0ACF34 ds=0x4029EA8 status=00 pak_size=0

08 bd_ptr=0x30A0 pak=0x0ACD64 ds=0x40297F0 status=00 pak_size=0

09 bd_ptr=0x30B4 pak=0x0ACB94 ds=0x4029138 status=00 pak_size=0

10 bd_ptr=0x30C8 pak=0x0AC9C4 ds=0x4028A80 status=00 pak_size=0

11 bd_ptr=0x30DC pak=0x0AC7F4 ds=0x40283C8 status=00 pak_size=0

12 bd_ptr=0x30F0 pak=0x0AC624 ds=0x4027D10 status=00 pak_size=0

13 bd_ptr=0x3104 pak=0x0AC454 ds=0x4027658 status=00 pak_size=0

14 bd_ptr=0x3118 pak=0x0AC284 ds=0x4026FA0 status=00 pak_size=0

15 bd_ptr=0x312C pak=0x0AC0B4 ds=0x40268E8 status=00 pak_size=0

16 bd_ptr=0x3140 pak=0x0ABEE4 ds=0x4026230 status=00 pak_size=0

cpb = 0x2, eda = 0x3800, cda = 0x3800

TX ring with 2 entries at 0x4023800

00 bd_ptr=0x3800 pak=0x000000 ds=0x000000 status=80 pak_size=0

01 bd_ptr=0x3814 pak=0x000000 ds=0x000000 status=80 pak_size=0

02 bd_ptr=0x3828 pak=0x000000 ds=0x000000 status=80 pak_size=0

0 missed datagrams, 0 overruns

0 bad datagram encapsulations, 0 memory errors

0 transmitter underruns

0 residual bit errors

OFFSHORE_HEY_DSL#

T/Y

Bob

[Richard Burts]

Bob

Thanks for sending the additional information. I am quite surprised that the show tech did not include show controller serial and I am glad that you did one and posted the results, even though it did not lead me to a solution.

Am I correct in understanding that your primary problem is the flapping state of the serial interface? Are there any other problem symptoms?

Let me say something about the logging messages and what you can do about them. When the interface changes state it generates a log message which is sent to the console and to any other logging location which might be specified (in your config no other location is specified). This log message is a "notification" severity level (level 5). Some people would supress the messages by turning off console logging but I think that is more drastic than is needed. If you add this line to the configuration:

logging console warnings

then the messages about the serial interface changing state will not be sent to the console. And when you want them back again change the config to this:

logging console debug

Be aware that when you set the console logging level to debug that it is the default value and default values do not show up in show running config so the line will seem to disappear. But it will still be effective so do not worry about it.

I am puzzled about what is causing this problem. The interface flapping like this reflects failure of the keepalives but I am not sure what is causing the keepalive problem.

Would it be possible to post the output of show interface (and perhaps show controller serial, and the interface config) from the router on the other end of the connection?

Is it possible that when the network was upgraded and this circuit was not being actively used that the provider has changed something about the circuit?

HTH

Rick

[treborvfr]

Hi Rick,

At present there are no other symptoms that I am aware of.

Thanks for the info on switching off the logging.

It is almost the end of the working day over here (UK) so I will see if I can get someone ashore to get the interface, controller and config details of the the other end of the link tomorrow.

The comms circuit is privately owned, there are only two of us that look after the configuration of it so I now nothing has been changed. The comms are 'mission critical' so everything is dual routed. We tried the routers on the other circuit with the same result.

Cheers

Bob

[treborvfr]

Hi again Rick,

Not sure what you mean by "the interface config", do you mean 'show tech-support'?

Bob

[Richard Burts]

Bob

It will be included in the show tech-support.

HTH

Rick

[treborvfr]

Rick,

I managed to get someone at the remote end to run the configs of, see attached.

I got him to switch on console debug and interestingly the line protocol is permanently down there. I placed a short DTE loopback on the Nokia mux at the far end and the protocol stayed down.

Could be a cable problem at the far end?

or is it clocking related? Should the Tx clock be inverted (if it isn't already)?

Cheers

Bob

[treborvfr]

Rick,

I managed to get someone at the remote end to run the configs of, see attached.

I got him to switch on console debug and interestingly the line protocol is permanently down there. I placed a short DTE loopback on the Nokia mux at the far end and the protocol stayed down.

Could be a cable problem at the far end?

or is it clocking related? Should the Tx clock be inverted (if it isn't already)?

Cheers

Bob

[Richard Burts · Accepted solution]

Bob

Thanks for the additinal information. I think it may point to something to investigate. I believe the first clue is in the show controller serial from the remote which includes this:

0 missed datagrams, 0 overruns

0 bad datagram encapsulations, 0 memory errors

0 transmitter underruns

9233 residual bit errors

I am not clear what the residual bit errors are but I believe they point to a problem with the serial connection.

I think it gets more clear in looking at the show interface of the serial interface:

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

62897 input errors, 62887 CRC, 2226 frame, 0 overrun, 0 ignored, 52450 abort

There are no good packets received. Every packet it has received has been an error.

This helps explain the symptoms. At the remote end the line protocol is down and stays down because it never receives a valid keepalive packet.

At your end you receive a keepalive from the remote and the line protocol comes up. The mine seen and your seen sequence numbers do not increment correctly and the line protocol on your end goes down. Then you receive a keepalive from the remote and the line protocol comes up, sequence numbers do not increment, and the cycle repeats over and over.

While I believe that this data confirms that there is a problem in the connection I am not sure that it tells what kind of problem or where the problem is. It might be a cable problem and probably the easy first step is to replace cables. It might be a clocking problem, though the fact that it looks like keepalives do get through to you makes me doubt it. I wonder if something might be mis-connected or mis-configured on the mux. Or it might be a problem in the circuit. Is this something that you can have checked?

HTH

Rick

[treborvfr]

Cheers Rick,

I'll get someone to check out the cables at the far end tomorrow and let you know how we get on.

Thanks

Bob

[treborvfr]

Rick,

At last I managed to get someone at the far end to check out the cabling. It turned out that the Cisco 60 to 15 pin cable was faulty. It is now all up and running and I am a happy bunny!

Thanks very much for all your help Rick, have a virtual beer on me!

Bob