10-21-2007 09:45 AM - edited 03-03-2019 07:16 PM
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.
10-21-2007 10:07 AM
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...
10-21-2007 10:24 AM
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
!
10-21-2007 12:09 PM
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
10-21-2007 03:28 PM
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.
10-21-2007 04:13 PM
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
10-21-2007 04:21 PM
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.
10-21-2007 05:26 PM
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
- 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
10-21-2007 07:02 PM
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#
10-22-2007 02:47 AM
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
10-22-2007 07:19 AM
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.
10-22-2007 08:39 AM
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.
10-22-2007 02:49 AM
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.
10-22-2007 07:35 AM
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.
10-22-2007 08:44 AM
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.
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: