Download Cisco.PracticeDumps.400-101.2017-11-11.1e.470q.vcex

Sometimes, over some IP paths, a TCP/IP node can send small amounts of data (typically less than 1500 bytes) with no difficulty, but transmission attempts with larger amounts of data hang, then time out. Often this is observed as a unidirectional problem in that large data transfers succeed in one direction but fail in the other direction. This problem is likely caused by the TCP MSS value, PMTUD failure, different LAN media types, or defective links. ReferencE. http://www.cisco.com/c/en/us/support/docs/additional-legacy-protocols/ms-windows- networking/13709-38.html

Here we see that the Time to Live (TTL) value of the packet is one, so it will be forwarded to the next hop router, but then dropped because the TTL value will be 0 at the next hop.

In this example we see that the source interface and destination interface are the same (Et0/0). Typically this is seen when there is a routing loop for the destination IP address.

Tail Drop 
Tail drop treats all traffic equally and does not differentiate between classes of service. Queues fill during periods of congestion. When the output queue is full and tail drop is in effect, packets are dropped until the congestion is eliminated and the queue is no longer full. 
Weighted Random Early Detection 
WRED avoids the globalization problems that occur when tail drop is used as the congestion avoidance mechanism on the router. Global synchronization occurs as waves of congestion crest only to be followed by troughs during which the transmission link is not fully utilized. Global synchronization of TCP hosts, for example, can occur because packets are dropped all at once. Global synchronization manifests when multiple TCP hosts reduce their transmission rates in response to packet dropping, then increase their transmission rates once again when the congestion is reduced. 
ReferencE. 
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfconav.html#wp1002

It is a general best practice to not mix TCP-based traffic with UDP-based traffic (especially Streaming- Video) within a single service-provider class because of the behaviors of these protocols during periods of congestion. Specifically, TCP transmitters throttle back flows when drops are detected. Although some UDP applications have application-level windowing, flow control, and retransmission capabilities, most UDP transmitters are completely oblivious to drops and, thus, never lower transmission rates because of dropping. 
When TCP flows are combined with UDP flows within a single service-provider class and the class experiences congestion, TCP flows continually lower their transmission rates, potentially giving up their bandwidth to UDP flows that are oblivious to drops. This effect is called TCP starvation/UDP dominance. 
TCP starvation/UDP dominance likely occurs if (TCP-based) Mission-Critical Data is assigned to the same service-provider class as (UDP-based) Streaming-Video and the class experiences sustained congestion. Even if WRED or other TCP congestion control mechanisms are enabled on the service- provider class, the same behavior would be observed because WRED (for the most part) manages congestion only on TCP-based flows. 
ReferencE. 
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND- Book/VPNQoS.html

L3HWFORWADING-2 
Error Message C4K_L3HWFORWARDING-2-FWDCAMFULL:L3 routing table is full. Switching to software forwarding.
The hardware routing table is full; forwarding takes place in the software instead. The switch performance might be degraded. 
Recommended Action Reduce the size of the routing table. Enter the ip cef command to return to hardware forwarding. 
ReferencE. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12- 2/31sg/system/message/message/emsg.html

Micro-bursting is a phenomenon where rapid bursts of data packets are sent in quick succession, leading to periods of full line-rate transmission that can overflow packet buffers of the network stack, both in network endpoints and routers and switches inside the network. Symptoms of micro bursts will manifest in the form of ignores and/ or overruns (also shown as accumulated in "input error" counter within show interface output). This is indicative of receive ring and corresponding packet buffer being overwhelmed due to data bursts coming in over extremely short period of time (microseconds). You will never see a sustained data traffic within show interface's "input rate" counter as they are averaging bits per second (bps) over 5 minutes by default (way too long to account for microbursts). You can understand microbursts from a scenario where a 3-lane highway merging into a single lane at rush hour  the capacity burst cannot exceed the total available bandwidth (i.e. single lane), but it can saturate it for a period of time. 
ReferencE. http://ccieordie.com/?tag=micro-burst

This is an example of a conditional debug, where there is a single condition specified of IP address 172.16.129.4. so all IP events for that address will be output in the debug.

The maximum segment size (MSS) is a parameter of the Options field of the TCP header that specifies the largest amount of data, specified in octets, that a computer or communications device can receive in a single TCP segment. It does not count the TCP header or the IP header. The IP datagram containing a TCP segment may be self-contained within a single packet, or it may be reconstructed from several fragmented pieces; either way, the MSS limit applies to the total amount of data contained in the final, reconstructed TCP segment. 
The default TCP Maximum Segment Size is 536. Where a host wishes to set the maximum segment size to a value other than the default, the maximum segment size is specified as a TCP option, initially in the TCP SYN packet during the TCP handshake. The value cannot be changed after the connection is established. 
ReferencE. http://en.wikipedia.org/wiki/Maximum_segment_size

An IOS device configured for IP+MPLS routing uses three different Maximum Transmission Unit (MTU) values: The hardware MTU configured with the mtu interface configuration command The hardware MTU specifies the maximum packet length the interface can support ... or at least that's the theory behind it. In reality, longer packets can be sent (assuming the hardware interface chipset doesn't complain); therefore you can configure MPLS MTU to be larger than the interface MTU and still have a working network. Oversized packets might not be received correctly if the interface uses fixed-length buffers; platforms with scatter/gather architecture (also called particle buffers) usually survive incoming oversized packets.
IP MTU is used to determine whether am IP packet forwarded through an interface has to be fragmented. It has to be lower or equal to hardware MTU (and this limitation is enforced). If it equals the HW MTU, its value does not appear in the running configuration and it tracks the changes in HW MTU. For example, if you configure ip mtu 1300 on a Serial interface, it will appear in the running configuration as long as the hardware MTU is not equal to 1300 (and will not change as the HW MTU changes). However, as soon as the mtu 1300 is configured, the ip mtu 1300 command disappears from the configuration and the IP MTU yet again tracks the HW MTU. ReferencE. http://blog.ipspace.net/2007/10/tale-of-three-mtus.html