[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1227
  • Last Modified:

in DE packets (cisco routers)

Hi all,
 
our customer A is complaining their access is slow via frame-relay, our check-up on the router found increasing number of DE packet(in)...
1)how does this affect our customer A access performance
2)what should we do to overcome this..look at the input/output rate, very low utilization, this customer subscribing 32k CIR.
 
pls help
 
rgds
nazri
 
CustomerA#sh frame-relay pvc
 
PVC Statistics for interface Serial1/3 (Frame Relay DTE)
 
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
 
DLCI = 172, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/3.172
 
  input pkts 19160         output pkts 26984        in bytes 5167257  
  out bytes 5403047        dropped pkts 0           in pkts dropped 0        
  out pkts dropped 0                out bytes dropped 0        
  in FECN pkts 83          in BECN pkts 3           out FECN pkts 0        
  out BECN pkts 0          in DE pkts 575           out DE pkts 0        
  out bcast pkts 1301      out bcast bytes 83264    
  5 minute input rate 9000 bits/sec, 5 packets/sec
  5 minute output rate 6000 bits/sec, 6 packets/sec
  pvc create time 2d14h, last time pvc status changed 01:45:12
CustomerA#sh clock
.07:27:39.737 CTT Wed Nov 5 2003

CustomerA#sh frame-relay pvc
 
PVC Statistics for interface Serial1/3 (Frame Relay DTE)
 
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
 
DLCI = 172, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/3.172
 
  input pkts 19877         output pkts 27901        in bytes 5363785  
  out bytes 5577926        dropped pkts 0           in pkts dropped 0        
  out pkts dropped 0                out bytes dropped 0        
  in FECN pkts 87          in BECN pkts 3           out FECN pkts 0        
  out BECN pkts 0          in DE pkts 635           out DE pkts 0        
  out bcast pkts 1339      out bcast bytes 85696    
  5 minute input rate 4000 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 2d14h, last time pvc status changed 01:48:08
0
mdnazri
Asked:
mdnazri
3 Solutions
 
guynumber5764Commented:
DE is not an issue.  It just means "Discard Eligible" and is like "nice" for packets.

FECN on the other hand means "Forward Explicit Congestion Notification."  It means the incoming data stream is encountering congestion.
0
 
cooleditCommented:
what kind of data is running over the Frame relay (remote offices) any kind of special servers ?
VOIP, or something else ?? Installation of new servers ?

asking the problem because I have been working in a cooperate where some people thought it would be very smart to make some servers do Etherchannel overnight without telliing the Network team
then I had the same kind of negotiation of speed plus dropped packets.
0
 
SteveJCommented:
There's nothing in the "show int" that helps diagnose or indicates a problem. The easiest thing to do with a frame network in diagnosing throughput and sluggishness issues is to start PINGing across the network with increasingly larger PING packets to make sure that things aren't getting fragged somewhere along the way. Also, as guy#4764 said, the FECN bits getting set may indicate that there's simply a congestion problem somewhere . . . How much oversubscription do you have at the head end site?

Good luck,
Steve
0
 
mvselmCommented:
DE packets are send for 2 reasons:
1) The customer makes a selection between important and less important services. The less important are send as DE. These will be dropped first if dropping is needed. I do not think this is the case unless you have a sophisticated customer (or you made it like that for them)
2) The customer sends traffic in peaks. The 5 minute average is low but the peaks are probably high. TCP applications trottle their transmission rate by sending until they lose packets (or ACKs take too long).

2 is the likely cause. The solution, traffic shaping. Modern routers can delay traffic that is outside the contract. Generally TCP performs not very well on FR with a CIR that low, if the CIR is actually enforced by the network, and you do not shape. This is because the clients and servers are to fast. Probably connected to a 100Mbps LAN. Also the router is fast. Hence, peaks. These peaks are likely to violate the CIR configured in the router. This traffic is marked DE. Shaping uses delaying of traffic. TCP works much better when packets are delayed as compared to packets that are dropped.

Marc
0

Featured Post

NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now