cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1005
Views
5
Helpful
21
Replies

Problem with T1 bridge w/2 1720 routers performance slow

xtremenet
Level 1
Level 1

I have a partial bridged T1 using 2 Cisco 1720 routers and the speed is very slow from lan to lan.

Here is the config:

Using 646 out of 29688 bytes

!

version 12.2

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname GW-MAC

!

logging queue-limit 100

enable secret 5 xxxxxxxxx

enable password xxxxxxx

!

memory-size iomem 25

ip subnet-zero

no ip routing

!

!

!

!

interface FastEthernet0

no ip address

no ip route-cache

no ip route-cache

full-duplex

bridge-group 1

!

interface Serial0

ip address 192.168.20.201 255.255.255.0

encapsulation ppp

no ip route-cache

bridge-group 1

!

ip classless

no ip http server

!

bridge 1 protocol ieee

!

line con 0

line aux 0

line vty 0 4

password xxxxxx

login

!

no scheduler allocate

Same config both sides with different host name and IP.

21 Replies 21

pciaccio
Level 4
Level 4

Try enabling route cache on all interfaces involved. So for the FE0 and Ser 0 use the IP ROUTE-CACHE. Do this for the remote end as well... This will speed up the processing speed through the routers/bridges... Also verify the T-1 is no taking any errors. Do you have a full T-1 bandwidth or a fractional speed T-1? Verify that your DS0's are set up correctly and the same goes for the remote end... Good Luck..Please rate...

I will try the Cache. It is a partial T1 with 20 channels. The following is my new config.

memory-size iomem 25

ip subnet-zero

no ip routing

!

!

!

!

interface FastEthernet0

no ip address

no ip route-cache

speed auto

full-duplex

bridge-group 1

!

interface Serial0

ip address 192.168.20.201 255.255.255.0

encapsulation ppp

no ip route-cache

service-module t1 timeslots 20

bridge-group 1

!

ip classless

no ip http server

!

bridge 1 protocol ieee

!

Vern

Since you have configured no ip routing on the router there will not be any ip route cache anyway. So configuring no ip route-cache will not change anything.

Perhaps I am a bit confused in your original post you referred to it as a partially bridged situation. With no ip routing configured and bridge-groups on the interfaces it looks fully bridged to me. Was the partial in reference to the partial T1 or is it something else that you meant?

Since you are taking traffic that normally moves at 100 Mb and sending it over a link of about 1.2 Mb (including all the broadcast traffic that is normal on a LAN) I would expect an impact on performance. What does the traffic level look like in show interface serial 0? (It might help to make the measurement interval 30 seconds instead of the normal 5 minutes so that you get a better picture of traffic that may be bursty) I am guessing that the slowness is the impact of the slow link.

HTH

Rick

HTH

Rick

Rick,

It's in reference to the T1. It is fully bridged. The circuit was bridged through 2 Adtran 850's with a different ISP. The switched ISP's and we purchased 2 1720'S. Now the circuit uses the same amount of T1 channels but the performance with RDP and Citrix is very poor.

Vern

Thanks for clarifying what was partial. That makes sense.

I am not sure how the 850s were set up or what they might have done to optimize performance over the T1. The config of the 1720 is quite straightforward and I have not yet seen any issue in the config that would impact performance. I wonder if there might be some issue with the T1 or with the service module that is preventing full utilization of the T1. Perhaps you could post the output of show interface serial 0 and of show service-module?

HTH

Rick

HTH

Rick

I did not have access to the 850's. I will send the info from the serial interface later.

I attempted to enable IP routing remotely and have lost access to the router. I will need to go and attach with the console. I was working from home.

Vern

I am sorry that you lost access to the router. Turning on IP routing on a device that has been configured only for bridging does carry the risk that access will be lost. I have a couple of suggestions for the next time that you try something like that:

- the IOS allows you to reschedule a reload. You can use the command reload in or reload at hh:mm and the router will reload when you indicate. Before you make changes in the config schedule a reload (allow yourself enough time for the changes plus a little margin). Then make the changes. If the change does make you lose access just wait for the scheduled reload. The reload will get rid of the changes that you made (they were not saved to NVRAM) and gets you back to where you started and you have access again. If you make the changes and still have access (the changes were successful) then use the command reload cancel to cancel the scheduled reload.

- make changes on the remote device first. When you make the change on the remote then access will be lost. But when you make the corresponding change on the near device it may restore access. If you change the near device first and lose access then there is no way to get to the remote to make the corresponding change.

HTH

Rick

HTH

Rick

Rick,

here is the serial interface output:

GW-NBG#sho int ser 0

Serial0 is up, line protocol is up

Hardware is PQUICC with Fractional T1 CSU/DSU

Internet address is 192.168.20.201/24

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,

reliability 255/255, txload 7/255, rxload 3/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

LCP Open

Open: BRIDGECP, IPCP, CDPCP

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

Last clearing of "show interface" counters 2d03h

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

Queueing strategy: weighted fair

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

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

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 48 kilobits/sec

5 minute input rate 1000 bits/sec, 2 packets/sec

5 minute output rate 2000 bits/sec, 4 packets/sec

71290 packets input, 9355206 bytes, 0 no buffer

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

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

111724 packets output, 6017973 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

1 carrier transitions

DCD=up DSR=up DTR=up RTS=up CTS=up

GW-NBG#

Vern

This certainly does not show much load on the serial interface. I wonder whether it represents a time when users are trying to do something and experiencing slowness or is it Sunday night when there is little traffic (which I suspect is the case)? In which case it might help to do the show commands again at a time when it is more busy.

I do not a couple of things:

- the interface things that its BW is only 64 K where your post indicates that it should be over 1 Mb (BW 64 Kbit) and that after allowing for overhead the remaining bandwidth is 48 K (Available Bandwidth 48 kilobits/sec). We might want to check into why this difference.

- I notice that IPCP is open on the serial interface. This is appropriate since there is an IP address configured on the interface. Since the router is just bridging the IP address could be on any interface. I suggest moving the IP address from the serial interface to the FastEthernet interface (on both routers) and see if that makes any difference.

HTH

Rick

HTH

Rick

Rick,

You are correct about Sunday. They are in the office today and it's very slow.

Should I set the bandwidth on the serial interface?

I will need to go to each sight to change the IP to the Fast Ethernet.

I believe I may have some issues with the clocking. Could be due to a noisy serial interface. I will replace the cables with sheilded.

I am not sure if I should set the clock rate.

ilya.varlashkin
Level 3
Level 3

1720 is not up for job - it's too slow. Bridging on this platform is done in the software, and process switching performance of this router is only some 700Kbps.

Besides, bridging fast LAN links over slow WAN link will quickly fill up interface buffers so you'll see a lot of packet drops.

Best solution would be to redesign your setup so that traffic between LAN's is routed and only really necessary traffic is sent over the WAN link.

Actually there is no problem in using bridging on a 1720 with T1.

The normal routers including 1720 do everything in software, bridging, routing or whatever.

I agree that a routed design would be easier to design, implement and troubleshoot. But technically speaking, the performances should be the same.

The only traffic passing through the bridge is RDP (Remote Desktop) and some internet.

The bridge should handle this without a problem. I do think I have a clocking issue due to a noisy serial connection. I am currently preparing to change cables and troubleshoot the serial interfaces.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card