cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1088
Views
4
Helpful
15
Replies

what is C6880-X TX interface max throughput ?

Herman2018
Level 3
Level 3

hi , we have cisco 6880-x core switch and connected to 1 Gbps wan circuit. Now encountering packet discard issue on the interface connected to the wan circuit. The max transmit rate reached 350Mbps based on Solarwind monitoriing. Can anyone please advise why the transmitted packets start to drop, the circuit bandwidth is 1Gbps, and interface of C6880-x is Tx port with 1G SFP? What is the max performance throughput of C6880-X? Thanks in advance!

15 Replies 15

balaji.bandi
Hall of Fame
Hall of Fame

You may not get 100% of 1GB  due to other over heads, but you can reach at lease 80-90 % of interface speed. if this plain Layer 2 configuration.

what Sup card you have and what IOS Code running ? how is your Line card loaded - Fully  populated on that blade ?

how is your port configured ? do you see any packet drop when issue show interface x/x ? is your port negotiated 1GB full duplex ? 

if you connect PC and directly to ISP what speed you get ?

check some troubleshooting tips :

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/12027-53.html

 

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

thanks @balaji.bandi for your advice!  sup module PID is C6880-X-LE-SUP, software IOS v15.5. The interface is running on full duplex with 1G speed : Full-duplex, 1000Mb/s, media type is 1000BaseLH

interface config

Herman2018_0-1718331564219.png

 

When you connected to ISP, why do you have NAT Inside config, why you have MTU 1560 ?

check below example how INSIDE and OUTSIDE interface configured when you using Cat 6K switches :

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/97262-nat-cat665k-configex.html

is this possible you post show run removing confidential informaiton.

I am thinking you may have some kind of QOS configuration, also post show interface x/x (full output to look what kind of drops you see on the interface).

have you tested connecting PC directly ISP, what throughput you get ?

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Joseph W. Doherty
Hall of Fame
Hall of Fame

Very likley, max transmission rate, on 6880 gig interface is gig, both short term and sustained.

If you're seeing drops, common cause is oversubscription of interface, i.e. sending more than gig to interface.  Interface will queue excess, but there are limits to how much can be queued before excess is dropped.

As to why Solorwinds is showing a transmit rate of 340 Mbps, likely that's an average rate over time (5 minutes?).  By definition, interface always sends frames at line-rate.  Often short term micro bursts (microseconds to milliseconds), will overflow queue, but not be "seen" on longer term averages, often multi-second to multi-minute.

Thanks @Joseph W. Doherty . it is possible that the root cause is micros burst. the interval is 30 secs rather than 5mins we configured on the interface .

 load-interval 30

Firstly, Solarwinds may be using its own load interval timer, not the value (30 seconds) set on the interface.

Secondly, micro bursts are generally not visible at 30 seconds.  Again, they occur at the microsecond to millisecond time intervals (did you see the second reference I provided in my prior reply?).

BTW, from your later posted interface config, this is some form of private WAN link?

Can you have Solarwinds plot drops?  Too many drops will reduce throughput performance although I suspect that's not the case.

If you want to verify your WAN can provide gig throughput, use a UDP traffic generator.  With it you may be able to show interface can send at gig, and if p2p private link, far side receives gig.  Note - without QoS, such testing tends to disrupt concurrent prod traffic.

Leo Laohoo
Hall of Fame
Hall of Fame

@Herman2018 wrote:
The max transmit rate reached 350Mbps based on Solarwind monitoriing.

The 6840/6880 series family can do line rate at 1- and 10 Gbps. 

If Solarwinds report maximum rate of 350 Mbps, this means the upstream provider is unable to support 1 Gbps.  

"If Solarwinds report maximum rate of 350 Mbps, this means the upstream provider is unable to support 1 Gbps."

Certainly possible but wouldn't account for OP noting drops on their interface.


@Joseph W. Doherty wrote:
but wouldn't account for OP noting drops on their interface.

That depends if the "packet drops" @Herman2018 reported is actually "Total Output Drops" which I suspect the case to be.  

yes, it is shown on the C6880-x interface "Total Output Drops" when you run the command " sh int Tx/x/x", and also reflected on the solardwind , it shows the packets are discarded on that interface. 

thanks @Leo Laohoo for your advice. the problem is the packet dropped at C6880-x ,not upstream device, so seems not service provider issue. The queue of C6880x is not enough to store more packets? 

Hello @Herman2018 ,

there is flow control to be checked

if upstream device sends PAUSE frames the Cat6880 cannot send out packets that have to stay on the sofftware queue increasing the probability to be dropped.

the Cat 6880 cannot have performance issues on a simple 1GE port but it can be driven to drop by upstream device.

Each PAUSE frame stops transmission for a short time.

If so I agree with @Leo Laohoo that likely the circuit or service is not a full 1 GE

Hope to help

Giuseppe

 

