Need help configuring router! HELP!!!

[paradoxwd]

Hey,

Where I work we recently got two t1 lines and had someone, who really didn't know how, configure our Cisco 3640 router. No one in our office really knows how to configure routers either, so during attempts to improve the performance of the configuration, we probably screwed it up a bit more.

BGP is working fine, but only 1 of our t1 lines seems to be doing all the work. The other line is barely doing anything at all. Download speeds are much lower than they should be and pings are all over the place. Not only are we running web servers and file servers, but we are also attempting to run a game server. Clients who connect to the game server have a good ping most of the time, but it continually spikes from 30 to 200 almost every second, making playing impossible.

One of the lines was original frame-relay, and was configured that way in the router. However, we had it switched to point-to-point, but every time I try to set encapsulation to ppp on that interface, the line protocol goes down and does not come back up. If anyone can help me at all, it would be truly appreciated.

Our running config is as follows:

version 12.2
service timestamps debug uptime
service timestamps log uptime
!
hostname Router
!
enable secret 5
!
ip subnet-zero
ip cef
!
!
ip domain-name alter.net
ip name-server 198.6.1.122
ip name-server 198.6.1.142
ip name-server 66.115.51.2
ip name-server 65.212.126.2
!
ip audit notify log
ip audit po max-events 100
!
!
!
interface Ethernet0/0
no ip address
shutdown
half-duplex
!
interface Serial0/0
description to UUNet u88932
bandwidth 1536
ip address 63.122.229.10 255.255.255.252
encapsulation frame-relay IETF
no ip mroute-cache
!
interface Ethernet0/1
no ip address
ip load-sharing per-packet
shutdown
half-duplex
!
interface Serial0/1
description ciberlynx line
bandwidth 1536
ip address 216.242.227.198 255.255.255.252
encapsulation ppp
no ip mroute-cache
no fair-queue
!
interface FastEthernet1/0
ip address 65.212.126.1 255.255.255.0 secondary
ip address 66.115.51.1 255.255.255.0 secondary
ip address 216.242.60.161 255.255.255.224
speed auto
full-duplex
!
router bgp 23325
no synchronization
bgp log-neighbor-changes
network 65.212.126.0 mask 255.255.255.0
network 66.115.51.0 mask 255.255.255.0
neighbor 63.122.229.9 remote-as 701
neighbor 63.122.229.9 version 4
neighbor 63.122.229.9 soft-reconfiguration inbound
neighbor 63.122.229.9 distribute-list 1 out
neighbor 216.242.227.197 remote-as 13488
neighbor 216.242.227.197 version 4
neighbor 216.242.227.197 soft-reconfiguration inbound
neighbor 216.242.227.197 distribute-list 1 out
maximum-paths 2
!
ip classless
ip route 0.0.0.0 0.0.0.0 216.242.227.197
ip route 65.212.126.0 255.255.255.0 Null0
ip route 66.115.51.0 255.255.255.0 Null0
ip route 216.242.60.160 255.255.255.224 Null0
ip http server
ip pim bidir-enable
!
access-list 1 permit 66.115.51.0 0.0.0.255
access-list 1 permit 65.212.126.0 0.0.0.255
access-list 1 deny any
!
line con 0
password
login
line aux 0
line vty 0 4
password
login
!
end

Again any assitance at all, will be truly appreciated. Thank you for your time and patience.

 

[CCIEWANNABE]

I Disagree with benzito
All we need to do is verify connection, verify proper LMI Types, verify active PVC status, and final verify Proper encapsulation matches.

It does start with baby steps but it’s a learning curve. A
LAN analysis is a little extreme when the issue is a configuration issue at best!
Route once; switch many

 

[benzito]

CCIE...what exactly are you disagreeing with??? I suggested LAN ANALYSIS when I'm mentioned that they forego running BGP. If they run BGP then they won't need to break the LAN up like they would w/ statics. If they DO run statics then they will need to analyze their LAN to determine what boxes are producing the most traffic and then segment their LAN accordingly. Maybe I didn't make that clear... Not having to break up the network in that fashion is one of the benefits of running BGP in this scenario.

Also...how can you be sure his problem stems purely from a configuration issue? How much memory does he have? What's his utilization like? Is the proc working overtime? Don't make simple assumptions...there are too many variables that have yet to be accounted for.

 

