What is Cisco IOS XE?
IOS XE represents the continuing evolution of Cisco's
pre-eminent IOS operating system. IOS XE is architected for routers, switches
and appliances, leveraging the years of functionality that is provided by IOS,
while adding new functionality and benefits from a POSIX environment. It provides
a set of system services that are targeted at the integration of network-aware
applications into the platform. IOS XE integrates a generic approach to network
management into every function.
IOS XE also provides a development, build and release
environment that will streamline efforts across the company by providing a
single system meeting a variety of products.
The IOS XE architecture and well-defined set of APIs
extend IOS to improve portability across platforms and extensibility outside
IOS. This extensibility opens up to a whole new paradigm for application
integration with IOS.
Why IOS XE?
The IOS feature set for routing and switching is
unmatched in the industry, delivering functionality required for business
critical applications. Preserving these advantages of IOS to our customers is
critical for Cisco.
IOS XE retains the exact same look and feel of IOS,
while providing enhanced future-proofing and improved functionality. In IOS XE,
IOS 15.0 runs as a single daemon within a modern Linux operating system.
Additional system functions now run as additional, separate processes in the
host OS environment. The operation, support and management of IOS XE does not
require re-training from classic IOS.
Pegado de <http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-xe-3sg/QA_C67-622903.html>
Load-Balance With CEF
Unicast flooding due to asymmetric routing
Remember: In
L3 Switches, the default ARP table aging time is 4 hours while the CAM holds
the entries for only 5 minutes.
Explain IP operations
Comparación IPv4 vs Ipv6
Header.
Internet Protocol being a
layer-3 protocol (OSI) takes data Segments from layer-4 (Transport) and divides
it into packets. IP packet encapsulates data unit received from above layer and
add to its own header information.
The encapsulated data is
referred to as IP Payload. IP header contains all the necessary information to
deliver the packet at the other end.
IP header includes many
relevant information including Version Number, which, in this context, is 4. Other details are as follows:
·
Version: Version no. of Internet Protocol used (e.g.
IPv4).
·
IHL: Internet Header Length; Length of entire IP
header.
·
DSCP: Differentiated Services Code Point; this is
Type of Service.
·
ECN: Explicit Congestion Notification; It carries
information about the congestion seen in the route.
·
Total
Length:
Length of entire IP Packet (including IP header and IP Payload).
·
Identification: If IP packet is fragmented during the
transmission, all the fragments contain same identification number. to identify
original IP packet they belong to.
·
Flags: As required by the network resources, if IP
Packet is too large to handle, these ‘flags’ tells if they can be fragmented or
not. In this 3-bit flag, the MSB is always set to ‘0’.
·
Fragment
Offset:
This offset tells the exact position of the fragment in the original IP Packet.
·
Time
to Live:
To avoid looping in the network, every packet is sent with some TTL value set,
which tells the network how many routers (hops) this packet can cross. At each
hop, its value is decremented by one and when the value reaches zero, the
packet is discarded.
·
Protocol: Tells the Network layer at the destination
host, to which Protocol this packet belongs to, i.e. the next level Protocol.
For example protocol number of ICMP is 1, TCP is 6 and UDP is 17.
·
Header
Checksum:
This field is used to keep checksum value of entire header which is then used
to check if the packet is received error-free.
·
Source
Address:
32-bit address of the Sender (or source) of the packet.
·
Destination
Address:
32-bit address of the Receiver (or destination) of the packet.
·
Options: This is optional field, which is used if the
value of IHL is greater than 5. These options may contain values for options
such as Security, Record Route, Time Stamp, etc.
ICMP Destination Unreachable es un tipo de paquete ICMP
cuya función es transportar un mensaje que es generado por un enrutador, y se envía al host de origen, que recibe el
mensaje emitido por el enrutador.
ICMP redirects
Cisco routers send ICMP
redirects when all of these conditions are met:
Note: ICMP redirects are disabled by default if Hot
Standby Router Protocol (HSRP) is configured on the interface. In Cisco IOS
Software Release 12.1(3)T and later, ICMP Redirect is allowed to be enabled on
interfaces configured with HSRP. For more information, refer to HSRP Support for ICMP Redirects section of Hot Standby Router Protocol Features
and Functionality.
Pasted from <http://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13714-43.html>
The Concept
IPv6 is using two distinct types of headers:
Main/Regular IPv6 Header and IPv6 Extension Headers. The main IPv6 header is
equivalent to the basic IPv4 one despite some field differences that are the
result of lessons learned from operating IPv4. Figure 1 presents the IPv4 and
IPv6 main headers.
Figure 1. IPv4 and IPv6 Headers
The options field in the IPv4 header is used
to convey additional information on the packet or on the way it should be
processed. Routers, unless instructed otherwise [1], must process the options
in the IPv4 header. The processing of most header options pushes the packet
into the slow path leading to a forwarding performance hit.
IPv4 Options perform a very important role in
the IP protocol operation therefore the capability had to be preserved in IPv6.
On the other hand, the impact of IPv4 Options on performance was taken into
consideration in the development of IPv6. The functionality of options is
removed from the main header and implemented through a set of additional
headers called extension headers [2]. The main header remains fixed in size (40
bytes) while customized EHs are added as needed. Figure 2 shows how the headers
are linked together in an IPv6 packet.
Figure 2. Chaining Extension Headers in IPv6 Packets
RFC2460 defines the extension headers as
shown in the following table along with the Next Header values assigned to
them:
Table
1. IPv6 Extension Headers and
their Recommended Order in a Packet
|
Order
|
Header Type
|
Next Header Code
|
|
1
|
Basic IPv6 Header
|
-
|
|
2
|
Hop-by-Hop Options
|
0
|
|
3
|
Destination Options (with Routing Options)
|
60
|
|
4
|
Routing Header
|
43
|
|
5
|
Fragment Header
|
44
|
|
6
|
Authentication
Header
|
51
|
|
7
|
Encapsulation
Security Payload Header
|
50
|
|
8
|
Destination Options
|
60
|
|
9
|
Mobility Header
|
135
|
|
|
No next header
|
59
|
|
Upper Layer
|
TCP
|
6
|
|
Upper Layer
|
UDP
|
17
|
|
Upper Layer
|
ICMPv6
|
58
|
RFC2460 also recommends the order in which
they should be chained in an IPv6 packet:
Pegado de <http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html>
TCP MMS
!FRAMETACION DE UN PAQUETE IP CUANDO YA VIENE
MARCADO CON EL FLAG ACTIVO, EJM APLICADO CUANDO USAS INTERNET OVER
DMVPN.
ip policy route-map
clear-df
route-map clear-df permit
10
match ip address 111 101
set ip df 0
access-list 101 permit tcp
any any
access-list 111 permit tcp
any any
!TCP MAXIMUNSIZE
So for a standard Ethernet
connection with minimum size IP and TCP headers we subtract 40 bytes from the
1500 byte standard packet size (minus the Ethernet Header) leaving us with an
MSS of 1460 bytes for data transmission.
IP FRAGMENTATION
NOTA:ESTE LABORATORIO SE REALIZO UTILIZANDO PAGENT IN IOU-WEB.
PC1#ping 192.168.4.5 size 200 repeat 1
Type escape sequence to
abort.
Sending 1, 200-byte ICMP
Echos to 192.168.4.5, timeout is 2 seconds:
!
Success rate is 100 percent
(1/1), round-trip min/avg/max = 4/4/4 ms
PC1#ping 192.168.4.5 size 2000 repeat 1
Type escape sequence to
abort.
Sending 1, 2000-byte ICMP
Echos to 192.168.4.5, timeout is 2 seconds:
!
Success rate is 100 percent
(1/1), round-trip min/avg/max = 4/4/4 ms
PC1#
R3(PKTS:1 of 10)#show all
# TD interface summary relative time
length
1 I Et0/1 IP ICMP (Echo
Request)
3.827999 214
2 O
Et0/1 IP ICMP (Echo Reply) 3.831999 214
3 I Et0/1 IP OSPF (Hello) 4.411999 94
4 O Et0/1 IP OSPF (Hello) 7.063999 94
5 I Et0/1 IP ICMP (Echo Request) 7.163999 1514
6 I Et0/1 IP
7.163999 534
7 O Et0/1 IP ICMP (Echo Reply) 7.167999 1514
8 O
Et0/1 IP
7.167999 534
9 O
Et0/1 KeepAlive
8.891999 60
10 O Et0/1 CDP (R3)(Linux Unix)(Ethernet0/1) 10.371999 327
R3(PKTS:1 of 10)#show 1
=============================================================================
04:49:33.379 CET Sun Jul 19
2015 Relative Time:
3.827999
Packet 1 of 10 In:
Ethernet0/1
Ethernet Packet: 214 bytes
Dest Addr: AABB.CC00.0310, Source Addr: AABB.CC00.0210
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x5,
TOS: 0x00
Length: 200, ID:
0x0014, Flags-Offset: 0x0000
TTL: 254, Protocol: 1 (ICMP), Checksum: 0x34CA (OK)
Source: 192.168.2.1, Dest: 192.168.4.5
ICMP Type: 8,
Code: 0 (Echo Request)
Checksum: 0x3415 (OK)
Identifier: 0004, Sequence: 0000
R3(PKTS:1 of 10)#show 5
=============================================================================
04:49:36.715 CET Sun Jul 19
2015 Relative Time:
7.163999
Packet 5 of 10 In:
Ethernet0/1
Ethernet Packet: 1514 bytes
Dest Addr: AABB.CC00.0310, Source Addr: AABB.CC00.0210
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x5,
TOS: 0x00
Length: 1500, ID: 0x0015,
Flags-Offset: 0x2000 (more fragments)
TTL: 254, Protocol: 1 (ICMP), Checksum: 0x0FB5 (OK)
Source: 192.168.2.1, Dest: 192.168.4.5
ICMP Type: 8,
Code: 0 (Echo Request)
Checksum: 0x27FC ERROR: C6D9
Identifier: 0005, Sequence: 0000
Echo Data:
R3(PKTS:5 of 10)#show 6
=============================================================================
04:49:36.715 CET Sun Jul 19
2015 Relative Time:
7.163999
Packet 6 of 10 In:
Ethernet0/1
Ethernet Packet: 534 bytes
Dest Addr: AABB.CC00.0310, Source Addr: AABB.CC00.0210
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x5,
TOS: 0x00
Length: 520, ID:
0x0015, Flags-Offset: 0x00B9
TTL: 254, Protocol: 1 (ICMP), Checksum: 0x32D0 (OK)
Source:
192.168.2.1, Dest: 192.168.4.5
IPV6
FRAGMENTATION
Los routers IPv6 no hacen fragmentación.
Los nodos IPv6 requieren ya sea hacer descubrimiento
de MTU, realizar fragmentación extremo a extremo o enviar paquetes menores
al MTU mínimo de IPv6 de 1280 bytes
Pegado de <https://es.wikipedia.org/wiki/IPv6>
Path MTU Discovery (PMTUD) is a standardized technique
in computer networking for determining the maximum transmission unit (MTU) size on the network path between two
Internet Protocol (IP) hosts, usually with the goal of avoiding IP fragmentation. PMTUD was originally intended for routers
in Internet Protocol Version 4 (IPv4).[1] However, all modern operating systems use it
on endpoints. In IPv6, this function has been explicitly delegated
to the end points of a communications session.[2]
For IPv4 packets, Path MTU
Discovery works by setting the Don't Fragment (DF) option bit in the IP
headers of outgoing packets. Then, any device along the path whose MTU is
smaller than the packet will drop it, and send back an Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3,
Code 4) message containing its MTU, allowing the source host to reduce its Path
MTU appropriately. The process is repeated until the MTU is small enough to
traverse the entire path without fragmentation.
Pegado de <https://en.wikipedia.org/wiki/Path_MTU_Discovery>
PC1#ping P5 size 1500 repeat 1
Type escape sequence to
abort.
Sending 1, 1500-byte ICMP
Echos to 2001:4:5:0:A8BB:CCFF:FE00:510, timeout is 2 seconds:
!
Success rate is 100 percent
(1/1), round-trip min/avg/max = 0/0/0 ms
PC1#ping P5 size 4500 repeat 1
Type escape sequence to
abort.
Sending 1, 4500-byte ICMP
Echos to 2001:4:5:0:A8BB:CCFF:FE00:510, timeout is 2 seconds:
!
Success rate is 100 percent
(1/1), round-trip min/avg/max = 0/0/0 ms
R3(PKTS:2 of 7)#show all
# TD interface summary relative time
length
1 I Et0/1 IPv6 ICMPv6 (Echo Request) 2.499999 1514
2 I Et0/1 IPv6 (Frag) 3.703999 1510
3 I Et0/1 IPv6 (Frag) 3.707999 1510
4 I Et0/1 IPv6 (Frag) 3.707999 1510
5 I Et0/1 IPv6 (Frag) 3.707999 178
6 I Et0/1 IP OSPF (Hello) 5.283999 94
7 I Et0/1 IPv6 OSPF (Hello) 7.035999 94
R3(PKTS:2 of 7)#
R3(PKTS:2 of 7)# show 1
=============================================================================
18:32:55.171 CET Sun Jul 19
2015 Relative Time:
2.499999
Packet 1 of 7 In: Ethernet0/1
Ethernet Packet: 1514 bytes
Dest Addr: AABB.CC00.0310, Source Addr: AABB.CC00.0210
Protocol: 0x86DD
IPV6 Version: 0x6,
Traffic_Class: 0x0,
Flow_Label: 0x000000, Payload_Length: 1460
Next_Header: 58, Hop_Limit: 63
Source: 2001:1::A8BB:CCFF:FE00:100
Dest: 2001:4:5::A8BB:CCFF:FE00:510
ICMPv6 Type: 128, Code: 0
(Echo Request)
Checksum: 0xC1E6 (OK)
Identifier: 1E56, Sequence: 0000
Echo Data:
R3(PKTS:1 of 7)# show 2
=============================================================================
18:32:56.375 CET Sun Jul 19
2015 Relative Time:
3.703999
Packet 2 of 7 In:
Ethernet0/1
Ethernet Packet: 1510 bytes
Dest Addr: AABB.CC00.0310, Source Addr: AABB.CC00.0210
Protocol: 0x86DD
IPV6 Version: 0x6,
Traffic_Class: 0x0,
Flow_Label: 0x000000, Payload_Length: 1456
Next_Header: 44, Hop_Limit: 63
Source: 2001:1::A8BB:CCFF:FE00:100
Dest: 2001:4:5::A8BB:CCFF:FE00:510
IPv6 Option: 44 (Fragmentation Option)
Next Header: 58, Frag Offset: 0 (0 bytes), Mflag: 1 (More)
Identification: 10
ICMPv6 Type: 128, Code: 0
(Echo Request)
Checksum: 0xBC3F ERROR: E175
Identifier: 247B, Sequence: 0000
Echo Data:
R3(PKTS:2 of 7)# show 3
=============================================================================
18:32:56.379 CET Sun Jul 19
2015 Relative Time:
3.707999
Packet 3 of 7 In:
Ethernet0/1
Ethernet Packet: 1510 bytes
Dest Addr: AABB.CC00.0310, Source Addr: AABB.CC00.0210
Protocol: 0x86DD
IPV6 Version: 0x6,
Traffic_Class: 0x0,
Flow_Label: 0x000000, Payload_Length: 1456
Next_Header: 44, Hop_Limit: 63
Source: 2001:1::A8BB:CCFF:FE00:100
Dest: 2001:4:5::A8BB:CCFF:FE00:510
IPv6 Option: 44 (Fragmentation Option)
Next Header: 58, Frag Offset: 181 (1448 bytes), Mflag: 1
(More)
Identification: 10
IPv4 and IPv6 PMTU
IPv6 MTU Path Discovery
As in IPv4, path MTU
discovery in IPv6 allows a host to dynamically discover and adjust to
differences in the MTU size of every link along a given data path. In IPv6,
however, fragmentation is handled by the source of a packet when the path MTU
of one link along a given data path is not large enough to accommodate the size
of the packets. Having IPv6 hosts handle packet fragmentation saves IPv6 device
processing resources and helps IPv6 networks run more efficiently.
|
Note
|
In IPv6, the minimum link MTU is 1280 octets. We recommend using an MTU value of 1500 octets for IPv6 links. |
With IPv6 path MTU
discovery, a device originating IPv6 traffic has an MTU cache that contains MTU
values received in ICMPv6 "toobig" messages. In order to prevent an
attacker from filling the MTU cache, the device keeps track of the destinations
to which it has originated (sent) traffic, and only accepts toobig ICMPv6
messages that have an inner destination matching one of these tracked
destinations.
If a malicious device can
learn to which destination the device is originating traffic, it could still
send a toobig ICMPv6 message to the device for this destination, even if the
attacker is not on the path to this destination, and succeeds in forcing his
entry into the MTU cache. The device then starts fragmenting traffic to this
destination, which significantly affects device performance.
Enabling flow-label marking
for locally generated traffic can mitigate this attack. Originated packets are
marked with a flow label (which is randomly generated and changed every
minute), and toobig messages received are checked against the values sent.
Unless an attacker can snoop traffic, the attacker will not know which flow
label to use, and its toobig message will be dropped.
How to Configure IPv6 MTU Path Discovery
Enabling
Flow-Label Marking in Packets that Originate from the Device
This feature allows the
device to track destinations to which the device has sent packets that are 1280
bytes or larger.
SUMMARY STEPS
1. enable
2. configure terminal
3. ipv6 flowset
4. exit
5. clear ipv6 mtu
Explain TCP and UDP operations
The TCP and UDP are the
most major protocols which are operating at the transport layer. Both the
protocols will operate in a different manner and it will be selected based on
the requirements only. TCP stands for the transmission control protocol, which
guarantees the data packet delivery. And UDP stands for the User datagram
protocol which operates in the datagram mode. TCP is the connections oriented
protocol, whereas the UDP is the connection less protocol. Here, you can learn
the TCP and UDP operations in the following sections:
1.4 Explain TCP operations
The TCP is referred as the
reliable protocol, which is responsible for breaking up the messages into the
TCP segments as well as resembling it in a receiving side. The major purpose of
the TCP is to give the reliable and secure logical connection, service or
circuit between the pairs of the processes. To offer this type of service on
top of the less reliable internet communication system needs facilities in
areas such as security, precedence, multiplexing, reliability, connections and
basic data transfer. The main purpose of the TCP is flow control and error
recovery. As it is connection based protocol, which means that before allowing
any data it accomplishes connections and also terminates it upon completion.
During the connection,
accomplishment both server and client agree upon the sequence and also
acknowledge numbers. The implicit client notifies the server of its source
ports. The sequence is the characteristic of the TCP data segment. This
sequence begins with the random number and each time the new packet is sent,
then the sequence is incremented by a number of bytes sent in the previous
segment of the TCP. Acknowledge segment is moreover the same, but from a
receiver side. This does not comprise data and are equal to the sender's
sequence numbers increased by the number of the received bytes. The ACK segment
acknowledges that the host has got the sent data.
TCP is the connection
oriented protocol, that means the devices must open the connection before
transferring data and must lose a connection gracefully after transferring the
data. It also assures the reliable data delivery to the destinations. This
protocol offers the extensive error checking mechanisms, including the
acknowledge of data and flow control as mentioned above. The TCP is relatively
slow because of the extensive error checking mechanisms only. Demultiplexing as
well as multiplexing is greatly possible in the TCP by means of the TCP port
numbers and also retransmission of the lost packets is merely possible in the
TCP.
1.4 a Ipv4 and Ipv6 (P) MTU
The larger Maximum
transmission unit - MTU will bring greater efficiency. This MTU is the needed
concept in the packet switching systems. The Path MTU equals to the smallest
link MTU on the path from the source to destination. Let us come to the Path
MTU that relies on the TCP to probe an internet path with the progressively
larger packets. It is the most efficient one when used in the conjunction with
an ICMP based path MTU mechanism as indicated in the RFC 1191 and RFC 1981, but
it resolves many robustness problems of the techniques which are classic, since
it will never depend on the ICMP message delivery.
The internet protocol
version 6 is also known as the IP next generation. It was specially proposed by
the IETTF as the successor to the internet protocol version 4. The most
significant difference between version 4 and 6 is the version 6 increases an IP
address size from the 32 bits - 128 bits.
The links that the packet
passes through the source to the destination has a variety of different MTU. In
the IPv6, when the packet size exceeds the MTU link, then the packet can be
fragmented at a source so as to deduce the forwarding device processing
pressure and also utilize the network resource rationally. The PMTU mechanism
is to identify the minimum MTU on the source to destination path.
1.4.bMMS
The MSS is defined as the
maximum segment size. It is the parameter of the TCP protocol which specifies
the largest data amount. The default TCP MSS is 536. Each of the TCP device has
associated with it the ceiling on TCP size. The segment size that does not
exceed regardless of how large the current window was. This is called as the
maximum segment size. To decide how much data to put into the segment, every
device in the TCP connections will choose the quantity based on the current
size of the window, in conjunction with a various algorithm, but it does not as
so large that the quantity of data exceeds the maximum segment size of the
device to which it was sent.
It is the largest quantity
of data that a communication or computer device can handle in the single,
unfragmented piece. For the optimum communications, then the number of bytes in
a data segment as well as the header must include less than the number of the
bytes in an MTU. This MSS is the most essential consideration in the internet
connections, especially in web browsing.
When an internet TCP is used to gain
the internet connection, then the computers which are connected must agree on
and set, the maximum transmission unit size acceptable to both. The typical MTU
size in the TCP for the home computer, internet connections are either 1500 or
576 bytes. The headers are mostly 40 bytes long and the MSS is equal to a
difference, either 1460 or 536 bytes. In some cases, the MTU size is less than
the 576 bytes and data segments has smaller than the 536 bytes. As the data is
routed over the internet, it has to pass via multiple gateway routers.
Most
ideally, each data segment may pass via each router without getting fragmented.
Suppose, the data segment size is relatively too large for any routers via
which the data passes, then the oversize segment are fragmented. It will slow
down the speed of the connection as viewed by the computer operator. In some
instance this slowdown is really dramatic. The likelihood of the such kind of
fragmentation may be minimized by maintaining the MSS as small as much as
possible. For most of the computer operators, the MSS will set automatically by
an operating system.
1.4.c Latency
The speed of the each data
transfer like the TCP is about the use largely determined by a line speed. The
delay is considered as round trip time- RTT of the each data packet. Regardless
of the speed of a processor or software efficiency, it takes the finite amount
of the time to manipulate and also present the data. Whether an application is
the web page showing the live camera or latest news shot showing the traffic
jam, there are so many methods in which the application can be affected by the
latency. There are 4 key causes of the latency are: data protocols, propagation
delay, serialization, switching a routing, buffing and queuing. Any time the
client computer asks the server a, there is an RTT delay until that receives
the response. The data packet has to travel through the number of high traffic
router and also there was always a speed of light as the limitation,
considering a huge distance of the internet communication.
1.4.d Windowing
The throughput of the
communication is limited by the 2 windows such as congestion window and receive
window. Each of the TCP segments comprises the current value of a receive
window. The TCP windowing concept is mainly used to avoid the congestion in the
traffic. It also controls the quantity of the unacknowledged data that a sender
may send before it get an acknowledgement back from a receiver which it has received
it.
1.4.e Bandwidth-delay product
The Bandwidth delay product
- BDP determines the quantity of the data which can be transmitted in a
network. It is the most important concept in the window based protocol like
TCP, as the throughput is bound by a BDP. The TCP receive window and BDP limit
the connection to the products of the latency as well as the bandwidth. The
transmission will not exceed a RWIN/ latency value. The amount of the data to
send prior that should reasonably expect an acknowledgement.
1.4.f Global
synchronization
The TCP global
synchronization in the computer networks will happen to the TCP flows during
the period of congestions because every sender will deduce their transmission
rates at a same time when packet loss occur. All the TCP streams will behave in
the same way, so it will become as synchronized eventually, increasing to cause
the congestion as well as backing off at the roughly same rates. It causes the
most familiar bandwidth utilization graphs called the saw tooth. The WRED and
RED will assist to alleviate it.
1.5 Describe UDP operations
The user datagram protocol
- UDP is the datagram oriented protocol without overhead for opening the
connection with the help of 3 way handshake, closing the connection and
maintaining the connection. This UDP is very efficient for the multicast or
broadcast type of the network transmission. It has only the error checking
mechanism with the help of checksums. There are no sequencing of the data in
the UDP and the delivery of the data cannot be guaranteed in that. It is
simpler, more efficient and faster than the TCP. Although, UDP is less robust
than the TCP. Here demultiplexing and multiplexing are possible in the UDP by
means of the UDP port numbers. Additionally, there is no transmission of the
lost packets in the UDP.
As it is a connectionless
protocol, it is not at all reliable protocols when compared to the TCP. It is
capable to perform the fundamental error checking too. It will never offer any
sequencing of the data. Hence, the data will arrive at the destination device
in the various orders from which it is sent. This will occur in the large
networks like the internet, where datagrams takes various paths to a
destination and also experience the delay in the different router. The UDP is
generally the IP with the transport layer port addressing. Sometimes this UDP
is also known as the wrapper protocol.
The last 16 digits are
reserved for a checksum value in the UDP header. This checksum is used as the
error detection tool. The checksum field also includes the 12 bytes pseudo
header which includes the destination and source IP addresses. This pseudo
header is the most useful one to check the IP datagram arrived at the station.
1.5.a Starvation
The TCP starvation or UDP
dominance is experienced at the congestions time where the TCP and UDP streams
are assigned to a same class. Because the UDP has no flow control which cause
it to back off while congestion taking place, but TCP does, this TCP ends up
backing off and also allowing even many bandwidth to the UDP streams to a point
where the UDP takes it over completely. It is not assisted by WRED as drops
caused by the WRED will not affect the UDP streams. The best possible way to
resolve the issue is to classify the TCP and UDP streams separately in the
possible way.
1.5.b Latency
The latency is the end to
end delay. As mentioned above, the UDP is connectionless, the real effect of
the latency on the UDP stream is that there would be a great delay in between
the sender and the receiver. The jitter is the variance in the latency. It
causes problems with the UDP stream. The Jiffer can be smoothed by buffering.
From the above session, it
is possible to learn the TCP and UDP operations in details. In that it is
essential to learn more about the difference between those 2 operations too.
The connection and connectionless protocols are used in a variety of things
depends upon the usage and requirements of the things. This thorough
explanation will help to understand the operations as well MSS, latency, global
synchronization, bandwidth-delay product, windowing, and IPv4 and IPv6 P MTU
under TCP and latency and starvation under the UDP operations.
Pegado de <http://www.examcollection.com/certification-training/ccnp-explain-tcp-and-udp-operations.html>
Recognize the proposed changes to the network
It is essential to recognize
the changes to a network to operate the network without any issues. By learning
the changes and impact or effect of the existing network infrastructure, one
can able to perform the tasks in a better way. In the following sections, let
us see the about the changes to routing he protocol parameters, migrate parts
of the network to IPv6 and routing protocol migration.
1.6.a Changes to routing Protocol parameters
The routing protocol helps
to specify how routers communicate with the each other which enables to select
routes between any 2 nodes on the computer network. The routing protocol will
share the information among the immediate neighbors at first and throughout the
network. In this way, the routers gain the knowledge of the network topology.
The routing protocols can be classified mainly into 3 different groups such as
behavior, operation and purpose.
The changes include things
such as metrics, redistribution, additional routes. The right selection of the
routing protocol for the network is mostly sensitive tasks and difficult to
understand in some cases. It is essential to consider many factors, ranging
from the speed of convergence and protocol scalability via the advanced feature,
ends with the compatibility problem, particularly in the multi vendor
environment, all are related to the network requirement and design only. As the
networks evolved, it may become need to reevaluate a choice of the particular
routing protocol. If it is defined as inappropriate, then it required to be
replaced.
The migration from the 1
routing protocol to the other is mostly the disruptive change to a network. It
needs the careful planning to reduce the outages as well as even, it was
inevitable, however its duration can be maintained very low. Hence, the routing
protocol migration always needs the maintenance window.
The point to point protocol
is the form of serial line data encapsulation. It can negotiate the connection
parameters like speed along with an ability to support the CHAp and PAP use
authentication.
The routing protocols are
most often used in the implementation of the routing algorithms to offer the
facility to exchange the routing information in between the networks, which
allows the routers to build the routing table dynamically. In some instances,
the routing protocols will run over routed protocols themselves. If the BGP run
over the TCP then take is important in the implementation of that system for
not to create the circular dependency between the routed protocols and routing
protocols.
The routing metric is one
of the parameters which consist of the value used by the algorithms to examine
to choose one route over the other. The metrics take into consideration such
information like delay, bandwidth, load, MTU, cost, reliability, MTU, and hop
count. A routing table stores, the best routes which is possible, when the
topological databases or link state may store all the other information well.
The border gateway protocol
routes traffic in between the autonomous systems. It is the very scalable and
robust routing protocol. To gain the scalability, the BGP uses the many routes
parameters such as attributes which helps to define the routing policies as
well as keep the routing environment.
1.6.b Migrate Parts of the Networks to Ipv6
IPv6 is the next generation
protocol, which is the only internet protocol in use. Even though IPv6 is not
al compatible with the IPv4, to ensure the business continuity and growth, all
the organizations require to carefully plan for the coexistence between the
IPv4 as well as IPv6. There plenty small business that runs with the IPV6
phase.
There are so many factors
involved in the migrate parts of the networks to IPv6. As the technology moves
forward with the recent technology with the new standard, the migration to IPv6
is an important one in the day to day tasks. For the most part, the migration
to the IPv6 will take associated planning and time to assure the integrity of
the existing networks. It will need to upgrade or replace the older equipment
such as routers, switches, firewalls, endpoint devices and also other security
elements.
This migration mainly
involves looking at the IPv6 transition mechanism such as toredo, Dual stack,
ISATAP, 6 to 4 tunnels and much more. It also includes the I,pact on the
existing interoperability, services and etc.
In that the Teredo is the
mechanism in the windows systems which is used to provide the single system
behind the IPv4 Nat access to the IPv6. Like version 6 to 4, it uses the public
relays. The teredo combines it with the setup protocol with the help of teredo
servers to detect and break via the IPv4 NAT. This is not all reliable but the
teredo is used when the explicitly connected to the IPv6 address and not while
connecting to the hostname and also looking for the DNS addresses. It happens
while using the BitTorrent and the lesser reliability is not a big matter.
The IPv6 transition
mechanism is the technology which facilitates transitioning of the internet
from the current or initial infrastructure to a successor addressing and the
routing system of the IPv6. The IPv6 is not able to interoperable directly,
this technology is designed to permit the hosts on either the network to allow
the networking with the other networks. The tunnel broker combines the several
IPv6 mechanisms of migration and also enables the users to use it. This
transition is provided by the tunnel broker is the IPv6 in IPv4 tunneling, with
the help of the 6in4, AYIYA or TSp tunnels.
1.6.c Routing protocol migration
The routing protocol is the
protocol used by the router to identify the appropriate path over which data is
transmitted. It also specifies how the routers in the network share the
information with one another and report changes. This protocol enables the
network to make the dynamic adjustment to its condition. Hence the routing
decisions cannot be predetermined and static.
Each routing protocol is assigned
a default AD- administrative distance. This term is something of the misnomer
and instead of effecting any of the metric calculations within the protocol,
the AD is simply the way to prefer 1 routing protocol over the other. If the
router has learned of the route through both EIGRP and OSPF. In certain case,
it will prefer a route learned through the EIGRP regardless of the metric
because the EIGRP has the lowest default administrative distance.
The defaults
can also be modified by the any number lies in between 1 to 255. It can
especially handy while migrating from the 1 routing protocol to the other.
Suppose, migrating a network from the Is IS to the OSPF. As default, the
routers will start to follow the OSPF routes as soon it is done within the single
maintenance window to omit the disruption, which is really tough in pratical,
especially on the larger networks.
The routing protocol
migration will always need the maintenance window. This routing migration is
generally established in the below steps:
·
Plan the strategy for
migration
·
Activate
a new routing protocol on the entire router in a topology, raising the AD above
the AD of a current IGP. If a new IGP is the EIGRP or RIP, the redistributions
from a current into a new IGP needs to be configured on every router also. A current IGP is the left intact.
·
Verify
a new IGP adjacencies and an optional working database content.
·
Deactivate
a current IGP in the gradual fashion.
·
Remove
all the temporary settings from a new IGP
In the above, planning the
migration strategy is more important than anything. The deployment of the new
routing protocol must pre planned for all the network, such as split of the
network as areas if the link state IGP has to be used, filtration or prefix
summarization, external information redistribution and stub features and much
more. This type of planning must involve the right order in which the routers
will be migrated through from a current IGP to a new one. In the ideal, the
router has to be migrated so that it forms the contiguous and ever growing part
of a network running a new IGP, then shrinking the contiguous remainders of a
network in which both the new and current IGP are run gradually. If a current
IGP is the link state protocol, then it is advisable to do the migration in the
per area fashion. A backbone routers must be the last one to migrate.
The routing protocol
migration includes the manipulating metrics, administrative distances and
redistribution and much. In order to migrate, it is essential to determine the
EIGRP or IGRP network design and scope of OSPF areas, according to the number
of the EIGRP or IGRP routers. According to planning the migration, the new IGP
must be activated on a router in a network, the first setting its AD to higher
value than a current Ad of IGP, and only adding the networking and interfaces
to a new IGP and also activating the selected features. A current IGP is kept
running and the configuration remains constant throughout the entire steps.
If
a current IGP uses the different administrative distance for the various
network types, a new administrative distance of IGP has to be reconfigured as
higher that of the AD which is used by an existing IGP. The new IGP can also be
deployed over a network, making adjacencies between the routers as normal, but
it will never influence the routing and routing table simply yet. If a new IGP
is the distance vector type routing protocol, then every router must be
configured with the redistribution from a current IGP into a new IGP. After a new
IGP configuration over all the networks, it must create adjacencies in usual
fashion despites a routing table is not populated by the routes yet. Those
adjacencies must be verified to ensure the completeness. After IGP is
deactivated, the adjacency is the only routing protocol adjacency kept left in
between the migrated routers. It has to work as expected before a current IGP
begins being removed. It is recommended to check the working database content
in a new IGP to analyze whether all the expected networks are there or not. As
the result, if a new IGP is EIGRP or RIP, then the working database can contain
partial content only until the migration begins inducing the verification
before the migration impossible. After this stage, the routing protocol migration
will involve removing or deactivate the current IGP from the contiguous set of
the routers. Then finally, remove all the temporary settings from a new IGP.
With migration by means of
redistribution, then the migration is staged as the series of smaller steps. In
the every step, the part of the network will convert from the old to a new
routing protocol. In the huge networks, the approach with AD might use to
support that type of conversion. In the smaller network, the simpler approach
or an overnight cutover is sufficient. To offer the full connectivity at the
time of migration by redistribution, then a boundary routers in between the 2
parts of a network has to redistribute bidirectionally between the protocols.
The filtering through the tags is one among the simple method to manage this
when compared to others. A boundary routers will move as more as possible about
the region is migrated.
The network has become the
critical resource and the organizations requires strategies to strengthen the
continuity as well as to improve the network. It includes the capability to
predict, avoid as well as lessen the costly network effects and service
disruption and provides the confidence to adapt the networking to face the
changes. It is very, very essential to recognize the proposed changes to the
network. It has been carried out different techniques such as routing protocol
migration, migrate parts of the network of internet protocol version -6 and
changes to the routing protocol parameters. This technique will help a lot to
diagnose the effect and also gives effective knowledge to avoid the problems.
This will make the greatest impact on the network as well.
Pegado de <http://www.examcollection.com/certification-training/ccnp-recognize-proposed-changes-to-the-network.html>
Network troubleshooting
Use IOS troubleshooting
tools
Cisco is more than just a
hardware company. Cisco IOS provides you with powerful diagnostic programs such
as show, ping, trace, log, and debug commands. Mastering them is
important because some of these can be simple tools that can still save you a
great deal of time.
Table 2-1 and the following
sections review some basic IOS troubleshooting tools. The objectives here are
to review the output and summarize the importance of the commands so that you
can put them to practical use. Many times it is advantageous if you can
physically inspect the hardware, such as the equipment, cables, and connectors;
but maybe you can't. Lots of times you are remote to the problem, depending on
your scenario, so it is critical to know the tools innate to the IOS to assist
you.
NOTE
Review Chapter 1,
"Shooting Trouble," to make sure you have an understanding of
protocol technical characteristics and a systematic method for troubleshooting.
Table 2-1. IOS
Troubleshooting Tools
|
Cisco Command
|
Description
|
|
show
|
A snapshot of what is
occurring to monitor status. The show commands enable you to detect
neighbors, spot performance issues, and isolate problems.
|
|
ping
|
Determine end-to-end
connectivity and reachability.
|
|
traceroute
|
Hop-by-hop approach to
finding the problem.
|
|
log
|
Monitor and view messages
that record real-time events, such as errors, warnings, and state
transitions.
|
|
debug
|
Use for troubleshooting
traffic flow or misconfigurations; not for normal daily operations.
|
Extended Ping Options
|
Field
|
Description
|
|
Protocol[IP]:
|
Default is IP.
|
|
Target IP address:
|
Destination host name or
IP address.
|
|
Repeat count[5]:
|
Number of ping packets.
Default is 5 ping packets.
|
|
Datagram size [100]:
|
Size of ping packets.
Default size of the ping packet is 100 bytes.
|
|
Timeout in seconds[2]:
|
Default timeout interval
is 2 seconds.
|
|
Extended commands[n]:
|
Default is no extended
commands, but you can type Y to indicate you want a series of
additional commands to appear. Some of these
commands follow.
|
|
Source address or interface:
|
Set the source address in
the ping packet.
|
|
Type of service [0]:
|
TOS selection. Default is 0.
|
|
Set DF bit in IP header? [no]:
|
Don't fragment. Drop and
send error message instead. Helps determine the smallest MTU in the path. Default is no.
|
|
Validate reply data? [no]:
|
Specify whether to
validate the reply data. Default is no.
|
|
Data pattern [0xABCD]:
|
Default is ABCD, but
varying to all 1s or 0s can be helpful when debugging channel service
units/data service units (CSUs/DSUs) or detecting cable problems such as
crosstalk.
|
|
Loose, Strict, Record,
Timestamp, Verbose[none]:
|
The default is none.
Other header options include the following:
Loose— List of nodes that must be traversed
Strict— List of nodes that must be the only nodes
traversed
Record— Path
Timestamp— Times
Verbose— Detailed information
|
|
Sweep range of sizes[n]:
|
Vary the size of the echo
packets being sent. Useful to determine the minimum MTUs configured from the
source to destination. Reduce performance
problems related to fragmentation.
|
|
!!!!!
|
Each bang (!) indicates
the receipt of a reply, whereas a period (.) indicates a timeout while
waiting for a reply.
|
|
Success rate is 100 percent
|
100 percent or 5/5 is
obviously what you want to see, not the 0/5, which most definitely indicates
a problem at L3 or below. If the success rate is less than 100 percent,
remember to ping again for best results. When the success rate is 4/5 (or 80
percent) in a Cisco environment, I normally just write it off to ARP
performing its duties.
|
|
Round-trip min/avg/max =
1/2/4 ms
|
Round-trip minimum/average/maximum
milliseconds for the reply packet.
|
Type ping and press Enter
to specify the extended protocol options in Example 2-24.
Example 2-24. Cisco
Extended Ping
r2#ping
Protocol [ip]:
Target IP address: 192.168.4.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.3.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
r2#
Protocol [ip]:
Target IP address: 192.168.4.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.3.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
r2#
Table 2-5. traceroute Characters
|
Output
|
Description
|
|
nn msec
|
Round-trip time per probe
in milliseconds.
|
|
*
|
The probe timed out.
|
|
?
|
Unknown packet type.
|
|
A
|
Administratively
unreachable; check for access list issues.
|
|
H
|
Host unreachable.
|
|
N
|
Network unreachable.
|
|
P
|
Protocol unreachable.
|
|
Q
|
Source quench.
|
|
U
|
Port unreachable. Probe
received but discarded because it could not deliver to the application.
|
Now that I have introduced
a few tools, I want you to refer back to the practical examples provided thus
far, if necessary, to help troubleshoot a particular problem in Example 2-25.
The chapter scenario is pictured in Figure 2-2 for your convenience. I am on r2 trying to
ping the far side of r1. This worked in my earlier test when I added RIP, but I
can't ping now.
Example 2-25. Trace
Troubleshooting
r2>ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
r2>trace 192.168.1.1
Type escape sequence to abort.
Tracing the route to 192.168.1.1
1 * * *
2 * * *
3 * *
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
r2>trace 192.168.1.1
Type escape sequence to abort.
Tracing the route to 192.168.1.1
1 * * *
2 * * *
3 * *
Apply troubleshooting methodologies
Troubleshooting
Methodologies
Troubleshooting is not an
exact science, and a particular problem can be diagnosed and sometimes even
solved in many different ways. However, when you perform structured
troubleshooting, you make continuous progress, and usually solve the problems
faster than it would take using an ad hoc approach. There are many different
structured troubleshooting approaches. For some problems, one method might work
better, whereas for others, another method might be more suitable. Therefore,
it is beneficial for the troubleshooter to be familiar with a variety of
structured approaches and select the best method or combination of methods to
solve a particular problem.
Troubleshooting Principles
Troubleshooting is the
process that leads to the diagnosis and, if possible, resolution of a problem.
Troubleshooting is usually triggered when a person reports a problem. Some
people say that a problem does not exist until it is noticed, perceived as a
problem, and reported as a problem. This implies that you need to differentiate
between a problem, as experienced by the user, and the actual cause of that
problem. The time a problem is reported is not necessarily the same time at
which the event causing the problem happened. Also, the reporting user
generally equates the problem to the symptoms, whereas the troubleshooter often
equates the problem to the root cause. For example, if the Internet connection
fails on Saturday in a small company, it is usually not a problem, but you can
be sure that it will turn into a problem on Monday morning if it is not fixed
before then. Although this distinction between symptoms and cause of a problem
might seem philosophical, you need to be aware of the potential communication
issues that might arise from it.
Generally, reporting of a
problem triggers the troubleshooting process. Troubleshooting starts by
defining the problem. The second step is diagnosing the problem during which
information is gathered, the problem definition is refined, and possible causes
for the problem are proposed. Eventually this process should lead to a
hypothesis for the root cause of the problem. At this time, possible solutions
need to be proposed and evaluated. Next, the best solution is selected and
implemented. Figure 2-1 illustrates the main elements of a
structured troubleshooting approach and the transition possibilities from one
step to the next.
Diagnosis is the process of
identifying the nature and cause of a problem. The main elements of
this process are as follows:
·
Gathering
information:
Gathering information happens after the problem has been reported by the user
(or anyone). This might include interviewing all parties (user) involved, plus
any other means to gather relevant information. Usually, the problem report
does not contain enough information to formulate a good hypothesis without
first gathering more information. Information and symptoms can be gathered
directly, by observing processes, or indirectly, by executing tests.
·
Analyzing
information:
After the gathered information has been analyzed, the troubleshooter compares
the symptoms against his knowledge of the system, processes, and baselines to
separate normal behavior from abnormal behavior.
·
Eliminating
possible causes:
By comparing the observed behavior against expected behavior, some of the
possible problems causes are eliminated.
·
Formulating
a hypothesis:
After gathering and analyzing information and eliminating the possible causes,
one or more potential problem causes remain. The probability of each of these
causes will have to be assessed and the most likely cause proposed as the
hypothetical cause of the problem.
·
Testing
the hypothesis:
The hypothesis must be tested to confirm or deny that it is the actual cause of
the problem. The simplest way to do this is by proposing a solution based on
this hypothesis, implementing that solution, and verifying whether this solved
the problem. If this method is impossible or disruptive, the hypothesis can be
strengthened or invalidated by gathering and analyzing more information.
Cisco IOS embedded Packet Capture
Product Architecture
The Cisco IOS Embedded Packet Capture is a
software feature consisting of infrastructure to allow for packet data to be
captured at various points in the packet-processing path. The network administrator
may define the capture buffer size and type (circular, or linear) and the
maximum number of bytes of each packet to capture. The packet capture rate can
be throttled using further administrative controls. For example, options allow
for filtering the packets to be captured using an Access Control List (ACL)
and, optionally, further defined by specifying a maximum packet capture rate or
by specifying a sampling interval.
CLI commands are available for controlling
the packet capture buffer (defining, clearing, destroying, and displaying).
EXEC-level commands initiate and terminate captures at defined capture points.
The feature currently allows for capture
points at the ingress and egress interfaces for Cisco Express Forwarding path
and the process-switching path. Both IPv4 and IPv6
packets may be captured.
Packet data may be displayed in hex and ASCII
on the CLI, or may be exported using typical file transfer methods such as a
PCAP-formatted file that may be further analyzed using the open-source tool
Wireshark.
Figure 1. Embedded Packet Capture
Cisco IOS Embedded Packet Capture extends the
embedded management capabilities of Cisco IOS and provides another powerful
tool to help resolve application and network problems. It can be particularly
useful in situations where it is not practical or desirable to tap into the
network using a stand-alone packet-sniffing tool, or when the need arises to
remotely debug or troubleshoot issues.
Feature
Specifications
Please use the Cisco IOS Feature Navigator
application on Cisco.com to check the latest information on software and
product availability. Go to http://cisco.com/go/fn.
The following table includes the EPC feature
availability information.
Table 1. Feature Specifications
|
Feature
|
Description
|
|
Product
Compatibility
|
EPC is available for the Cisco Integrated Services Routers, and the
Cisco 7200 Series Routers
|
|
Software
Compatibility
|
EPC is available in Cisco IOS Software Release 12.4(20)T and future
versions
|
|
Software Packaging
|
Please refer to the Cisco IOS Feature Navigator for the latest
packaging information
|
System
Requirements
The EPC software subsystem will consume CPU
and memory resources in its operation. Customers should examine the operation
in their environment to ensure resources exist for their specific scenarios. Some basic guidelines are included in Table 2.
Table 2. System Requirements
|
Feature
|
Description
|
|
Hardware
|
CPU utilization requirements are platform dependent
|
|
Memory
|
The packet buffer is stored in DRAM; The size of the packet buffer is
user specified
|
|
Disk Space
|
Packets can be exported to external systems; No intermediate storage
on flash disk is required
|
Commands EPC
1-Definimos el tamaño del archivo en el cual vamos
a guardar la captura:
R1#monitor capture
buffer buffer-test size 100
2-Definimos la interface que queremos analizar, en
esta caso especifico todas
R1#monitor capture point
ip cef capture-test all both
3-Asociamos el buffer creado en el paso 1 con la
interface que utilizaremos:
R1#monitor capture point
associate capture-test buffer-test
4-Iniciamos la captura.
R1#monitor capture point
start capture-test
5-validamos EPC que esté funcionando capturando el
trafico llega a la interface.
6-Detener la captura.
R1#monitor capture point
stop capture-test
7-El feature nos permiderevisar la captura desde el
router donde realizamos la recopilación de información:
R1#show monitor capture
buffer buffer-test
8-Exportamos el archivo para analizarlo usando
Wireshark
R1#monitor capture
buffer-test export tftp://IP/Path/