Oh, excellent point if PAUSE frames are being used, although that's unusual usage because it can cause the issues @Giuseppe Larosa describes.  (Also why the later "data center" PAUSE Ethernet variants, can be selective about what's paused.)

That aside, I think it unlikely the problem is with the provider.  Don't misunderstand, certainly a provider could have capacity issues which don't allow you to obtain your full gig, assuming that's supposed to be available, but such issues tend to drop within the providers network, not the CE interface to PE (excluding the possibility of PAUSE frames - which you can easily check the interface to see if 6880 interface is enabled to accept [by default, off I recall?] - and if enabled, believe you might get a count of them too).

You noted your interface is running at a 30 second load interval, and as I noted, possibly Solarwinds is using even a longer load interval, such can show a lower thoughput average than you're actually obtaining during short intervals.

One factoid not described, is how many drops you're getting, and how often they are occurring.  Such information can tell much about what's happening.  BTW, a really high drop rate can drive average throughput to the floor.  One of the biggest throughput killers of TCP is transmission timeouts.

Also BTW, I'm a big fan of QoS (a tool for obtaining best/selective performance pushing traffic across a network), but one overlooked packet type, not usually mentioned for QoS special processing is TCP ACKs, regardless of application.  Specifically, trying to insure they are not dropped.

Anyway, my brower's AI has this to say:

Tcp transmission timeout

TCP (Transmission Control Protocol) is a transport-layer protocol that ensures reliable data transfer between devices over IP networks. One of the key mechanisms used by TCP to ensure reliable data transfer is the transmission timeout, also known as the Retransmission Timeout (RTO). The RTO is a timer that is started when a segment is sent by the sender, and it is used to determine when to retransmit a segment if no acknowledgment is received.

How TCP Transmission Timeout Works

When a segment is sent by the sender, the RTO is initialized to a default value, typically 3 seconds. The timer starts counting down from this value. If no acknowledgment is received for the segment before the timer expires, the segment is retransmitted. The timer is doubled after each retransmission, up to a maximum number of retransmissions, which is typically 5.

The RTO is adjusted on the fly to match the characteristics of the connection by using Smoothed Round Trip Time (SRTT) calculations. SRTT is a measure of the average round-trip time between the sender and receiver. The RTO is calculated as a function of SRTT, which ensures that the timer is adjusted to match the normal delay of the connection.

Factors Affecting TCP Transmission Timeout

Several factors can affect the TCP transmission timeout, including:

  1. Network congestion: If the network is congested, packets may be delayed or lost, causing the RTO to increase.
  2. Distance and latency: The distance between the sender and receiver can affect the RTO, as packets may take longer to travel.
  3. Network quality: The quality of the network can affect the RTO, with lower-quality networks resulting in longer timeouts.
  4. TCP implementation: Different TCP implementations may have different default RTO values and algorithms for adjusting the timer.

TCP Transmission Timeout in Practice

In practice, TCP transmission timeout can have a significant impact on network performance. For example:

  1. Retransmissions: If the RTO is too high, retransmissions may occur too frequently, leading to increased network congestion and decreased performance.
  2. Timeouts: If the RTO is too low, timeouts may occur too frequently, leading to packet loss and decreased performance.
  3. Network optimization: Optimizing the RTO can improve network performance by reducing retransmissions and timeouts.

Conclusion

In conclusion, TCP transmission timeout is a critical mechanism used by TCP to ensure reliable data transfer over IP networks. Understanding how TCP transmission timeout works and the factors that affect it is essential for optimizing network performance and troubleshooting network issues.

AI-generated answer. Please verify critical facts. Learn more
 
In summary, there are many things that can cause the issue you're having, yes, including WAN provider issues, but in my experience, a lower than expected transmission rate, if some time interval average, may be just that, an average, not to be confused with peak possible.  (Consider, have you ever done a large ping series, see a min/avg/max values?  Notice often how they are often not all the same value? [British Prime Minister Benjamin Disraeli, who said, “There are three kinds of lies: lies, damned lies, and statistics.” - laugh])
 
Likewise, with interface drops, usually just egress queues being overfilled, which doesn't always require oversubscription of bandwidth!  Consider, 9 gig ingress ports feeding a single 10g egress port.  No way there can be drops, correct?  Wrong (although unlikely).  What if all 9 ports send their traffic at about the same exact time?  The 10g port can only transmit one frame (even though 10x faster), so it must queue 8 frames.  What if the queue is 7 or less frame capacity?  Frames will be dropped!
 
Again, the prior example is unusual, but TCP in slow start will burst up to max RWIN before it settles to self clocking with return ACKs.  Insufficient queue size for this will cause drops too.

@Giuseppe Larosa @Joseph W. Doherty , thanks you both for your advices. I believe the ISP just applied QOS and set bandwidth to 1g, regarding flow control, normally just leave the default setting, right? how to check flow control? can you please advise, thanks.

Review Cisco Networking for a $25 gift card