[benzito]

correction...wybnormal was the one that originally mentioned alternatives to bgp...not me!

 

[CCIEWANNABE]

Well from his postings of
show frame-relay pvc and
show frame-relay map and
debug frame-relay lmi

I can be pretty sure that he has a mismatched LMI or DLCI numbering. LMI is not properly exchanging between the router and the frame relay provider. Or his DLCI numbering is wrong. The PVC cannot be created and therefore is the issue.
A common mistake is the accidental reversal of DLCI numbering between sites.
I also notice that he is using a third party router because the sight is using encapsulation frame-relay IETF .

He also states.....
One of the lines was original frame-relay, and was configured that way in the router. However, we had it switched to point-to-point

The system worked in till they reconfigured an interface.

I just think that this is getting off topic and is a configuration issue.
I will tell you this get 3 eng. together and they will point out what the other eng. did wrong!
Route once; switch many

 

[paradoxwd]

ok... well i've changed the router config a bit and am now getting good steady pings with only the occasional spike. However, I am sure it could be better.

Current configuration : 2062 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
!
hostname Router
!
//password was here
!

ip subnet-zero
ip cef
!
!
ip domain-name alter.net
ip name-server 198.6.1.122
ip name-server 198.6.1.142
ip name-server 66.115.51.2
ip name-server 65.212.126.2
!
ip audit notify log
ip audit po max-events 100
!
!
!
interface Ethernet0/0
no ip address
shutdown
half-duplex
!
interface Serial0/0
description to UUNet u88932
bandwidth 1536
no ip address
encapsulation frame-relay
no ip mroute-cache
!
interface Serial0/0.1 point-to-point
bandwidth 1536
ip address 63.122.229.10 255.255.255.252
no ip mroute-cache
frame-relay interface-dlci 500 IETF
!
interface Ethernet0/1
no ip address
ip load-sharing per-packet
shutdown
half-duplex
!
interface Serial0/1
description ciberlynx line
bandwidth 1536
ip address 216.242.227.198 255.255.255.252
encapsulation ppp
no ip mroute-cache
no fair-queue
!
interface FastEthernet1/0
ip address 65.212.126.1 255.255.255.0 secondary
ip address 66.115.51.1 255.255.255.0 secondary
ip address 216.242.60.161 255.255.255.224
speed auto
full-duplex
!
router bgp 23325
no synchronization
bgp log-neighbor-changes
network 65.212.126.0 mask 255.255.255.0
network 66.115.51.0 mask 255.255.255.0
neighbor 63.122.229.9 remote-as 701
neighbor 63.122.229.9 version 4
neighbor 63.122.229.9 soft-reconfiguration inbound
neighbor 63.122.229.9 distribute-list 1 out
neighbor 216.242.227.197 remote-as 13488
neighbor 216.242.227.197 version 4
neighbor 216.242.227.197 soft-reconfiguration inbound
neighbor 216.242.227.197 distribute-list 1 out
!
ip classless
ip route 0.0.0.0 0.0.0.0 216.242.227.197
ip route 216.242.60.160 255.255.255.224 Null0
no ip http server
ip pim bidir-enable
!
access-list 1 permit 66.115.51.0 0.0.0.255
access-list 1 permit 65.212.126.0 0.0.0.255
access-list 1 deny any
!
line con 0
//password was here
login
line aux 0
line vty 0 4
//password was here
login
!
end

Sho interfaces:
Serial0/0 is up, line protocol is up
Hardware is QUICC with integrated T1 CSU/DSU
Description: to UUNet u88932
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 255/255, txload 199/255, rxload 15/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
LMI enq sent 13236, LMI stat recvd 13238, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 2210/0, interface broadc
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 1d12h
Input queue: 0/75/390/0 (size/max/drops/flushes); Total output drops:
Queueing strategy: weighted fair
Output queue: 0/1000/64/48376 (size/max total/threshold/drops)
Conversations 3/114/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1152 kilobits/sec
5 minute input rate 93000 bits/sec, 110 packets/sec
5 minute output rate 1199000 bits/sec, 208 packets/sec
12557162 packets input, 1523988998 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 8 giants, 0 throttles
1205 input errors, 83 CRC, 515 frame, 0 overrun, 0 ignored, 607 abo
23708902 packets output, 4111557410 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up

Serial0/0.1 is up, line protocol is up
Hardware is QUICC with integrated T1 CSU/DSU
Internet address is 63.122.229.10/30
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 255/255, txload 198/255, rxload 15/255
Encapsulation FRAME-RELAY

Serial0/1 is up, line protocol is up
Hardware is QUICC with integrated T1 CSU/DSU
Description: ciberlynx line
Internet address is 216.242.227.198/30
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 255/255, txload 29/255, rxload 5/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
LCP Open
Open: IPCP, CDPCP
Last input 00:00:29, output 00:00:00, output hang never
Last clearing of "show interface" counters 1d12h
Queueing strategy: fifo
Output queue 0/40, 3484 drops; input queue 0/75, 0 drops
5 minute input rate 36000 bits/sec, 49 packets/sec
5 minute output rate 180000 bits/sec, 23 packets/sec
9308101 packets input, 1552031238 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
4815476 packets output, 129705834 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up

I verified with Sprint (s0/1) that the config is fine. And the line with UUnet (worldcom) is not Point-to-Point; we had thought it was.

What seemed to fix most of the ping problems was removing some of the routes; I am thinking about removing the others, but I believe the default route is necessary.

I tried setting up a route for a specific server, and sending it through s0/0. It worked, but when I tried to make it go through s0/1, it didn't work at all. That server no long had access to the net.

Show frame-relay pvc:
PVC Statistics for interface Serial0/0 (Frame Relay DTE)

Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0

DLCI = 500, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

input pkts 12575851 output pkts 23801759 in bytes 1527098314
out bytes 4214323859 dropped pkts 0 in FECN pkts 8
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 2215 out bcast bytes 651210
pvc create time 3d00h, last time pvc status changed 14:17:17

Serial0/0.1 (up): point-to-point dlci, dlci 500(0x1F4,0x7C40), broadcast, IETF,
BW = 1536000
status defined, active

show frame-relay lmi:
LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 13277 Num Status msgs Rcvd 13279
Num Update Status Rcvd 0 Num Status Timeouts 1

Thank you all for your help.

 

[CCIEWANNABE]

I see you changed the LMI type from Ansi to Cisco
New Output: LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO

Old Output:
LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = ANSI
And that your corrected your encapsulation to Standard Frame relay
New Out Put: Encapsulation FRAME-RELAY
Old Output: encapsulation frame-relay IETF
Control Signals are fine.

Your last output does tell me you have some congestion:

For example FECN pkts 8 is the notification of congestion in the path. Check the protocols usage real carefully. Try to use Higher level protocols for flow control.
Route once; switch many

 

[paradoxwd]

Which protocols? What should I try? And any ideas on what was happening when I tried setting up the static route to use interface s0/1?

 

[wybnormal]

With the discussion on BGP here and the *whys*.. check out the clip below from a discussion group.

:::snip::::
Message: 1
Date: Wed, 29 May 2002 09:03:51 -0700
From: &quot;Luke Sheppard&quot; <luke@xxxxxx.com>
Subject: bgp meltdown

I sent this email last night, but I forgot that particular email account can't send stuff to SCCUG. However, this problem seems to still be going on:

12:45am 5/29/02...
If any of you are online right now, try doing traceroutes from multiple sites
to hosts in the 66.134.0.0/16 block. You will see one of the most spectacular
BGP meltdowns in recent memory taking place live on Level3's edge routers. This
seems to be a case of a moving black hole, occasionally manifesting itself in
temporary routing loops and (the dreaded) transit across private (RFC9118)
nets. It's been going on for several hours now Every traceroute holds a new
surprise! Try it from:

http://lg.level3.net/traceroute/traceroute.cgi

I'm not subscribed to Nanog's mailing list, but perhaps Jeff E. has some info
for us. I would not want to be the BGP admin at Level3 right now.

Luke

:::end snip:::

He's right, the admin for BGP is in deeep s***t right now. Not only with his people but all the other BGP admins who have to suffer until he gets it together again.

This is one of the reasons we were asking the reason for using BGP on this router. There are ways to isolate things but it's still dangerous.

Just thought to share

MikeS
Find me at

http://www.packetattack.com

&quot;The trouble with giving up civil rights is that you never get them back&quot;