Sunteți pe pagina 1din 100

CCIE R&S v5 Advanced Technology Labs LAN Switching

Layer 2 Access Switchports : OK

Layer 2 Dynamic Switchports: OK


DTP Negotiation: OK
On: Puts the port into permanent trunking mode and negotiates to convert the link into a trunk
link. The port becomes a trunk port even if the neighboring port does not agree to the change.
Desirable: Actively attempt to form a trunk, subject to neighbor agreement. The port becomes a
trunk port if the neighboring port is set to on, desirable, or auto mode.
Auto: Makes the port willing to convert the link to a trunk link. The port becomes a trunk port if
the neighboring port is set to on or desirable mode. This is the default mode.
Off. (Is access mode in Cisco IOS software.) Never become a trunk, even if the neighbor tries.
Puts the LAN port into permanent nontrunking mode and negotiates to convert the link into a
nontrunking link.
Nonnegotiate: Puts the port into permanent trunking mode but prevents the port from generating
DTP frames. You must configure the neighboring port manually as a trunk port to establish a
trunk link. With Cisco devices, there are three Ethernet trunk encapsulation types:
ISL: Uses ISL encapsulation on the trunk link.
Dot1q: Uses 802.1Q encapsulation on the trunk link.

Negotiate: Specifies that the LAN port negotiate with the neighboring LAN port to become an ISL
(preferred) or 802.1Q trunk, depending on the configuration and capabilities of the neighboring
LAN port.

** DTP Negotiated Interface Modes


Auto

Desirable

Trunk

Access

Auto

Access

Trunk

Trunk

Access

Desirable

Trunk

Trunk

Trunk

Access

Trunk

Trunk

Trunk

Trunk

Limited connectivity

Access

Auto

Desirable

Trunk

Access

Access

Limited connectivity

Access

802.1q Dynamic Trunking: OK

o
802.1q Native VLAN : Untaged ( se voc quer transportar um
trafego com vlan native em um trunk 801.2q necessrio configurar
o switchport trun native vlan x, pois todos os pacotes da vlan so
tageados menos o da vlan nativa.

TIP: Pode-se configurar o switch com o comando vlan tag native x


caso tenha necessidade de enviar um pacote com tag de VLAN.

o
VTP Domain / Transparent/ VTP Password / VTP Pruning /
Prune-Eligible List

Verso do protocolo VTP: 1, 2 ou 3

Tipos de mensagem VTP:


o

Summary advertisements: Por padro, os switches Catalyst emitem anncios de resumo em


incrementos de cinco minutos. Os anncios de resumo informam aos Catalysts adjacentes o nome de
domnio VTP atual e o nmero de reviso da configurao. Quando o switch recebe um pacote de
anncio de resumo, ele compara o nome de domnio VTP com seu prprio nome de domnio VTP. Se os
nomes forem diferentes, o switch simplesmente ignorar o pacote. Se os nomes forem iguais, o switch
comparar a reviso da configurao com sua prpria reviso. Se a sua prpria reviso da configurao
for superior ou igual, o pacote ser ignorado. Se for inferior, um pedido de anncio ser enviado.

Subset advertisement: Sempre que voc adiciona, exclui ou altera uma VLAN em um Catalyst, o
servidor Catalyst onde as alteraes foram realizadas incrementar a reviso de configurao e emitir
um anncio de resumo. Um ou mais anncios de subconjuntos seguiro o anncio de resumo. Um
anncio de subconjunto contm uma lista de informaes sobre a VLAN. Se houver vrias VLANs,
mais de um anncio de subconjunto poder ser solicitado para anunciar todas as VLANs.

Advertisement requests: O switch foi reiniciado. O nome de domnio VTP foi alterado. O switch
recebeu um anncio de resumo VTP com uma reviso de configurao maior que sua prpria. Ao
receber um pedido de anncio, um dispositivo VTP envia um anncio de resumo. Um ou mais anncios
de subconjunto seguem o anncio de resumo.

Modos do VTP
possvel configurar um switch para operar em um destes modos do VTP:

Servidor No modo de servidor VTP, voc pode criar, modificar e excluir VLANs, bem como especificar
outros parmetros de configurao, como verso e remoo do VTP, para todo o domnio VTP. Os servidores
VTP anunciam sua configurao de VLAN para outros switches do mesmo domnio VTP e sincronizam essa
configurao com outros switches com base nos anncios recebidos atravs de links de tronco. Servidor VTP
o modo padro.

Cliente Os clientes VTP comportam-se da mesma maneira que os servidores VTP, mas no possvel criar,
alterar nem excluir VLANs nesses clientes.

Transparente switches VTP transparentes no participam no VTP. Os switches VTP transparentes no


anunciam sua configurao de VLAN nem sincronizam essa configurao com base nos anncios recebidos.
Contudo, eles encaminham os anncios VTP recebidos atravs de suas portas de tronco no VTP Verso 2.

Desativado (configurvel somente nos switches CatOS) Nos trs modos descritos, os anncios VTP so
recebidos e transmitidos assim que o switch entra no estado de domnio de gerenciamento. No modo
desativado, os switches se comportam como no modo transparente VTP, porm, a nica diferena que os
anncios VTP no so encaminhados.

VTP Version 3 Do again!!!

PDF:
VTP_configurations.pdf

Layer 2 EtherChannel ( ON with ON )/ Layer 2 EtherChannel with


PAgP/ Layer 2 EtherChannel with LACP/ Layer 3 EtherChannel
For mode, select one of these keywords:

activeEnables LACP only if an LACP device is detected. It places an interface into an active negotiating state, in
which the interface starts negotiations with other interfaces by sending LACP packets.

auto Enables PAgP only if a PAgP device is detected. It places an interface into a passive negotiating state, in
which the interface responds to PAgP packets it receives but does not start PAgP packet negotiation.

desirableUnconditionally enables PAgP. It places an interface into an active negotiating state, in which the
interface starts negotiations with other interfaces by sending PAgP packets.

onForces the interface to channel without PAgP. With the on mode, a usable EtherChannel exists only when an
interface group in the on mode is connected to another interface group in the on mode.

non-silentIf your switch is connected to a partner that is PAgP-capable, you can configure the switch interface for
nonsilent operation. You can configure an interface with the non-silent keyword for use with
the auto or desirable mode. If you do not specify non-silent with the auto or desirable mode, silent is assumed.
The silent setting is for connections to file servers or packet analyzers. This setting allows PAgP to operate, to attach
the interface to a channel group, and to use the interface for transmission.

passiveEnables LACP on an interface and places it into a passive negotiating state, in which the interface
responds to LACP packets that it receives, but does not start LACP packet negotiation.

Mode:
ON + ON = (Channel)
On / Active / Passive + Off = ( No Channel )
Active + Active = ( Channel )
Active + Passive = ( Channel )
Passive / On + Passive = ( No Channel )

The load-balancing keywords indicate these values:

src-macSource MAC addresses

dst-macDestination MAC addresses

src-dst-macSource and destination MAC addresses

src-ipSource IP addresses

dst-ipDestination IP addresses

src-dst-ipSource and destination IP addresses (Default)

src-portSource Layer 4 port

dst-portDestination Layer 4 port

src-dst-portSource and destination Layer 4 port

Balance simple explanations:

Use the option that provides the balance criteria with the greatest variety in your configuration. For example,
if the traffic on an EtherChannel is going only to a single MAC address and you use the destination MAC
address as the basis of EtherChannel load balancing, the EtherChannel always chooses the same link in
that EtherChannel; using source addresses or IP addresses might result in better load balancing.

PDF:

Etherchannel_802.1q_InterVlan Routing.pdf

STP:
PDF:
STP_MST_features.pdf

STP Root Bridge Election

Some of the terminologies that has to be kept in mind wile designing STP:
1- Root ID The lowest Bridge-ID in the topology
2- Cost of Path Cost of all links from the desired switch to the root bridge
3- Bridge ID (BID) of the transmitting switch
4- Port ID Transmitting switch port ID
5- STP timer values Max_Age, Hello Time,
6- Forward Delay

BPDU Process :
1. Electing a Root Bridge :

BPDU s were sent in the broadcast domain. The switch with the lowest bridge
ID is elected as a root bridge.
2. One Root port is elected on each non root bridge:

With the help of received BPDUs the path cost on all switch ports were
compared. The port with the lowest cost to the root is automatically
assigned as a root port.
3. Election of Designated and Non-designated Ports:

All the switch ports in the root bridge will be acting as a designated port.
When 2 switches connected to the same segment sends BPDUs, there will be
2 root ports and the port with the lowest BID other than these 2 root ports will
be acting as a designated port. The other port will be blocked.

Spanning-Tree Port Roles


Root Port (RP) (UPSTREAM_BDPU) - It is a port on a non-root switch,
which is the shortest (the best) path towards the root bridge. Root Bridge
does NOT have any root ports. (No shortest path to itself ;-) )
Designated Port (DP) (DOWNSTREAM_BPDU) - It is a port that is in the
forwarding state. All ports of the root bridge are designated ports (they are
never in a blocking state). BPDU frames our sent out this port.
Non-Designated Port (NDP) - It is a port that is in a blocking state in the
STP topology.

Topology Change Notification (TCN) - the type of BPDU that a switch will
send if it detects the topology change (port going down, or TCN received).
This BPDU is sent out the Root Port (upstream) towards the root bridge
informing it, that the tree needs to be recomputed.
Topology Change Acknowledgement (TCA) - the type of BPDU that is
sent back to the sender of TCN BPDU, acknowledging the reception of the
notification.

Topology Changes
These are the differences between the RSTP and the 802.1D in handling spanning tree topology changes:

DetectionUnlike 802.1D in which any transition between the blocking and the forwarding state causes a topology
change, only transitions from the blocking to the forwarding state cause a topology change with RSTP (only an
increase in connectivity is considered a topology change). State changes on an edge port do not cause a topology
change. When an RSTP switch detects a topology change, it deletes the learned information on all of its nonedge
ports except on those from which it received the TC notification.

Notification the RSTP does not use TCN BPDUs, unlike 802.1D. However, for 802.1D interoperability, an RSTP
switch processes and generates TCN BPDUs.

AcknowledgementWhen an RSTP switch receives a TCN message on a designated port from an 802.1D switch,
it replies with an 802.1D configuration BPDU with the TCA bit set. However, if the TC-while timer (the same as the
TC timer in 802.1D) is active on a root port connected to an 802.1D switch and a configuration BPDU with the TCA
set is received, the TC-while timer is reset.
This method of operation is only required to support 802.1D switches. The RSTP BPDUs never have the TCA bit
set.

PropagationWhen an RSTP switch receives a TC message from another switch through a designated or root port,
it propagates the change to all of its nonedge, designated ports and to the root port (excluding the port on which it is
received). The switch starts the TC-while timer for all such ports and flushes the information learned on them.

Protocol migrationFor backward compatibility with 802.1D switches, RSTP selectively sends 802.1D
configuration BPDUs and TCN BPDUs on a per-port basis.
When a port is initialized, the migrate-delay timer is started (specifies the minimum time during which RSTP BPDUs
are sent), and RSTP BPDUs are sent. While this timer is active, the switch processes all BPDUs received on that
port and ignores the protocol type.
If the switch receives an 802.1D BPDU after the port migration-delay timer has expired, it assumes that it is
connected to an 802.1D switch and starts using only 802.1D BPDUs. However, if the RSTP switch is using 802.1D
BPDUs on a port and receives an RSTP BPDU after the timer has expired, it restarts the timer and starts using
RSTP BPDUs on that port.

TIPs:
RSTP.

UplinkFast and BackboneFast configurations are ignored in Rapid-PVST mode; both features are included in

STP Path Selection with Port Cost: OK

Com essa mudana ir afetar Local path selection.

STP Path Selection with Port Priority = 0

Com essa mudana ir afetar Downstream Neighbor.


o

Tuning STP Convergence Timers: OK

STP PortFast: OK

In order to reduce the number of topology changes, configure all edge ports in
the topology (connected to hosts, IP Phones, servers) as spanning-tree portfast.
Portfast ports do not generate TC events when they go up or down.

STP PortFast Default: OK

habilitado em todas as portas edge de um domnio STP.


o

STP UplinkFast: OK

To understand how UplinkFast helps speed up the convergence. Convergncia


de aproximadamente 1 segundo. Porm o TCN enviado aps 3 segundos!
No ocasionando perca de pacote.

STP BackboneFast:OK
Indirect failures should start recalculating immediately!

STP BPDU Guard/ STP BPDU Guard Default:OK

The BPDU Guard feature is used to protect the Spanning Tree domain from
external influence
If superior BPDUs is received the will get shutdown with (err-disabled).
You must apply these configurations on edge ports to avoid BPDU inferior on
the STP domain!
You can use together STP BPDU Guard Default and PortFast for guarantee
more security in your
Environment.
o
STP BPDU Filter ( Working Inbound and Outbound )/ STP BPDU
Filter Default ( Default with Portfast is works only outbound filter!)
Filter BPDUs IN end OUT.

Quando habilitado o comando spanning-tree bpdufilter na interface do SW_1 (


SW_01 para RT_01) o elemento SW_01 ir parar de enviar BDPU para o
RT_01.

STP Root Guard:OK


Root Guard is useful in avoiding Layer 2 loops during network
anomalies. The Root Guard feature forces an interface to become a
designated port to prevent surrounding switches from becoming a root
switch. In other words, Root Guard provides a way to enforce the root
bridge placement in the network. The Root Guard feature prevents
a Designated Port from becoming a Root Port. If a port on which
the Root Guard feature receives a superior BPDU, it moves the
port into a root-inconsistent state (effectively equal to a listening
state), thus maintaining the current Root Bridge status.
TIP:
You need define manually this feature to guarantee the topology
synchronization!!!

STP Loop Guard


proprietary ):

/ Unidirectional Link Detection

( Cisco-

Prevention unidirectional links


Loop Guard:
Send L1 keep alive packets for the neighbors
When implementing Loop Guard, you should be aware of the following
implementation guidelines;
With the Loop Guard feature, switches do an additional check before
transitioning to the STP forwarding state. If switches stop receiving BPDUs
on a no designated port with the Loop Guard feature enabled, the switch
places the port into the STP loop-inconsistent blocking state instead of
moving through the listening, learning, and forwarding states.
You configure the Loop Guard feature on a per-port basis, although the
feature blocks inconsistent ports on a per-VLAN basis.

Loop Guard cannot be enabled on a switch that also has Root Guard
enabled

Loop
Loop
Loop
Loop
Loop

Guard
Guard
Guard
Guard
Guard

does not affect Uplink Fast or Backbone Fast operation


must be enabled on point-to-point links only
operation is not affected by the Spanning Tree timers
cannot actually detect a unidirectional link
cannot be enabled on Port Fast or Dynamic VLAN ports

UDLD:
A unidirectional link occurs when traffic is transmitted between neighbors in
one direction only. Unidirectional Link Detection is a Layer 2 protocol.
UDLD performs tasks that Layer 1 mechanisms, such as auto negotiation,
cannot perform. When UDLD and auto-negotiation are enabled, both Layer 1
and Layer 2 detections work together to prevent physical and logical
unidirectional connections and the malfunctioning of other protocols.
Unidirectional links can cause spanning-tree topology loops. UDLD enables
devices to detect when a unidirectional link exists and also to shutdown the
affected interface. UDLD is useful on a fiber ports to prevent network issues
resulting in miswiring at the patch panel causing the link to be in up/up status
but the BPDUs are lost.

UDLD in aggressive mode:

UDLD aggressive mode is configured on point-to-point links. This mode comes


into play after a UDLD neighbor stops receiving UDLD updates from its
adjacent peer. In aggressive mode, the local device will attempt to reestablish the UDLD connection eight times. If the switch is unable to reestablish the connection within this timeframe, it will proceed and
errdisable the port.

MST:
The IEEE 802.1s implementation does not send BDPUs for every active STP instance separately, nor
does it encapsulate VLAN numbers list configuration messages. Instead, a special STP instance
number 0 called Internal Spanning Tree (IST aka MSTI0, Multiple Spanning Tree Instance 0) is
designated to carry all STP-related information.

IST, CIST, and CST Overview

Unlike other spanning tree protocols, in which all the spanning tree instances are independent; MST
establishes and maintains IST, CIST, and CST spanning trees:

An IST is the spanning tree that runs in an MST region.


Within each MST region, MST maintains multiple spanning tree instances. Instance 0 is a
special instance for a region, known as the IST. All other MST instances are numbered from 1 to
4094.
The IST is the only spanning tree instance that sends and receives BPDUs. All of the other
spanning tree instance information is contained in MSTP records (M-records), which are
encapsulated within MST BPDUs. Because the MST BPDU carries information for all instances,
the number of BPDUs that need to be processed to support multiple spanning tree instances is
significantly reduced.
All MST instances within the same region share the same protocol timers, but each MST instance
x has its own topology parameters, such as root bridge ID, root path cost, and so forth. By
default, all VLANs are assigned to the IST.
An MST instance is local to the region; for example, MST instance 1 in region A is independent of
MST instance 1 in region B, even if regions A and B are interconnected.

A CIST is a collection of the ISTs in each MST region.

The CST interconnects the MST regions and single spanning trees.

The spanning tree computed in a region appears as a sub-tree in the CST that encompasses the
entire switched domain. The CIST is formed by the spanning tree algorithm running among switches
that support the 802.1w, 802.1s, and 802.1D standards. The CIST inside an MST region is the same
as the CST outside a region.

M-Record is a sub-field, within the BPDU of MSTP instances that


enables corresponding instances to calculate a final topology

TIP:
revision number, treat this number like a software version number
in programming start from 1 and work upwards (1,2,3,4 etc). Keep in
mind that you have to change it manually (this isnt VTP) on all MST
switches it doesnt update automatically

MST Path selection


Same election process as CST/PVST
MST Root Bridge Election
Root Bridge:
1-Lowest BID
Root port:
1-Lowest cost
2-Lowest upstream BID
3-Lowest port ID

MST Path Selection with Port Cost (Will choose the lowest cost to Root Port)
MST Path Selection with Port Priority (Will choose the lowest Port-Priority to became the root port)
MST and Rapid Spanning Tree (Transaction almost immediately the ports states)

PDF:
Protect Ports_STP brodcastStorm.pdf

Protected Ports: OK

Some applications require that no traffic be forwarded by the Layer 2 protocol between ports on the
same switch. In such an environment, there is no exchange of unicast, broadcast, or multicast traffic
between ports on the switch, and traffic between ports on the same switch is forwarded through a
Layer 3 device such as a router.
To meet this requirement, you can configure Catalyst 2950 ports as protected ports (also referred to as
private VLAN edge ports). Protected ports do not forward any traffic to protected ports on the
same switch. This means that all traffic passing between protected portsunicast, broadcast, and
multicastmust be forwarded through a Layer 3 device (You cant configure vlan as mode switch
mode access in sub. interfaces). Protected ports can forward any type of traffic to nonprotected
ports, and they forward as usual to all ports on other switches. Dynamically learnt addresses are not
retained if the switch is reloaded.
Commando that you apply on interface: switchport protected

Traffic Storm Control : OK

A traffic storm occurs when packets flood the LAN, creating excessive traffic and degrading network
performance. The traffic storm control feature prevents LAN ports from being disrupted by a broadcast,
multicast, or unicast traffic storm on physical interfaces.
Traffic storm control (also called traffic suppression) monitors incoming traffic levels over a 1second traffic storm control interval, and during the interval it compares the traffic level with the traffic
storm control level that you configure. The traffic storm control level is a percentage of the total
available bandwidth of the port. Each port has a single traffic storm control level that is used for all
types of traffic (broadcast, multicast, and unicast).
Traffic storm control monitors the level of each traffic type for which you enable traffic storm control in
1-second traffic storm control intervals.
In all releases, and by default in Release 12.2(33)SXJ and later releases, within an interval, when the
ingress traffic for which traffic storm control is enabled reaches the traffic storm control level that is
configured on the port, traffic storm control drops the traffic until the traffic storm control interval ends.
Release 12.2(33)SXJ and later releases support these configurable traffic storm control optional
actions:

ShutdownWhen a traffic storm occurs, traffic storm control puts the port into the error-disabled
state. To reenable ports, use the error-disable detection and recovery feature or
the shutdown and no shutdown commands.

TrapWhen a traffic storm occurs, traffic storm control generates an SNMP trap.

MAC-Address Table Static Entries and Aging: OK

To switch frames between LAN ports efficiently, the switch maintains an address table. When the
switch receives a frame, it associates the media access control (MAC) address of the sending network
device with the LAN port on which it was received.
The switch dynamically builds the address table by using the MAC source address of the frames
received. When the switch receives a frame for a MAC destination address not listed in its address
table, it floods the frame to all LAN ports of the same VLAN except the port that received the frame.
When the destination station replies, the switch adds its relevant MAC source address and port ID to
the address table. The switch then forwards subsequent frames to a single LAN port without flooding
all LAN ports.
You can also enter a MAC address, which is termed a static MAC address, into the table. These static
MAC entries are retained across a reboot of the switch.
In addition, you can enter a multicast address as a statically configured MAC address. A multicast
address can accept more than one interface as its destination.

TIP:

If you enable the auto-learn option, the switch will update the entry if the same MAC address is seen
on a different port.

The switch uses a mechanism called aging to keep the Ethernet switching table current. For each
MAC address in the Ethernet switching table, the switch records a timestamp of when the information
about the network node was learned. Each time the switch detects traffic from a MAC address that is
in its Ethernet switching table, it updates the timestamp of that MAC address. A timer on the switch
periodically checks the timestamp, and if it is older than the value set for mac-table-aging-time, the
switch removes the node's MAC address from the Ethernet switching table. This aging process
ensures that the switch tracks only active MAC addresses on the network and that it is able to flush out
from the Ethernet switching table MAC addresses that are no longer available.
You configure how long MAC addresses remain in the Ethernet switching table using the mac-tableaging-time statement in either the edit ethernet-switching-options or the vlans hierarchy, depending on
whether you want to configure it for the entire switch or only for specific VLANs.
For example, if you have a printer VLAN, you might choose to configure the aging time for that VLAN
to be considerably longer than for other VLANs so that MAC addresses of printers on this VLAN age
out less frequently. Because the MAC addresses remain in the table, even if a printer has been idle for
some time before traffic arrives for it, the switch still finds the MAC address and does not need to flood
the traffic to all other interfaces.
Similarly, in a data center environment where the list of servers connected to the switch is fairly stable,
you might choose to increase MAC address aging time, or even set it to unlimited, to increase the
efficiency of the utilization of network bandwidth by reducing flooding

SPAN / RSPAN / ERSPAN / PSPAN / VSPAN = Precisa testar !!!

SPAN Terminology

Ingress traffic-Traffic that enters the switch.

Egress traffic-Traffic that leaves the switch.

Source (SPAN) port -A port that is monitored with use of the SPAN feature.

Source (SPAN) VLAN -A VLAN whose traffic is monitored with use of the SPAN feature.

Destination (SPAN) port -A port that monitors source ports, usually where a network analyzer
is connected.

Reflector Port -A port that copies packets onto an RSPAN VLAN.

Monitor port-A monitor port is also a destination SPAN port in Catalyst 2900XL/3500XL/2950
terminology.

Overviwe about SPANs mode.

Local SPAN-The SPAN feature is local when the monitored ports are all located on the same
switch as the destination port. This feature is in contrast to Remote SPAN (RSPAN), which this list
also defines.

Remote SPAN (RSPAN)-Some source ports are not located on the same switch as the destination
port. RSPAN is an advanced feature that requires a special VLAN to carry the traffic that is
monitored by SPAN between switches. RSPAN is not supported on all switches. Check the
respective release notes or configuration guide to see if you can use RSPAN on the switch that you
deploy.

Port-based SPAN (PSPAN)-The user specifies one or several source ports on the switch and one
destination port.

VLAN-based SPAN (VSPAN)-On a particular switch, the user can choose to monitor all the ports
that belong to a particular VLAN in a single command.

ESPAN-This means enhanced SPAN version. This term has been used several times during the
evolution of the SPAN in order to name additional features. Therefore, the term is not very clear.
Use of this term is avoided in this document.

Administrative source-A list of source ports or VLANs that have been configured to be monitored.

Operational source-A list of ports that are effectively monitored. This list of ports can be different
from the administrative source. For example, a port that is in shutdown mode can appear in the
administrative source, but is not effectively monitored.

Voice VLAN:OK

Rede Local baseada em classificao e marcao de pacotes


Se as ligaes Voip e o trfego de desktop estiverem na mesma VLAN, cada trfego tentar utilizar a
banda disponvel sem considerao com o outro perfil de trfego. Para evitar essa questo utilize
diferentes VLANs para permitir a segregao do VoIP dos outros dados. Aps a separao dos
dados, polticas de QoS podem ser aplicadas para priorizar o VoIP na rede.
O componente importante de uma rede de telefonia IP bem sucedida o correto provisionamento da
largura de banda, representando o mnimo de banda para um determinado link que no deve exceder
75% do total da largura de banda ( na prtica os valores so questionveis).

O trfego padro de uma ligao consiste em 2 tipos de trfego:


Stream de Voz: Pacotes RTP com as amostras de voz
Call Control Signaling: Pacotes responsveis pela sinalizao das chamadas
VLAN de Voz

Alguns modelos de Switches oferecem features chamadas de auxiliary VLAN ou voice VLAN.
Esse modelo de VLANs permite a atribuio dos telefones em sua prpria VLAN sem a interveno
do usurio final.
O usurio simplesmente coloca o telefone no Switch que ento providencia ao telefone as
configuraes necessrias da VLAN.
Com os telefones IP em suas prprias sub-redes e VLANs, os administradores podem facilmente
identificar e aplicar as polticas de QoS e segurana alm da convergncia da estrutura fsica.
PoE ( Power over Ethernet ):
A tecnologia PoE permite que o Switch ou Patch Pannel fornea energia diretamente ao telefone IP.
Classificao e Marcao
A tcnica de Classificao e Marcao identifica o perfil para priorizao adequada de cada trfego da
rede. O trfego examinado e classificado, o que pode ser feito pela examinaro de informaes de
diferentes camadas (modelo OSI).
O trfego pode ser classificado seguindo qualquer um dos critrios abaixo:
Camada 2: endereo MAC, cabealho 802.1q (e 802.1p), cabealho MPLS, CLP (ATM), DE (FrameRelay) ou pela interface de entrada.
Camada 3: precedncia IP, DSCP, endereo IP ou interface de entrada.
Camada 4: portas TCP ou UDP ou interface de entrada
Camada 7: assinatura de aplicaes ou interface de entrada
Todo trfego classificado ou agrupado de acordo com esses critrios sero marcados de acordo
com a sua classificao.
As marcaes de QoS estabelece nveis de prioridade ou prioridades de classes para trfego de rede
em cada Switch.

NOTE

Traditionally, a switchport on a Cisco switch that receives tagged packets is referred to as a trunk port.
However, when you configure a switchport to connect to a Cisco IP Phone, you configure it as an

access port (for the untagged data from the PC) while supporting tagged traffic from the IP phone. So,
think of these ports as "access ports supporting tagged voice VLAN traffic."

NOTE

Keep in mind that Cisco IP phones will be able to receive this voice VLAN configuration from the
switch via CDP. After it receives the voice VLAN number, the IP Phone begins tagging its own
packets. Non-Cisco IP Phones cannot understand CDP packets. This typically requires you to
manually configure each of the non-Cisco IP Phones with its voice VLAN number from a local phone
configuration window (on the IP phone).

Smartport Macros:OK

Understanding SmartPort Macros


Smartport macros provide a convenient way to save and share common configurations. You can use
Smartport macros to enable features and settings based on the location of a switch in the network and
for mass configuration deployments across the network.
Each Smartport macro is a set of CLI commands that you define. SmartPort macro sets do not contain
new CLI commands; Each Smartport macro is a group of existing CLI commands.
When you apply a SmartPort macro on an interface, the CLI commands contained within the macro
are configured on the interface. When the macro is applied to an interface, the existing interface
configurations are not lost. The new commands are added to interface and are saved in the running
configuration file.

TIP-1:
If you modify a macro definition by adding or deleting commands, the changes are not
reflected on the interface where the original macro was applied. You need to reapply the updated
macro on the interface to apply the new or changed commands.

TIP-2:
You can use the macro trace macro-name interface configuration command to show what
macros are running on an interface or to debug the macro to determine any syntax or configuration
errors.

Cisco-Default Smartports Macros


cisco-global: Use this global configuration macro to enable load balancing across VLANs, provide
rapid convergence of spanning-tree instances and to enable port error recovery.
cisco-desktop: Use this interface configuration macro for increased network security and reliability
when connecting a desktop device, such as a PC, to a switch port.

cisco-phone: Use this interface configuration macro when connecting a desktop device such as a PC
with a Cisco IP Phone to a switch port. This macro is an extension of the cisco-desktop macro and
provides the same security and resiliency features, but with the addition of dedicated voice VLANs to
ensure proper treatment of delay-sensitive voice traffic.
cisco-switch: Use this interface configuration macro when connecting an access switch and a
distribution switch or between access switches connected using GigaStack modules or GBICs.
cisco-router: Use this interface configuration macro when connecting the switch and a WAN router.
cisco-lre-cpe: Use this interface configuration macro to optimize performance when the switch is
installed in apartment buildings or hotels, or when it is used to deliver Video-on-Demand (VoD), or
multicast video.
cisco-wireless: Use this interface configuration macro when connecting the switch and a wireless
access point.
PDF:
Smart Port_Macro.pdf

Private VLANs

A private VLAN domain has only one primary VLAN. Each port in a private VLAN domain is a member
of the primary VLAN; the primary VLAN is the entire private VLAN domain.
Secondary VLANs provide isolation between ports within the same private VLAN domain. The
following two types are secondary VLANs within a primary VLAN:

Isolated VLANsPorts within an isolated VLAN cannot communicate directly with each other at
the Layer 2 level.

Community VLANsPorts within a community VLAN can communicate with each other but
cannot communicate with ports in other community VLANs or in any isolated VLANs at the Layer 2
level.

Primary VLANs and the two types of secondary VLANs (isolated and community) have these
characteristics:

Primary VLAN the primary VLAN carries traffic from the promiscuous ports to the host ports,
both isolated and community, and to other promiscuous ports.

Isolated VLAN an isolated VLAN is a secondary VLAN that carries unidirectional traffic
upstream from the hosts toward the promiscuous ports. You can configure multiple isolated VLANs
in a private VLAN domain; all the traffic remains isolated within each one. Each isolated VLAN can
have several isolated ports, and the traffic from each isolated port also remains completely
separate.

Community VLANa community VLAN is a secondary VLAN that carries upstream traffic from
the community ports to the promiscuous port and to other host ports in the same community.
You can configure multiple community VLANs in a private VLAN domain. The ports within one
community can communicate, but these ports cannot communicate with ports in any other
community or isolated VLAN in the private VLAN.

Another TIP:
Terminology:
Promiscuous Port This is the primary VLAN that can communicate with all
the other Isolated & Community ports with the PVLAN environment.
Isolated Port This is a secondary VLAN that will only communicate with the
primary promiscuous VLAN. Isolated ports cannot even communicate with
other isolated ports. Since we are talking about VLANs, communication is
blocked at the Layer 2 perspective. (At which layer do VLANs operate at,
Layer 2)
Community Port This is another type of a secondary VLAN, like Isolated
ports a community port can also communicate with the primary
promiscuous VLAN. The big difference here is that a port configured in a
secondary community VLAN can also communicate with other ports
configured as community ports. They will not however be able to
communicate with ports configured in an isolated VLAN.
Traffic Flows:
Since these Private VLANs operate at layer 2 it is worth pointing out some
specific traffic flows, after all it is worth considering the implication of this
isolation and typical broadcast/multicast flows:
Broadcast Traffic
The promiscuous port will forward broadcast traffic to all isolated &
community ports. (Including trunks)
The Isolated port will only forward the broadcast to a promiscuous port.
(Including trunks)
Community ports will forward broadcast to the promiscuous & other
community ports. (Including trunks)
PDF:
PrivateVLANs.pdf

Layer 2 WAN Circuits

HDLC: OK
hdlc-101211214058-phpapp01.pptx
PPP:
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol
datagrams over point-to-point links. PPP is comprised of three main components:
1.

A method for encapsulating multi-protocol datagrams.

2.

A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link
connection.

3.

A family of Network Control Protocols (NCPs) for establishing and configuring different
network-layer protocols.

PPP Authentication ( PAP and CHAP )


PAP authentication involves a two-way handshake where the username and password are sent
across the link in clear text; hence, PAP authentication does not provide any protection against
playback and line sniffing.
R1 and R2
R1#
!
username R1 password 0 cisco
interface Serial0/0
ip address 1.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication pap
ppp pap sent-username R2 password 0 cisco
R2#
!
username R2 password 0 cisco
!
interface Serial0/0
ip address 1.1.1.2 255.255.255.0
encapsulation ppp

ppp authentication pap


ppp pap sent-username R1 password 0 cisco

CHAP authentication, on the other hand, periodically verifies the identity of the remote node using a
three-way handshake. After the PPP link is established, the host sends a "challenge" message to the
remote node. The remote node responds with a value calculated using a one-way hash function. The
host checks the response against its own calculation of the expected hash value. If the values match,
the authentication is acknowledged; otherwise, the connection is terminated.
R1 and R2
R1#
username R1 password 0 cisco
interface Serial0/0
ip address 1.1.1.1 255.255.255.0
encapsulation chap
clock rate 2000000
ppp authentication chap
R2#
!
username R2 password 0 cisco
!
interface Serial0/0
ip address 1.1.1.2 255.255.255.0
encapsulation ppp
clock rate 2000000
ppp authentication chap
!

PPP Multilink
The Multilink PPP feature provides load balancing functionality over multiple WAN links while
providing multivendor interoperability, packet fragmentation, proper sequencing, and load
calculation on both inbound and outbound traffic. Cisco's implementation of Multilink PPP supports the
fragmentation and packet sequencing specifications in RFC 1990. Additionally, you can change the
default endpoint discriminator value that is supplied as part of user authentication. Refer to RFC 1990
for more information about the endpoint discriminator. Multilink PPP allows packets to be fragmented
and the fragments to be sent at the same time over multiple point-to-point links to the same remote
address. The multiple links come up in response to a defined dialer load threshold. The load can be
calculated on inbound traffic or outbound traffic, as required for the traffic between the specific sites.
Multilink PPP provides bandwidth on demand and reduces transmission latency across WAN
links. Multilink PPP is designed to work over synchronous and asynchronous serial types
of single or multiple interfaces that have been configured to support both dial-on-demand rotary groups
and PPP encapsulation.

Multilink PPP Minimum Links Mandatory


Multilink PPP allows multiple PPP links to be established in parallel to the same destination. Multilink
PPP is often used to increase the amount of bandwidth between points. The Multilink PPP Minimum
Links Mandatory feature enables you to configure the minimum number of links that are required in a
Multilink PPP bundle to keep the bundle active.
The Multilink PPP Minimum Links Mandatory feature causes all Network Control Protocols (NCPs) for
a Multilink PPP bundle to be disabled until the Multilink PPP bundle has the required minimum number
of links. When a new link is added to a Multilink PPP bundle to bring the number of links up to the
required number of minimum links, the NCPs are activated for the Multilink PPP bundle. When a link is
removed from a Multilink PPP bundle, the number of links falls below the required minimum number of
links for that Multilink PPP bundle, and the NCPs are disabled for that Multilink PPP bundle.

TIP:
Synchronous: ( send frames of large data blocks)
The synchronous format, receiver or transmitters are synchronized. A block of information is
transmitted along with the synchronization information. This is clk oriented transmission format. This
information is specially used for high speed transmission. Usually in this synchronous system one or
two SYNC character are used for data synchronous data system. Transmission device send data
continuously to receiving device. If the data is not ready this system continuously synchronous data
until the data is unviable.

Asynchronous: (sent in individual bytes)


It is character oriented. Each character comes with the information of start and stop ( each 8 bits ). In
this system 1 for mark, 0 for space. When data are being transmitted a receiver stay at high at logic 1.
This is specially used in low speed transmission.

PPPoE

Header PPPoE format Packet:

Configurations: PPPoE without and with DHCP.


http://blog.ine.com/2008/01/20/example-configurations-for-ppp-overethernet-pppoe/
TIP:
http://www.differencebetween.net/technology/difference-betweendhcp-and-pppoe/

Configuring PPPoE in a VPDN group limited PPPoE configuration options


because only one PPPoE VPDN group with one virtual template is permitted
on a device.
The PPPoE Profiles feature (bba-group) provides simplicity and flexibility in
PPPoE configuration by separating PPPoE from VPDN configuration. The
PPPoE Profiles feature allows multiple PPPoE profiles, each with a different
configuration, to be used on a single device.

CCIE R&S v5 Advanced Technology Labs IP Routing

Routing to Multipoint Broadcast Interfaces: OK

Routing to NBMA Interfaces: OK

NBMA (non-broadcast multiple access) is one of four network types in the


OSPF (Open Shortest Path First) communications protocol. NBMA is used to
accurately model X.25 and frame relay environments in multiple-access
networks where there are no intrinsic broadcast and multicast capabilities.
The other OSPF network types are: broadcast, point-to-point, and point-

to-multipoint. In an NBMA configuration, OSPF sends HELLO packets


(packets sent periodically to establish and confirm neighbor relationships
between routers) to each router one at a time rather than multicasting them.
The HELLO timer (which tells the router how often to send HELLO packets) is
extended from 10 to 30 seconds and the dead router timer (which tells
the router how long to wait before it decides that a neighboring router is not
functioning) is extended from 40 to 120 seconds.
Site:
http://ccieblog.co.uk/ospf/ospf-non-broadcast-nbma-network

Longest Match Routing:OK

As an example, if you have a routing table entry which is similar to the following :
--- 192.168.128.0/23 -> next hop 192.168.1.1 via FastEthernet0/0
When the router receives a packet destined for 192.168.129.14, the router will compare the first 23 bits of
192.168.129.14 to 192.168.128.0 and if they match (which they do) then the router will transmit the packet
out of FastEthernet0/0 using the destination MAC address of 192.168.1.1.

To summarize this subject: The longest match is referring to the longest or most specific prefix which is
matched against a destination address.

TIP:
Longer prefixes are always preferred over shorter ones when forwarding a packet.

Floating Static Routes:OK

You can configure two different ways for the same destinations with different
AD. The lowest AD will be choosing and when this bring down another AD will
bring UP.

Reliable Static Routing with Enhanced Object Tracking:OK


The Reliable Static Routing Backup Using Object Tracking feature
introduces the ability for the Cisco IOS software to use Internet Control
Message Protocol (ICMP) pings to identify when a Point-to-Point
over Ethernet (PPPoE) or IP Security Protocol (IPSec) Virtual
Private Network (VPN) tunnel goes down, allowing the initiation of
a backup connection from any alternative port. The Reliable Static
Routing Backup Using Object Tracking feature is compatible with both
preconfigured static routes and Dynamic Host Configuration Protocol
(DHCP) configurations.
Traffic from the remote LAN is forwarded to the main office from the
primary interface of the remote router. If the connection to the main
office is lost, the status of the tracked object changes from up to down.
When the state of the tracked object changes to down, the routing
table entry for the primary interface is removed and the preconfigured

floating static route is installed on the secondary interface. Traffic is


then forwarded to the preconfigured destination from the secondary
interface. When the state of the tracked object changes from down to
up, the routing table entry for the primary interface is reinstalled and
the floating static route for the secondary interface is removed

Policy Routing:OK
Each entry in a route map statement contains a combination of match
and set clauses/commands. The match clauses define the criteria for
whether appropriate packets meet the particular policy (that is, the
conditions to be met). The set clauses than explain how the packets
should be routed once they have met the match criteria. For each
combination of match and set commands in a route map statement, all
sequential match clauses must be met simultaneously by the packet
for the set clauses to be applied. There may be multiple sets of
combinations of match and set commands in a full route map
statement. The route maps statements can also be marked
as permit or deny. If the statement is marked as a deny, the packets
meeting the match criteria are sent back through the normal
forwarding channels (in other words, destination-based routing is
performed). Only if the statement is marked as permit and the packets
meet the match criteria are all the set clauses applied. If the
statement is marked as permit and the packets do not meet
the match criteria, then those packets are also forwarded
through the normal routing channel.
Policy-based routing is applied to incoming packets. All packets
received on an interface with policy-based routing enabled are
considered for policy-based routing. The router passes the packets
through enhanced packet filters called route maps. Based on the
criteria defined in the route maps, packets are forwarded/routed to the
appropriate next hop.

Reliable Policy Routing:OK

Reliable Policy Routing can be configured by using the "set ip next-hop verifyavailability" statement in a route-map. There are two ways to verify the
availability of the next-hop. One way is to use CDP. The other way is to use a
tracked object (e.g. IP SLA).
Packet Capture:

Wireshark_capituras\ICMP_IP_SLA.pcap

Verify availability of next-hop using CDP:


route-map PBR_FROM_R3 permit 10
match ip address FROM_R3_TO_R4
set ip next-hop 155.1.0.5
set ip next-hop verify-availability
set ip default next-hop 155.1.146.4
Verify availability using a tracked object:
route-map PBR_FROM_R3 permit 20
match ip address FROM_R3_TO_R5
set ip next-hop verify-availability 155.1.146.4 1 track 1
set ip default next-hop 155.1.0.5

Local Policy Routing:OK

Cisco IOS has a special feature called local policy routing, which permits to
apply a route-map to local (router-generated) traffic. The first way we can use
this feature is to re-circulate local traffic (and force it re-enter the router).
Heres an example. By default, locally-generated packets are not
inspected by outgoing access-lists. This may cause issues when local
traffic is not being reflected under reflexive access-list entries. Say with
configuration like that:
! Reflect all "session-oriented" traffic:
ip access-list extended EGRESS
permit tcp any any reflect MIRROR
permit icmp any any reflect MIRROR
permit udp any any reflect MIRROR
Evalute the reflected entries
ip access-list extended INGRESS
evaluate MIRROR
permit ospf any any
!

interface fast 0/0


ip address 54.1.1.6 255.255.255.0
ip access-group INGRESS in
ip access-group EGRESS out
You would not be able to telnet out of a router to destinations behind the Fast
interface, even though TCP sessions are reflected in access-list. To fix the
issue, we may use local-policy to force the local traffic re-enter the router and
be inspected by outgoing access-list:
!
Redirect local telnet traffic via the Loopback interface
!
ip access-list extended LOCAL_TRAFFIC
permit tcp any any eq 23
!
route-map LOCAL_POLICY 10
match ip address LOCAL_TRAFFIC
set interface Loopback0
!
! Traffic sent to Loopback interface re-enters the router
!
Interface Loopback0
ip address 150.1.6.6 255.255.255.50

Command to apply the local-policy


!
ip local policy route-map LOCAL_POLICY
With this configuration, local telnet session will re-enter the router and hit the
outgoing access-list, thereby triggering a reflected entry. This same idea may
be utilized to force CBAC inspection of locally-generated traffic, by since
12.3T there has been a special IOS feature to do this natively.
The other useful application of local policy routing is using it for traffic
filtering. For example you may want to prohibit outgoing telnet sessions from
local router to a certain destination:

ip access-list extended BLOCK_TELNET


permit tcp any host 150.1.1.1 eq 23
!
route-map LOCAL_POLICY 10

match ip address BLOCK_TELNET


set interface Null 0
!
! Command to apply the local-policy
!
ip local policy route-map LOCAL_POLICY
!
The syntax is somewhat similar to the vlan access-maps used on Catalyst
switches, and similarly the route-map is applied globally, i.e. to all router
traffic, going out on any interface. Note that you may use the same idea to
block incoming session, simply by reversing entries in access-list. (e.g.
permit tcp any eq 23 host 150.1.1.1). Best of all, with PBR you may apply
additional criteria to incoming traffic, e.g. match packet sizes.
The last example is the use of local PBR to apply special treatment to
management/control plane traffic e.g. use different output interfaces for
out-of-band management. With local PBR you may also apply special marking
for control traffic, e.g. selectively assign IP precedence values.
ip access-list extended MANAGEMENT_TRAFFIC
permit tcp any eq 23 any
permit tcp any eq 22 any
!
route-map LOCAL_POLICY 10
match ip address MANAGEMENT_TRAFFIC
set interface fast 0/1
set ip precedence 7
ip local policy route-map LOCAL_POLICY
Keep these simple features in mind, while considering options for
you CCIE lab task solution.

GRE Tunneling:OK

Capture_(IP_GRE_EIGRP):
Wireshark_capituras\(IP_GRE_EIGR).pcap

Routing Process:

http://blog.ccna.com.br/2008/12/23/pr-tunelamento-gre-genericrouting-encapsulation/
http://packetlife.net/blog/2012/feb/27/gre-vs-ipip-tunneling/

http://www.h3c.com/portal/Technical_Support___Documents/Technical
_Documents/Security_Products/H3C_SecPath_F1000E/Configuration/Operation_Manual/H3C_SecPath_HighEnd_OM(F3169_F3207)-5PW106/06/201109/725905_1285_0.htm

GRE Tunneling and Recursive Routing:OK

Problems with recursive routing can be avoided by configuring appropriate


static routes to the tunnel destination. A recursive route is when the best
path to the "tunnel destination" is through the tunnel itself. This
situation will cause the tunnel interface to bounce up and down. You will see
the following error when there is a recursive routing problem.
%TUN-RECURDOWN Interface Tunnel 0
temporarily disabled due to recursive routing
Solutions:

To avoid recursive routing problems, keep passenger and transport


network routing information disjointed with one of these methods:

->Use a different Autonomous System (AS) number or tag.


->Use a different routing protocol.
->Use static routes to override the first hop, but watch for routing loops.
-> You can configure some acl to avoid route back to the tunnel.

Wireshark_capituras\(IP_GRE_OSPF).pcap
Wireshark_capituras\(IP_GRE_EIGR).pcap

GRE Backup Interface / GRE Reliable Backup Interface:OK

Today I also looked at using GRE for backup interface specifically using the
keep alive feature. This is to combat issue when using a multipoint interface
that there is the possibility that end to end connectivity is unavailable but the
line protocol remains up as of other active DLCI connected to the multipoint
interface. We previously used other preferential solution like ip sla or using
p2p interfaces but this a legacy version of doing it. I need to know for the
exam so I will lab it out.
Wireshark_capituras\(Ping_SRC_IP_Dst_GRE_Backup_interface_).pcap

ODR - On-Demand Routing:OK

ODR allows you to easily install IP stub networks where the hubs dynamically
maintain routes to the stub networks. This installation is accomplished
without requiring the configuration of an IP routing protocol on the stubs. In
fact, from the standpoint of ODR, a router is automatically considered to be a
stub when no IP routing protocols have been configured.
A stub router that supports the ODR feature advertises IP prefixes
corresponding to the IP networks configured on all directly connected
interfaces. If the interface has multiple logical IP networks configured, only
the primary IP network is advertised through ODR. Because ODR advertises IP

prefixes and not simply IP network numbers, ODR is able to carry variablelength subnet mask (VLSM) information.
Once ODR is enabled on a hub router, the hub router begins installing stub
network routes in the IP forwarding table. The hub router also can be
configured to redistribute these routes into any configured dynamic IP routing
protocols.
ODR uses the Cisco Discovery Protocol to carry minimal routing information
between the hub and stub routers. The stub routers send IP prefixes to the
hub router. The hub router provides default route information to the stub
routers, thereby eliminating the need to configure a default route on each
stub router.

TIP:

Be careful that you do not forget CDP enabled.


ODR works properly on either broadcast or non-broadcast networks.
ODR is not CPU intensive and it consumes very little bandwidth.
ODR it is able to carry VLSM information.
ODR supports several settings.

Configurations:
ODR.pdf
Packet capture:
Wireshark_capituras\(cdp.tlv.type) or (text)_ODR.pcap

CCIE R&S v5 Advanced Technology Labs RIP

RIPv2 Basic Configuration:OK

RIPv2 Authentication ( without and with MD5 ):OK

The Key chain is the same for without and with MD5:
YOU MUST APPLY IN BOTH DIRECTIONS!!!
#
key chain RIP
key 1
key-string ccie
ip rip authentication key-chain RIP
#
#
Without MD5
#
#
Interface x/x
ip rip authentication key-chain RIP
#
With MD5
#
#
Interface x/x
ip rip authentication key-chain RIP
ip rip authentication mode md5
#
Wireshark_capituras\RIP_Key-chain_sem MD5_(rip.auth.passwd).pcap
Wireshark_capituras\RIP_Key-chain_com MD5_(rip.auth.passwd).pcap

RIPv2 Split Horizon:OK

Split horizon is a method of preventing a routing loop in a network. The basic


principle is simple: Information about the routing for a particular packet is
never sent back in the direction from which it was received. Split horizon can
be achieved by means of a technique called poison reverse. This is the
equivalent of route poisoning all possible reverse paths - that is, informing all
routers that the path back to the originating node for a particular packet has

an infinite metric. Split horizon with poison reverse is more effective than
simple split horizon in networks with multiple routing paths, although it
affords no improvement over simple split horizon in networks with only one
routing path.
Example:

RouterA: Loopback: 2.2.2.2 /32 ; Router B: Loopback: 2.2.2.2/32


Router_C(config-router)#
*Mar
1 01:03:18.383: RIP: received v2 update from 150.30.0.3 on
FastEthernet0/0
*Mar 1 01:03:18.387:
1.1.1.1/32 via 0.0.0.0 in 2 hops
*Mar 1 01:03:18.391:
2.2.2.2/32 via 0.0.0.0 in 1 hops
*Mar 1 01:03:18.395:
150.20.20.0/24 via 0.0.0.0 in 1 hops
R4(config-router)#
*Mar
1 01:03:25.519: RIP: sending v2 update to 224.0.0.9 via
FastEthernet0/0 (150.30.0.4)
*Mar 1 01:03:25.523: RIP: build update entries
*Mar 1 01:03:25.527: 3.0.0.0/8 via 0.0.0.0, metric 1, tag 0
R4(config-router)#
*Mar
1 01:03:44.943: RIP: received v2 update from 150.30.0.3 on
FastEthernet0/0
*Mar 1 01:03:44.943:
2.2.2.2/32 via 0.0.0.0 in 2 hops
*Mar 1 01:03:44.947:
3.3.3.3/32 via 0.0.0.0 in 1 hops
*Mar 1 01:03:44.951:
150.20.20.0/24 via 0.0.0.0 in 1 hops
o
RIPv2 Auto-Summary:OK
R2(config-router)#do sh ip ro rip
R 1.0.0.0/8 [120/1] via 150.10.1.1, 00:00:03, FastEthernet0/0

R2(config-router)#do sh ip pro
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 13 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
FastEthernet0/0
2
2
RIP
FastEthernet0/1
2
2
FastEthernet1/1
2
2
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
2.0.0.0
150.10.0.0
150.20.0.0
150.50.0.0
Passive Interface(s):
Loopback2
Routing Information Sources:
Gateway
Distance
Last Update
150.20.20.3
120
00:00:07
Gateway
Distance
Last Update
150.10.1.1
120
00:00:08
150.50.0.4
120
03:48:16
Distance: (default is 120)
R2(config-router)#

RIPv2 Send and Receive Versions:OK

Local router ( R1 )
R1(config)#do sh ip pro
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set

Sending updates every 30 seconds, next due in 12 seconds


Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
FastEthernet0/0
1
2
RIP
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
1.0.0.0
10.0.0.0
66.0.0.0
150.10.0.0
Passive Interface(s):
Loopback1
Loopback11
Loopback12
Loopback13
Loopback14
Loopback15
Passive Interface(s):
Loopback16
Loopback66
Routing Information Sources:
Gateway
Distance
Last Update
150.10.1.2
120
00:00:09
Distance: (default is 120)
Remote ( R2 )
R2(config-if)#do sh ip pro
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 21 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send
Recv Triggered RIP Key-chain
FastEthernet0/0
1 2
1
RIP
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:

2.0.0.0
150.10.0.0
150.20.0.0
150.50.0.0
Passive Interface(s):
Loopback2
Routing Information Sources:
Gateway
Distance
Last Update
150.10.1.1
120
00:00:21
Distance: (default is 120)
Wireshark_capituras\(rip.version)_V1 and V2_Filter.pcap

RIPv2 Manual Summarization:OK

128 64 32 16 8 4 2 1
Address: 1.1.2.1
Binary: 00000001.0000001.00000010.00000000
Address: 1.1.3.1
Binary: 00000001.0000001.00000011.00000000
Address: 1.1.4.1
Binary: 00000001.0000001.00000100.00000000
Address: 1.1.5.1
Binary: 00000001.0000001.00000101.00000000
Address: 1.1.6.1
Binary: 00000001.0000001.00000110.00000000
Final IP summary: 1.1.2.0/21
Command applications!
Interface x/x
Ip summary rip 1.1.2.0 255.255.248.0
R2 receved ip route update from R1:
R2(config-if)#do sh ip ro rip

1.0.0.0/21 is subnetted, 1 subnets


1.1.0.0 [120/1] via 150.10.1.1, 00:00:11, FastEthernet0/0

Wireshark_capituras\RIP_Summary address_1.1.2.0-21.pcap
o

RIPv2 Convergence Timers:OK

RIPv2 Offset List:OK

TIP:
R3(config-router)#offset-list filter in 16 fastEthernet 0/0
Access-list type conflicts with prior definition
% This command only accepts named standard IP access-lists.
#
ip access-list standard filter
permit 150.50.0.0 0.0.0.255
#
router rip
version 2
passive-interface Loopback3
offset-list filter in 16 FastEthernet0/0
#
R3(config-router)#do sh ip prot
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Incoming routes in FastEthernet0/0 will have 16 added to metric if
on list filter
Sending updates every 30 seconds, next due in 26 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
FastEthernet0/0
2
2
FastEthernet0/1
2
2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
3.0.0.0
150.20.0.0
150.30.0.0
Passive Interface(s):

Loopback3
Routing Information Sources:
Gateway
Distance
Last Update
150.30.0.4
120
00:00:02
Gateway
Distance
Last Update
150.20.20.2
120
00:00:00
Distance: (default is 120)
Log:
R3(config-router)#do deb ip rip
*Mar
1 00:47:00.347: RIP: received v2 update from 150.20.20.2 on
FastEthernet0/1
*Mar 1 00:47:00.347:
4.4.4.4/32 via 0.0.0.0 in 2 hops
*Mar 1 00:47:00.355:
150.30.0.0/24 via 0.0.0.0 in 2 hops
*Mar
1 00:47:00.719: RIP: received v2 update from 150.30.0.4 on
FastEthernet0/0
*Mar 1 00:47:00.719:
1.1.0.0/21 via 0.0.0.0 in 3 hops
*Mar 1 00:47:00.723:
2.2.2.2/32 via 0.0.0.0 in 2 hops
*Mar 1 00:47:00.727:
4.4.4.4/32 via 0.0.0.0 in 1 hops
*Mar 1 00:47:00.731:
10.10.1.1/32 via 0.0.0.0 in 3 hops
*Mar 1 00:47:00.739:
150.10.1.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:47:00.743:
150.50.0.0/24 via 0.0.0.0 in 17 hops
(inaccessible)
R3(config)#do sh run | se access-list
ip access-list standard filter
permit 150.50.0.0 0.0.0.255
R3(config)#
R3(config)#
R3(config)#do sh access-list
Standard IP access list filter
10 permit 150.50.0.0, wildcard bits 0.0.0.255 (46 matches)
RIPv2 Filtering with Passive Interface:OK
Updates from R2 interfaces F1/1 to R4.
You can see below the R4 only received updated from R2(interface f1/1) and
another interface send and received update( Interface f0/0).
Topology:
R2 (f1/1) (f1/1)

R4

R2(config-router)#do sh ip prot

Routing Protocol is "rip"


Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 25 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
FastEthernet0/0
2
2
RIP
FastEthernet0/1
2
2
Loopback33
2
2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
2.0.0.0
33.0.0.0
150.10.0.0
150.20.0.0
150.50.0.0
Passive Interface(s):
FastEthernet1/1
Loopback2
Routing Information Sources:
Gateway
Distance
Last Update
150.20.20.3
120
00:00:23
150.10.1.1
120
00:00:24
150.50.0.4
120
00:00:15
Distance: (default is 120)

R4(config)#do deb ip rip


*Mar
1 01:15:01.167: RIP: sending v2 update to 224.0.0.9 via
FastEthernet1/1 (150.50.0.4)
*Mar 1 01:15:01.171: RIP: build update entries
*Mar 1 01:15:01.171: 3.3.3.3/32 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:15:01.171: 4.4.4.4/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:15:01.171: 150.30.0.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:15:01.191: RIP: received v2 update from 150.30.0.3 on
FastEthernet0/0
*Mar 1 01:15:01.191:
1.1.0.0/21 via 0.0.0.0 in 3 hops
*Mar 1 01:15:01.195:
2.2.2.2/32 via 0.0.0.0 in 2 hops
*Mar 1 01:15:01.199:
3.3.3.3/32 via 0.0.0.0 in 1 hops
*Mar 1 01:15:01.199:
10.10.1.1/32 via 0.0.0.0 in 3 hops
*Mar 1 01:15:01.203:
33.33.33.33/32 via 0.0.0.0 in 2 hops

*Mar 1 01:15:01.207:
66.66.66.0/24 via 0.0.0.0 in 3 hops
*Mar 1 01:15:01.211:
150.10.1.0/24 via 0.0.0.0 in 2 hops
*Mar 1 01:15:01.215:
150.20.20.0/24 via 0.0.0.0 in 1 hops
*Mar 1 01:15:01.215:
150.50.0.0/24 via 0.0.0.0 in 2 hops
*Mar
1 01:15:18.655: RIP: sending v2 update to 224.0.0.9 via
FastEthernet0/0 (150.30.0.4)
*Mar 1 01:15:18.659: RIP: build update entries
*Mar 1 01:15:18.659: 1.1.0.0/21 via 0.0.0.0, metric 3, tag 0
*Mar 1 01:15:18.663: 2.2.2.2/32 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:15:18.667: 4.4.4.4/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:15:18.671: 10.10.1.1/32 via 0.0.0.0, metric 3, tag 0
*Mar 1 01:15:18.675: 33.33.33.33/32 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:15:18.675: 66.66.66.0/24 via 0.0.0.0, metric 3, tag 0
*Mar 1 01:15:18.679: 150.10.1.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:15:18.679: 150.50.0.0/24 via 0.0.0.0, metric 1, tag 0
*Mar
1 01:15:26.787: RIP: sending v2 update to 224.0.0.9 via
FastEthernet1/1 (150.50.0.4)
*Mar 1 01:15:26.791: RIP: build update entries
*Mar 1 01:15:26.791: 3.3.3.3/32 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:15:26.795: 4.4.4.4/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:15:26.799: 150.30.0.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:15:30.815: RIP: received v2 update from 150.30.0.3 on
FastEthernet0/0
*Mar 1 01:15:30.815:
1.1.0.0/21 via 0.0.0.0 in 3 hops
*Mar 1 01:15:30.819:
2.2.2.2/32 via 0.0.0.0 in 2 hops
*Mar 1 01:15:30.823:
3.3.3.3/32 via 0.0.0.0 in 1 hops
*Mar 1 01:15:30.827:
10.10.1.1/32 via 0.0.0.0 in 3 hops
*Mar 1 01:15:30.827:
33.33.33.33/32 via 0.0.0.0 in 2 hops
*Mar 1 01:15:30.827:
66.66.66.0/24 via 0.0.0.0 in 3 hops
*Mar 1 01:15:30.827:
150.10.1.0/24 via 0.0.0.0 in 2 hops
*Mar 1 01:15:30.827:
150.20.20.0/24 via 0.0.0.0 in 1 hops
*Mar 1 01:15:30.827:
150.50.0.0/24 via 0.0.0.0 in 2 hops

RIPv2 Filtering with Prefix-Lists:OK

R1 wont advertise 1.1.2.1/32 and 1.1.5.1/32 to R2.


Topology:
R1 R2
R1(config)#do sh run | se ip prefix
ip prefix-list R1_to_R2 seq 5 deny 1.1.2.1/32
ip prefix-list R1_to_R2 seq 10 deny 1.1.5.1/32
ip prefix-list R1_to_R2 seq 15 permit 0.0.0.0/0 ge 32

#
#
R1(config)#do sh run | sec router rip
router rip
version 2
passive-interface Loopback1
network 1.0.0.0
network 150.10.0.0
distribute-list prefix R1_to_R2 in FastEthernet0/0
no auto-summary
#
R2(config-router)#do sh ip ro rip | in 1.1
1.0.0.0/32 is subnetted, 6 subnets
R
1.1.1.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R
1.1.3.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R
1.1.2.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R
1.1.5.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R
1.1.4.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R
1.1.6.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R2(config-router)#
R2(config-router)#do cle ip ro *
R2(config-router)#
R2(config-router)#do sh ip rou rip | in 1.1.
R
1.1.1.1 [120/1] via 150.10.1.1, 00:00:07, FastEthernet0/0
R
1.1.3.1 [120/1] via 150.10.1.1, 00:00:07, FastEthernet0/0
R
1.1.4.1 [120/1] via 150.10.1.1, 00:00:07, FastEthernet0/0
R
1.1.6.1 [120/1] via 150.10.1.1, 00:00:07, FastEthernet0/0
R
10.10.1.1 [120/1] via 150.10.1.1, 00:00:07, FastEthernet0/0

RIPv2 Filtering with Standard Access-Lists:OK

Topology:
R1 R2
R2 received updated 1.1.6.1/32 from R1.
R2(config-router)#do sh ip rou rip
1.0.0.0/32 is subnetted, 6 subnets
R
1.1.1.1 [120/1] via 150.10.1.1, 00:00:10,
R
1.1.3.1 [120/1] via 150.10.1.1, 00:00:10,
R
1.1.2.1 [120/1] via 150.10.1.1, 00:00:10,
R
1.1.5.1 [120/1] via 150.10.1.1, 00:00:10,

FastEthernet0/0
FastEthernet0/0
FastEthernet0/0
FastEthernet0/0

R
1.1.4.1 [120/1] via 150.10.1.1, 00:00:10, FastEthernet0/0
R
1.1.6.1 [120/1] via 150.10.1.1, 00:00:10, FastEthernet0/0
#
#
R2(config)#do sh run | se access-list
access-list 1 deny 1.1.6.1
access-list 1 permit any
R2(config)#
R2(config)#do sh run | be router rip
router rip
version 2
passive-interface Loopback2
network 2.0.0.0
network 33.0.0.0
network 150.10.0.0
network 150.20.0.0
network 150.50.0.0
distribute-list 1 in FastEthernet0/0
no auto-summary
R2(config-router)#
R2(config-router)#do sh ip rout rip | in 1.1
1.0.0.0/32 is subnetted, 5 subnets
R
1.1.1.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R
1.1.3.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R
1.1.2.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R
1.1.5.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R
1.1.4.1 [120/1] via 150.10.1.1, 00:00:01, FastEthernet0/0
R2(config-router)#
R2(config-router)#do sh access-list
Standard IP access list 1
10 deny 1.1.6.1 (6 matches)
20 permit any (42 matches)
#

RIPv2 Filtering with Extended Access-Lists:OK

If we try to use extended access-lists, the logic is a little bit different: the
"source" in the access-list is the ip of the advertising router, the
"destination" is the prefix to permit or deny.
Topology:
R1 R2

#
access-list 100 deny ip host 150.10.1.1 host 1.1.3.1
access-list 100 permit ip any any
#
router rip
version 2
network 2.0.0.0
network 150.10.0.0
network 150.20.0.0
network 150.50.0.0
distribute-list 100 in FastEthernet0/0
#
#
R2(config)#do sh access-list
Extended IP access list 100
10 deny ip host 150.10.1.1 host 1.1.3.1 (6 matches)
20 permit ip any any (7 matches)
#
#
R2(config)#do sh ip ro rip
1.0.0.0/32 is subnetted, 5 subnets
R
1.1.1.1 [120/1] via 150.10.1.1, 00:00:20, FastEthernet0/0
R
1.1.2.1 [120/1] via 150.10.1.1, 00:00:20, FastEthernet0/0
R
1.1.5.1 [120/1] via 150.10.1.1, 00:00:20, FastEthernet0/0
R
1.1.4.1 [120/1] via 150.10.1.1, 00:00:20, FastEthernet0/0
R
1.1.6.1 [120/1] via 150.10.1.1, 00:00:20, FastEthernet0/0
#
o

RIPv2 Filtering with Offset Lists:OK

Topology:
R2 R3
R2(config-router)#do sh run | se access-list
access-list 1 deny 1.1.1.1
access-list 1 deny 1.1.3.1
access-list 1 deny 1.1.2.1
access-list 1 deny 1.1.5.1
access-list 1 deny 1.1.4.1
access-list 1 permit 1.1.6.1
access-list 1 deny 66.66.66.0
access-list 1 deny 150.10.1.0
R2(config-router)# do sh run | sec router rip
router rip

version 2
offset-list 1 out 15 FastEthernet0/1
network 2.0.0.0
network 150.10.0.0
network 150.20.0.0
network 150.50.0.0
no auto-summary
R2(config-router)#
R3(config)#do deb ip rip
*Mar
1 00:15:49.867: RIP: received v2 update from 150.20.20.2 on
FastEthernet0/1
*Mar
1 00:15:49.867:
1.1.6.1/32 via 0.0.0.0 in 16 hops
(inaccessible)

RIPv2 Filtering with Administrative Distance:OK

Topology:
R1 R2
#
router rip
version 2
network 2.0.0.0
network 150.10.0.0
network 150.20.0.0
network 150.50.0.0
distance 200 150.10.1.1 0.0.0.0 1
#
R2(config-router)#do sh run | se access-list
access-list 1 deny 2.2.2.2
access-list 1 permit any
#
R2(config-router)#do sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 5 subnets

R
R
R
R
R

1.1.1.1 [200/1] via 150.10.1.1, 00:00:13, FastEthernet0/0


1.1.2.1 [200/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
1.1.5.1 [200/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
1.1.4.1 [200/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
1.1.6.1 [200/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
C
2.2.2.2 is directly connected, Loopback2
10.0.0.0/32 is subnetted, 1 subnets
C
150.10.1.0 is directly connected, FastEthernet0/0
R2(config-router)#
R2(config-router)#
R2(config-router)#do sh access-list
Standard IP access list 1
10 deny 2.2.2.2
20 permit any (48 matches)
#

RIPv2 Filtering with Per-Neighbor AD:OK

#
access-list 1 permit 1.1.1.1
access-list 1 permit 1.1.5.1
#
router rip
version 2
network 2.0.0.0
network 150.10.0.0
network 150.20.0.0
network 150.50.0.0
distance 250 150.10.1.1 0.0.0.0 1
#
R2(config)#do sh ip prot
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set


Sending updates every 30 seconds, next due in 24 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
FastEthernet0/0
2
2
RIP
FastEthernet0/1
2
2
FastEthernet1/1
2
2
Loopback2
2
2
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
2.0.0.0
150.10.0.0
150.20.0.0
150.50.0.0
Routing Information Sources:
Gateway
Distance
Last Update
150.10.1.1
250
00:00:01
Distance: (default is 120)
Address
Wild mask
Distance List
150.10.1.1
0.0.0.0
250 1

R2(config)#
R2(config)#do sh ip ro rip
1.0.0.0/32 is subnetted, 6 subnets
R
1.1.1.1 [250/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
R
1.1.3.1 [120/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
R
1.1.2.1 [120/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
R
1.1.5.1 [250/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
R
1.1.4.1 [120/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
R
1.1.6.1 [120/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
10.0.0.0/32 is subnetted, 1 subnets
R
10.10.1.1 [120/1] via 150.10.1.1, 00:00:13, FastEthernet0/0
R2(config)#

RIPv2 Default Routing

Topology:
R1 R2

R3

RIP has a built in feature in which allows it to advertise a default route to


its direct neighbors which will propagate throughout the entire RIP
routing domain. Utilizing this type of configuration can a company money
due to the man hours required to configure a static default route on each and
every router and/or switch in the network and that does not include general
router/switch maintenance.
Advertising a default route via RIP is done by a single command that
is executed in RIP router configuration mode. This command is
default-information originate
Wireshark_capituras\RIP_default-information_route_receveid from R1
do R3(r1-r2-r3).pcap
Configurations:
R1:
R1(config-router)#do sh run | sec router rip
router rip
version 2
network 1.0.0.0
network 99.0.0.0
default-information originate
no auto-summary
R1(config-router)#
R2(config-router)#do sh run | sec router rip
router rip
version 2
network 1.0.0.0
network 2.0.0.0
no auto-summary
#
R2(config-if)#do sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 1.1.2.1 to network 0.0.0.0

1.0.0.0/8 is variably subnetted, 4 subnets, 2 masks


C
1.1.1.0/24 is directly connected, FastEthernet0/0
C
1.1.2.0/24 is directly connected, FastEthernet1/0
C
1.1.3.0/24 is directly connected, FastEthernet0/1
R
1.10.10.10/32 [120/1] via 1.1.2.1, 00:00:03, FastEthernet1/0
[120/1] via 1.1.1.1, 00:00:08, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
C
2.2.2.2 is directly connected, Loopback2
R 3.0.0.0/8 [120/1] via 1.1.3.3, 00:00:01, FastEthernet0/1
R* 0.0.0.0/0 [120/1] via 1.1.2.1, 00:00:04, FastEthernet1/0
[120/1] via 1.1.1.1, 00:00:09, FastEthernet0/0
R3(config-router)#do sh run | sec router rip
router rip
version 2
network 1.0.0.0
network 3.0.0.0
no auto-summary
R3(config-router)#
R3(config-router)#
R3(config-router)#do sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 1.1.3.2 to network 0.0.0.0
1.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
R
1.1.1.0/24 [120/1] via 1.1.3.2, 00:00:23, FastEthernet0/1
R
1.1.2.0/24 [120/1] via 1.1.3.2, 00:00:23, FastEthernet0/1
C
1.1.3.0/24 is directly connected, FastEthernet0/1
R
1.10.10.10/32 [120/2] via 1.1.3.2, 00:00:23, FastEthernet0/1
2.0.0.0/32 is subnetted, 1 subnets
R
2.2.2.2 [120/1] via 1.1.3.2, 00:00:23, FastEthernet0/1
3.0.0.0/32 is subnetted, 1 subnets
C
3.3.3.3 is directly connected, Loopback3
99.0.0.0/32 is subnetted, 1 subnets
R
99.99.99.99 [120/2] via 1.1.3.2, 00:00:24, FastEthernet0/1
R* 0.0.0.0/0 [120/2] via 1.1.3.2, 00:00:24, FastEthernet0/1

RIPv2 Conditional Default Routing:OK

Ok same thing like in 3) but we will specify and exit interface where the
route-map is sent out. For me it was a little bit confusing at the beginning
because the route-map is used in a non-standard fashion in our case. We will
first need to configure a route map where we declare the interface where the
default route should be sent out. All other interfaces are denied then.
#
router rip
network 1.0.0.0
network 10.0.0.0
default-information originate route-map filter
no auto-summary
#
route-map filter permit 10
set interface FastEthernet0/0
#

RIPv2 Reliable Conditional Default Routing:OK

Well now the last thing is that we can add reliable information to our routemap. With the conditions we used in 5) we can only take care of conditions
that are brought to us by routing-protocols etc. With reliable here we want to
actively track some cases. To do this we use the IOS feature called IP SLA.
what I am going to do now is I will actively track the loopback of R2 (could be
of course any other ip address) with icmp echoes and will inject a
default route into the rip domain as long as R2s loopback is
available.
#
ip route 69.69.69.69 255.255.255.255 Null0 track 1
#
ip prefix-list ccie seq 10 permit 69.69.69.69/32
#
ip sla 1
icmp-echo 2.2.2.2 source-interface Loopback1
timeout 1000
frequency 2
#

ip sla schedule 1 life forever start-time now


#
track 1 rtr 1
#
route-map filter_reliable permit 10
match ip address prefix-list ccie
#
router rip
version 2
passive-interface Loopback1
network 1.0.0.0
network 10.0.0.0
default-information originate route-map filter_reliable
no auto-summary
#

RIPv2 Unicast Updates:OK

Topologia.
R1 R2
There is however another advantage to configuring RIP with static neighbor
relationships which is added security but there is one catch!!! By default
RIPv2 will send multicast updates out all interfaces specified within
the range of the network command. If you configure a static neighbor;
not only will that router send updates via unicast to that neighbor
out the respected link. It will also send multicast updates out the same link as
well. To prevent this from happening, you must utilize a feature called
Passive Interface.
A RIP Passive Interface in a nut shell prevents the RIP routing process from
sending multicast/broadcast updates out a specified interface. A RIP
Passive interface however does not block unicast updates. Keep in
mind a Passive Interface DOES NOT block multicast/broadcast updates
therefore the router would still process received RIP updates.
So with that in mind, its quite common in secure networks the passive
interface feature will be utilized on all interfaces and the neighbors will
statically be configured to prevent RIP route snooping via Wireshark.

Configurations:
R1(config-router)#do sh run | sec router rip
router rip
version 2
passive-interface Serial0/0
passive-interface Serial0/1
passive-interface Loopback1
network 1.0.0.0
network 10.0.0.0
network 20.0.0.0
neighbor 20.20.20.2
neighbor 10.10.10.2
no auto-summary
R2(config-router)#do sh run | se router rip
router rip
version 2
passive-interface Serial0/0
passive-interface Serial0/1
passive-interface Loopback2
network 2.0.0.0
network 10.0.0.0
network 20.0.0.0
neighbor 20.20.20.1
neighbor 10.10.10.1
no auto-summary

R1(config-router)#
*Mar 1 00:11:18.731: RIP: received v2 update from 10.10.10.2 on
Serial0/0
*Mar 1 00:11:18.735:
2.2.2.2/32 via 0.0.0.0 in 1 hops
*Mar 1 00:11:18.735:
20.20.20.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:11:18.735:
20.20.20.1/32 via 0.0.0.0 in 1 hops
*Mar 1 00:11:18.739: RIP: received v2 update from 20.20.20.2 on
Serial0/1
*Mar 1 00:11:18.739:
2.2.2.2/32 via 0.0.0.0 in 1 hops
*Mar 1 00:11:18.739:
10.10.10.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:11:18.743:
10.10.10.1/32 via 0.0.0.0 in 1 hops
R1(config-router)#
*Mar 1 00:11:37.587: RIP: sending v2 update to 10.10.10.2 via
Serial0/0 (10.10.10.1)

*Mar 1 00:11:37.587: RIP: build update entries


*Mar 1 00:11:37.587: 1.1.1.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:11:37.591: 20.20.20.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:11:37.591: 20.20.20.2/32 via 0.0.0.0, metric 1, tag 0
R1(config-router)#
*Mar 1 00:11:39.219: RIP: sending v2 update to 20.20.20.2 via
Serial0/1 (20.20.20.1)
*Mar 1 00:11:39.219: RIP: build update entries
*Mar 1 00:11:39.219: 1.1.1.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:11:39.223: 10.10.10.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:11:39.223: 10.10.10.2/32 via 0.0.0.0, metric 1, tag 0
o

RIPv2 Broadcast Updates:OK

R1(config-if)#
R1(config-if)#
*Mar
1 00:02:20.587: RIP: sending v2 update to 224.0.0.9 via
FastEthernet0/0 (150.10.1.1)
*Mar 1 00:02:20.591: RIP: build update entries
*Mar 1 00:02:20.591: 1.1.1.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:20.595: 1.1.2.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:20.599: 1.1.3.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:20.599: 1.1.4.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:20.603: 1.1.5.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:20.607: 1.1.6.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:20.611: 10.10.1.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:20.611: 66.66.66.0/24 via 0.0.0.0, metric 1, tag 0
R1(config-if)#
*Mar 1 00:02:26.831: RIP: received packet with MD5 authentication
*Mar
1 00:02:26.831: RIP: received v2 update from 150.10.1.2 on
FastEthernet0/0
*Mar 1 00:02:26.835:
2.0.0.0/8 via 0.0.0.0 in 1 hops
R1(config)#
R1(config)#interface fas 0/0
R1(config-if)#ip rip v2-broadcast
R1(config-if)#
*Mar 1 00:02:50.411: RIP: sending v2 update to 255.255.255.255 via
FastEthernet0/0 (150.10.1.1)
*Mar 1 00:02:50.415: RIP: build update entries
*Mar 1 00:02:50.415: 1.1.1.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:50.419: 1.1.2.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:50.419: 1.1.3.1/32 via 0.0.0.0, metric 1, tag 0

*Mar 1 00:02:50.419: 1.1.4.1/32 via 0.0.0.0, metric 1, tag 0


*Mar 1 00:02:50.419: 1.1.5.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:50.419: 1.1.6.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:50.419: 10.10.1.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:02:50.419: 66.66.66.0/24 via 0.0.0.0, metric 1, tag 0
R1(config-if)#
*Mar 1 00:02:53.535: RIP: received packet with MD5 authentication
*Mar
1 00:02:53.535: RIP: received v2 update from 150.10.1.2 on
FastEthernet0/0
*Mar 1 00:02:53.539:
2.0.0.0/8 via 0.0.0.0 in 1 hops
R1(config-if)#

RIPv2 Source Validation:OK

Use the no validate update-source interface command if the neighbor


is speaking to the router using an IP not on the local subnet (secondary
address is an example)
Topologia.
R1 R2
R1:
#
interface Serial0/0
ip address 11.11.11.1 255.255.255.0
encapsulation ppp
clock rate 2000000

end
#
R2:
#
interface Serial0/0
ip address 10.10.10.2 255.255.255.0
encapsulation ppp
clock rate 2000000
end
#
R1(config)#router rip
R1(config-router)#validate-update-source
*Mar 1 01:09:52.847: RIP: ignored v2 update from bad source 10.10.10.2 on
Serial0/0
#
R1(config-router)#do sh run | se router rip
router rip
version 2
validate-update-source
network 0.0.0.0
no auto-summary
R1(config-router)#
#

R1(config-router)# no validate-update-source
R1(config-router)#do sh run | se router rip
router rip
version 2
no validate-update-source
network 0.0.0.0
no auto-summary
R1(config-router)#
YOU must configure this feature in both directions!!!
LOGS
*Mar 1 01:11:17.463: RIP: received v2 update from 10.10.10.2 on
Serial0/0
*Mar 1 01:11:17.467:
2.2.2.2/32 via 0.0.0.0 in 1 hops
R1(config-router)#

*Mar
1 01:11:24.479: RIP: sending v2 update to 224.0.0.9 via
Serial0/0 (11.11.11.1)
*Mar 1 01:11:24.479: RIP: build update entries
*Mar 1 01:11:24.479: 1.1.1.1/32 via 0.0.0.0, metric 1, tag 0
#
R1(config-router)#do sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C
1.1.1.1 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 1 subnets
R
2.2.2.2 [120/1] via 10.10.10.2, 00:00:24
10.0.0.0/32 is subnetted, 1 subnets
C
10.10.10.2 is directly connected, Serial0/0
11.0.0.0/24 is subnetted, 1 subnets
C
11.11.11.0 is directly connected, Serial0/0
R1(config-router)#
==============================================
============================
R2(config-router)#do sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
R
1.1.1.1 [120/1] via 11.11.11.1, 00:00:26
2.0.0.0/32 is subnetted, 1 subnets
C
2.2.2.2 is directly connected, Loopback2

10.0.0.0/24 is subnetted, 1 subnets


C
10.10.10.0 is directly connected, Serial0/0
11.0.0.0/32 is subnetted, 1 subnets
C
11.11.11.1 is directly connected, Serial0/0

RIP_commands.pdf
Convergence in RIP Internetworks:
http://technet.microsoft.com/en-us/library/cc940478.aspx
https://sites.google.com/site/plan4ccie/config-template-vol1/01-inevol1-outline/lab04-rip
Things you must never forget about RIP.
1. The RIP process operates from UDP port 520.
2. The metric used by RIP is hop count, with 1 signifying a directly
connected network of the advertising router and 16 signifying an
unreachable network.

3. RIP sends periodic updates every 30 seconds minus a small random


variable that prevents the updates of neighboring routers from
becoming synchronized.
4. Default route can be advertised in the RIP domain several ways: e.g.
(1) static route to 0.0.0.0, with the redistribute static command, (2)
default-information originate command, and (3) ip default-network
command.
5. With RIP, default-information originate command advertises
a default route even if a default route does not exist in the
routing table. The route map referenced in this command
cannot use an extended access list; it can use a standard
access list.
6. With RIP, ip default-network command will work only if (1) the
network address is a classful network that is not directly connected,
and (2) this classful network is in the local routers IP routing table, via
any means.
7. ip default-network command will work only if (1) the network
specified in the command is a classful network, and (2) the router must
have a directly connected interface onto the specified classful network.
8. Unlike EIGRP the key numbers do not need to match for RIP
authentication.
9. Unlike EIGRP the neighbor command under RIP process does not
automatically suppress the sending of broadcast or multicast updates.
The additional passive-interface command is required to accomplish
this.
10.
In RIP, route feedback may occur when generating
summaries because RIP does not generate a route to Null0 like
EIGRP, OSPF, and BGP. Possible solutions are static route to
Null0, distribute-list inbound filtering.
11.Route feedback may also occur when generating a default route using
default-information originate as RIP does not need to have a default
route installed in the routing table. Possible solutions are static default
route to Null0, distribute-list inbound filtering of default route.
12.Supernet advertisement (advertising any network prefix less than its
classful major network) is not allowed in RIP route summarization (ip
summary-address rip ). Only one summary address can be
configured for each classful subnet.
13.
Extended ACLs when called as distribute-list in IGP have
a different meaning than in redistribution or as in BGP. In BGP

and redistribution the source field in the ACL represents the


network address, and the destination represents the subnet
mask. In IGP distribute-list the source field in the ACL
matches the update source of the route, and the destination
field represents the network address; e.g. access-list 100
deny ip host 155.1.0.3 host 155.1.7.0.
14.
The interface command ip rip triggered enables the
router to send triggered updates only when there is a topology
change. This command is only available on point-to-point serial
links and must be configured on both ends of the link before
taking affect.
15.validate-update-source does not validate source (if it is in the same
subnet) of ip unnumbered interfaces.
16.If we want to prevent the sending of RIP updates to a new router upon
joining in an existing RIP domain, we can configure either (1) RIP
authentication, or (2) unicast RIP updates on the existing RIP routers.
17.The IP-RIP Delay Start feature (ip rip initial-delay ...) is used
on Cisco routers to delay the initiation of RIPv2 neighbor sessions until
the network connectivity between the neighbor routers is fully
operational, thereby ensuring that the sequence number of the first
MD5 packet that the router sends to the non-Cisco neighbor router is 0.
18.If we have high-end router on one side and low-speed router on other
side, then we can use output-delay command on the high-end
router to increase the interpacket delay for RIP updates and we can
use input-queue command on the low-speed router to increase the
size of RIP input queue.
19.If an interface is configured with secondary IP addresses and split
horizon is enabled, updates might not be sourced by the secondary
address. One routing update is sourced per network number unless
split horizon is disabled.
20.If split horizon is enabled, neither automatic summary nor interface
summary addresses are advertised.

CCIE R&S v5 Advanced Technology Labs


EIGRP

Overview:
EIGRP is an enhanced version of IGRP developed by Cisco. Unlike IGRP and
RIP, EIGRP does not send out periodic route updates. EIGRP updates are sent
out only when the network topology changes. Key capabilities that distinguish
EIGRP from other routing protocols include fast convergence, support for
variable-length subnet mask, support for partial updates, and support for
multiple network layer protocols.
A router running EIGRP stores all the neighbor routing tables so that it can
quickly adapt to alternate routes. If no appropriate route exists, EIGRP queries
its neighbors to discover an alternate route. These queries propagate until an
alternate route is found. Its support for variable-length subnet masks permit
routes to be automatically summarized on a network number boundary. In
addition, EIGRP can be configured to summarize on any bit boundary at any
interface. EIGRP does not make periodic updates. Instead, it sends partial
updates only when the metric for a route changes. Propagation of partial
updates is automatically bounded so that only those routers that need the
information are updated. As a result of these two capabilities, EIGRP
consumes significantly less bandwidth than IGRP.
Neighbor discovery is the process that the ASA uses to dynamically learn of
other routers on directly attached networks. EIGRP routers send out multicast
hello packets to announce their presence on the network. When the ASA
receives a hello packet from a new neighbor, it sends its topology table to the
neighbor with an initialization bit set. When the neighbor receives the
topology update with the initialization bit set, the neighbor sends its topology
table back to the ASA.
The hello packets are sent out as multicast messages. No response is
expected to a hello message. The exception to this is for statically defined
neighbors. If you use the neighbor command to configure a neighbor, the
hello messages sent to that neighbor are sent as unicast messages. Routing
updates and acknowledgements are sent out as unicast messages.
Once this neighbor relationship is established, routing updates are not
exchanged unless there is a change in the network topology. The neighbor
relationship is maintained through the hello packets. Each hello packet
received from a neighbor contains a hold time. This is the time in which the
ASA can expect to receive a hello packet from that neighbor. If the ASA does
not receive a hello packet from that neighbor within the hold time advertised
by that neighbor, the ASA considers that neighbor to be unavailable.

The EIGRP protocol uses four key algorithm technologies, four key
technologies, including neighbor discover/recovery,
Reliable Transport Protocol (RTP), and the fourth one, DUAL being important
for route computations. DUAL saves all routes to a destination in the topology
table, not just the least-cost route. The least-cost route is inserted into the
routing table. The other routes remain in the topology table. If the main route
fails, another route is chosen from the feasible successors. A successor is a
neighboring router used for packet forwarding that has a least-cost path to a
destination. The feasibility calculation guarantees that the path is not part of
a routing loop.
If a feasible successor is not found in the topology table, a route
recomputation must occur. During route recomputation, DUAL queries the
EIGRP neighbors for a route, who in turn query their neighbors. Routers that
do not have a feasible successor for the route return an unreachable
message.
During route recomputation, DUAL marks the route as active. By default, the
ASA waits for three minutes to receive a response from its neighbors. If the
ASA does not receive a response from a neighbor, the route is marked as
stuck-in-active. All routes in the topology table that point to the unresponsive
neighbor as a feasibility successor are removed.

Keys for EIGRP that you MUST keeping in your mind:

EIGRP Updates, step-by-step:OK.

TIP:

http://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/configuration/guide/fipr_c/1c
feigrp.html#wp1012316
http://quizlet.com/4392357/ccie-eigrp-theory-flash-cards/

EIGRP Network Statement: OK

Configuraes bsicas do EIGRP.

EIGRP Auto-Summary: OK

Quando aplicado esse comando no processo EIGRP em questo, todas as


rotas iro sumarizar e anunciar classfull networks. Por exemplo, uma rede
declarada 10.1.1.0 com o auto-sumary essa rede ser anunciada como
10.0.0.0/8, isso pode causar alguns problemas em redes descontiguas:
192.10.1.0/172.16.10.0.

R1(config-router)#do ping 172.16.40.3


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.40.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1(config-router)#
R1(config-router)#no auto-summary
R1(config-router)#
*Mar
1 01:44:09.179: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1:
Neighbor 172.16.10.2 (FastEthernet0/0) is resync: summary
configured
R1(config-router)#
R1(config-router)#
R1(config-router)#do ping 172.16.40.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.40.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/63/80 ms
R1(config-router)#

EIGRP Multi-AF Mode : Teoria OK ( falta testar no Lab ):OK

TIP:
Somente possvel configurar um autonomo system dentro de cada
EIGRP named domain.
Quando se criado um novo EIGRP named domain , preciso
redistribuir caso tenha a necessidade de comunicao entre
instancias EIGRP Named;
No obrigatrio os nomes dos neighbors eigrp serem iguais,
porm, os autnomos system devem estar dentro do mesmo AS.
http://blog.boson.com/bid/105129/EIGRP-Named-Mode

EIGRP MD5 & SHA-256 Authentication:OK

EIGRP route authentication provides MD5 authentication of routing updates


from the EIGRP routing protocol. The MD5 keyed digest in each EIGRP packet
prevents the introduction of unauthorized or false routing messages from
unapproved sources.
Each key has its own key identifier (specified with the key number key chain
configuration command), which is stored locally. The combination of the key
identifier and the interface associated with the message uniquely identifies
the authentication algorithm and the MD5 authentication key in use.
You can configure multiple keys with specific lifetimes. Only one
authentication packet is sent, regardless of how many valid keys exist. The
software examines the key numbers in the order from lowest to highest, and
uses the first valid key that it encounters. Note that the device needs to know
the time to configure keys with lifetimes.
http://www.cisco.com/c/en/us/td/docs/iosxml/ios/iproute_eigrp/configuration/15-s/ire-15-s-book/ire-sha256.html

Topology for EIGRP named with MD5 and HCAM-SHA-256 bits


R1 R2
MD5 authentication:
Wireshark_capituras\EIGRP_MD5_.pcapng
About SHA ( Secure Hash Algorithm )
http://en.wikipedia.org/wiki/Secure_Hash_Algorithm

EIGRP named with SHA 256 bits authentications


Wireshark_capituras\(eigrp.tlv_type)_SHA-256
Named.pcapng

bits

with

EIGRP

http://labs.ine.com/workbook/view/rs-v5-workbook/task/5-4-eigrpmd5-sha-256-authentication-MjA4Nw%3D%3D

TIP:
EIGRP supports MD5 authentication in Classic (Autonomous System) Mode,
and both MD5 and SHA-256 in Multi-AF (Named) Mode. For MD5
authentication in both Classic and Named modes, the key chain is defined
globally. The key chain can contain multiple keys, but only the lowest active
key number will be exchanged in EIGRP packets. Note that the key ID must
match for authentication to occur, because this number is exchanged in the
hello packets. In Classic Mode, the authentication is applied at the link level,
whereas in Named Mode it is applied at the af-interface mode under the SAFI.

EIGRP Key Chain Rotation: Voltar!!!

EIGRP Unicast Updates:OK

Para formao do neighbors em rede broadcast necessrio a


configurao de neig esttico para full conectividade.
Segue exemplo no link abaixo:

http://hackingcisco.blogspot.com.br/2011/03/lab-60-eigrp-unicastcommunication.html

EIGRP Summarization:OK

Topology:
R1 R2

R1#sh ip rou eigrp


Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
D
10.10.0.0/21 is a summary, 00:19:18, Null0
130.10.0.0/24 is subnetted, 1 subnets
D
130.10.1.0 [90/30720] via 150.38.1.2, 00:04:28, FastEthernet0/0
[90/30720] via 9.9.9.2, 00:04:28, FastEthernet3/0
R1#
R1#sh run inter f0/0
Building configuration...
Current configuration : 218 bytes
!
interface FastEthernet0/0
ip address 150.38.1.1 255.255.255.0
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 ROLLOVER
ip summary-address eigrp 10 10.10.0.0 255.255.248.0
duplex full
end
R1#sh run inter f3/0
Building configuration...

Current configuration : 215 bytes


!

interface FastEthernet3/0
ip address 9.9.9.1 255.255.255.0
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 ROLLOVER
ip summary-address eigrp 10 10.10.0.0 255.255.248.0
duplex full
end
R2#sh ip ro eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D
10.10.0.0/21 [90/156160] via 150.38.1.1, 00:06:32,
FastEthernet0/0
[90/156160] via 9.9.9.1, 00:06:32,
FastEthernet3/0
D
10.10.10.0/24 [90/156160] via 150.38.1.1, 00:06:32, FastEthernet0/0
[90/156160] via 9.9.9.1, 00:06:32, FastEthernet3/0
90.0.0.0/32 is subnetted, 1 subnets
D
90.90.90.90 [90/156160] via 150.38.1.1, 00:06:32, FastEthernet0/0
[90/156160] via 9.9.9.1, 00:06:32, FastEthernet3/0
R2#

EIGRP Summarization with Default Routing:OK

Comportamento do EIGRP summary igual o a RIP; Sumarizamos em


um router ( Router A ) e este divulga uma rota default para todos os
elementos da rede que estiverem no mesmo dominio de AS.

Comando configurations:
interface FastEthernet0/0
ip address 150.38.1.1 255.255.255.0
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 ROLLOVER
ip summary-address eigrp 10 0.0.0.0 0.0.0.0
R1(config-if)#do sh ip ro eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
D*
D

0.0.0.0/0 is a summary, 00:03:07, Null0


130.10.0.0/24 is subnetted, 1 subnets
130.10.1.0 [90/30720] via 150.38.1.2, 00:11:52, FastEthernet0/0
[90/30720] via 9.9.9.2, 00:11:52, FastEthernet3/0

Log: R2 antes e depois de aplicado o commando summary com defatult


routing.
R2#
R2#sh ip rou eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

D
D
D
D
D
D

10.10.1.0/24 [90/156160] via 150.38.1.1, 00:00:04, FastEthernet0/0


10.10.2.1/32 [90/156160] via 150.38.1.1, 00:00:04, FastEthernet0/0
10.10.3.2/32 [90/156160] via 150.38.1.1, 00:00:04, FastEthernet0/0
10.10.4.2/32 [90/156160] via 150.38.1.1, 00:00:04, FastEthernet0/0
10.10.5.2/32 [90/156160] via 150.38.1.1, 00:00:04, FastEthernet0/0
10.10.10.0/24 [90/156160] via 150.38.1.1, 00:00:04, FastEthernet0/0
90.0.0.0/32 is subnetted, 1 subnets
D
90.90.90.90 [90/156160] via 150.38.1.1, 00:00:04, FastEthernet0/0
R2#
R2#
R2#
*Oct 24 14:46:18.151: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10:
Neighbor 150.38.1.1 (FastEthernet0/0) is resync: peer gracefulrestart
R2#
R2#sh ip rou eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 150.38.1.1 to network 0.0.0.0
D*
R2#

0.0.0.0/0 [90/30720] via 150.38.1.1, 00:00:05, FastEthernet0/0


[90/30720] via 9.9.9.1, 00:00:05, FastEthernet3/0

EIGRP Summarization with Leak Map:OK

TIP:
Route leaking is a technique which is used together with summarization. It is used in the
situations where we want to save memory by summarizing routes but still want some
routes to be preffered over others for some reasons. Leak map reffernces an access-list and
whatever network is permitted in the access-list will be leaked along summary route.

Configurations:
Topology:
R1R2R3
R1(config-if)#
R1(config-if)#do sh run | se access-list
access-list 1 permit 90.90.90.90
access-list 1 permit 10.10.2.1
access-list 1 permit 10.10.4.2
access-list 1 deny any
R1(config-if)#
R1(config-if)#do sh run | sec route-map
route-map filter permit 10
match ip address 1
set tag 69
R1(config-if)#do sh run inter f0/0
Building configuration...
Current configuration : 226 bytes
!
interface FastEthernet0/0
ip address 150.38.1.1 255.255.255.0
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 ROLLOVER
ip summary-address eigrp 10 0.0.0.0 0.0.0.0 leak-map filter
duplex full
end
R1(config-if)#do sh run inter f3/0
Building configuration...

Current configuration : 223 bytes


!
interface FastEthernet3/0
ip address 9.9.9.1 255.255.255.0
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 ROLLOVER
ip summary-address eigrp 10 0.0.0.0 0.0.0.0 leak-map filter
duplex full
end
#
R1(config-if)#do sh access-list
Standard IP access list 1
30 permit 90.90.90.90 (4 matches)
10 permit 10.10.2.1 (4 matches)
20 permit 10.10.4.2 (4 matches)
40 deny any (20 matches)
R1(config-if)#
#
After and before filter applied:
R2:
R2(config)#do sh ip ro ei
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 150.38.1.1 to network 0.0.0.0
D*

0.0.0.0/0 [90/30720] via 150.38.1.1, 00:00:25, FastEthernet0/0


[90/30720] via 9.9.9.1, 00:00:25, FastEthernet3/0
R2(config)#
R2(config)#
*Oct 25 09:52:58.259: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10:
Neighbor 150.38.1.1 (FastEthernet0/0) is resync: peer gracefulrestart
R2(config)#
*Oct 25 09:53:06.751: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10:
Neighbor 9.9.9.1 (FastEthernet3/0) is resync: peer graceful-restart

R2(config)#do sh ip ro ei
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 150.38.1.1 to network 0.0.0.0
D*

0.0.0.0/0 [90/30720] via 150.38.1.1, 00:02:35, FastEthernet0/0


[90/30720] via 9.9.9.1, 00:02:35, FastEthernet3/0
10.0.0.0/32 is subnetted, 2 subnets
D
10.10.2.1 [90/156160] via 150.38.1.1, 00:00:27, FastEthernet0/0
[90/156160] via 9.9.9.1, 00:00:27, FastEthernet3/0
D
10.10.4.2 [90/156160] via 150.38.1.1, 00:00:27, FastEthernet0/0
[90/156160] via 9.9.9.1, 00:00:27, FastEthernet3/0
90.0.0.0/32 is subnetted, 1 subnets
D
90.90.90.90 [90/156160] via 150.38.1.1, 00:00:27, FastEthernet0/0
[90/156160] via 9.9.9.1, 00:00:27, FastEthernet3/0
R2(config)#
R3:
R3(config)#
R3(config)#do sh ip rou eigr
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 130.10.1.2 to network 0.0.0.0
D*
D
D

0.0.0.0/0 [90/204800] via 130.10.1.2, 00:01:51, FastEthernet1/0


9.0.0.0/24 is subnetted, 1 subnets
9.9.9.0 [90/153600] via 130.10.1.2, 00:01:51, FastEthernet1/0
150.38.0.0/24 is subnetted, 1 subnets
150.38.1.0 [90/153600] via 130.10.1.2, 00:01:51, FastEthernet1/0

R3(config)#
R3(config)#
R3(config)#
R3(config)#do sh ip rou eigr
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 130.10.1.2 to network 0.0.0.0
D*

0.0.0.0/0 [90/204800] via 130.10.1.2, 00:03:57, FastEthernet1/0


9.0.0.0/24 is subnetted, 1 subnets
D
9.9.9.0 [90/153600] via 130.10.1.2, 00:03:57, FastEthernet1/0
10.0.0.0/32 is subnetted, 2 subnets
D
10.10.2.1 [90/2713600] via 130.10.1.2, 00:00:23, FastEthernet1/0
D
10.10.4.2 [90/2713600] via 130.10.1.2, 00:00:23, FastEthernet1/0
90.0.0.0/32 is subnetted, 1 subnets
D
90.90.90.90 [90/2713600] via 130.10.1.2, 00:00:23, FastEthernet1/0
150.38.0.0/24 is subnetted, 1 subnets
D
150.38.1.0 [90/153600] via 130.10.1.2, 00:03:57, FastEthernet1/0
R3(config)#

EIGRP Floating Summarization: NOK; Falta emular no lab IOS


12.2 e 15.2 no oferece a opo de distance no final de
comando para emular corretamente a topologia.

You can also use a floating summary route when configuring the ip
summary-address eigrp xx ( Distance administrative ) command. This
enhancement was introduced in Cisco IOS Release 12.2. The floating
summary route is created by applying a default route and administrative
distance at the interface level. The following scenarios illustrate the behavior
of this enhancement.

o
EIGRP Poisoned Floating Summarization: NOK; Falta emular no
lab IOS 12.2 e 15.2 no oferece a opo de distance no final de
comando para emular corretamente a topologia.

EIGRP Metric Weights:OK

Default K values are as follows:

K1 = K3 = 1

K2 = K4 = K5 = 0

K6 = 0

The EIGRP Wide Metrics feature also introduces K6 as an additional K value for future use.

You must applied this configurations on both side!!!!

Logs:
R2(config-router-af)#
*Oct 25 20:25:26.527: %DUAL-5-NBRCHANGE: EIGRP-IPv4
9.9.9.1 (Serial4/0) is down: K-value mismatch
*Oct 25 20:25:27.167: %DUAL-5-NBRCHANGE: EIGRP-IPv4
150.38.1.1 (FastEthernet0/0) is down: K-value mismatch
R2(config-router-af)#
*Oct 25 20:25:31.515: %DUAL-5-NBRCHANGE: EIGRP-IPv4
150.38.1.1 (FastEthernet0/0) is up: new adjacency
*Oct 25 20:25:31.523: %DUAL-5-NBRCHANGE: EIGRP-IPv4
9.9.9.1 (Serial4/0) is up: new adjacency

10: Neighbor
10: Neighbor

10: Neighbor
10: Neighbor

R1(config-router-af)#do sh ip eigrp nei


EIGRP-IPv4 VR(ccie) Address-Family Neighbors for AS(10)
H Address
Interface
Hold Uptime SRTT RTO Q Seq
(sec)
(ms)
Cnt Num
1 9.9.9.2
Se4/0
12 00:02:42 110 660 0 72
0 150.38.1.2
Fa0/0
12 00:02:42 109 654 0 73
R1(config-router-af)#
R1(config-router-af)#
R1(config-router-af)#do sh ip prot
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 10"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(ccie) Address-Family Protocol for AS(10)
Metric weight K1=1, K2=1, K3=1, K4=1, K5=1 K6=1
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 90.90.90.90
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 10
Total Redist Count: 1

Automatic Summarization: disabled


Maximum path: 4
Routing for Networks:
9.0.0.0
10.0.0.0
150.38.0.0
Routing Information Sources:
Gateway
Distance
Last Update
9.9.9.2
90
00:02:46
150.38.1.2
90
00:02:46
Distance: internal 90 external 170
#
R1(config-router-af)#do sh run | se router eigrp
router eigrp ccie
!
address-family ipv4 unicast autonomous-system 10
!
af-interface Serial4/0
authentication mode md5
authentication key-chain ROLLOVER
exit-af-interface
!
af-interface FastEthernet0/0
authentication mode md5
authentication key-chain ROLLOVER
exit-af-interface
!
topology base
exit-af-topology
network 9.0.0.0
network 10.0.0.0
network 150.38.0.0
metric weights 0 1 1 1 1 1 1
exit-address-family
#
Wireshark_capituras\(eigrp.par.k1)_0.pcapng

EIGRP Unequal Cost Load Balancing:OK

Podemos efetuar o balanceamento com custos desiguais com o


comando: variance x;
Topologia:
R1 R2
R1(config-router-af-topology)#do sh ip eigrp nei
EIGRP-IPv4 VR(ccie) Address-Family Neighbors for AS(10)
H Address
Interface
Hold Uptime SRTT RTO Q Seq
(sec)
(ms)
Cnt Num
1 192.168.2.2
Fa1/0
10 00:03:17 65 390 0 105
0 192.168.1.2
Fa0/0
10 00:03:18 67 402 0 103
R1(config-router-af-topology)#
R1(config-router-af-topology)#do sh run inter f 1/0
Building configuration...
Current configuration : 101 bytes
!
interface FastEthernet1/0
bandwidth 50000
ip address 192.168.2.1 255.255.255.0
duplex full
end
R1(config-router-af-topology)#do sh run inter f 0/0
Building configuration...
Current configuration : 84 bytes
!
interface FastEthernet0/0
bandwidth 100000
ip address 192.168.1.1 255.255.255.0
duplex full
end
R1(config-router-af-topology)#do sh ip ro eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is not set


20.0.0.0/32 is subnetted, 1 subnets
D
20.20.20.20 [90/103040] via 192.168.1.2, 00:01:58,
FastEthernet0/0
R1(config-router-af-topology)#
R1(config-router-af-topology)#
R1(config-router-af-topology)#
R1(config-router-af-topology)#variance 2
R1(config-router-af-topology)#
R1(config-router-af-topology)#do sh ip ro eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
20.0.0.0/32 is subnetted, 1 subnets
D
20.20.20.20 [90/154240] via 192.168.2.2, 00:00:02,
FastEthernet1/0
[90/103040] via 192.168.1.2, 00:00:02,
FastEthernet0/0
R1(config-router-af-topology)#
R1(config-router-af-topology)#do sh run | se router eigrp
router eigrp ccie
!
address-family ipv4 unicast autonomous-system 10
!
topology base
variance 2
exit-af-topology
network 10.0.0.0
network 192.168.1.0
network 192.168.2.0
exit-address-family
About traffic-share:

With the traffic-share command, if there are multiple minimum-cost paths


and traffic-share-min is configured, EIGRP will use equal-cost load
balancing. By default, the command is set to balanced, where traffic will be
distributed proportionally to the ratio of the metrics. For example, if variance
is set to 3 and traffic-share is set to balanced, the best route will transport
traffic three times that of the worst route.
About maximum-paths:
With the maximum-paths command, the router uses up to six paths to share traffic across; to
limit this number, use themaximum-paths command. The multiple paths that make up a singlehop transport to a common destination are called a load-sharing group. The default value is 4.

EIGRP Traffic Engineering with Metric:OK

Voc pode mudar as metricas com os Ks values para manipulao ou usar o


Delay nas interfaces para manipular os updates route.
o

EIGRP Convergence Timers:OK

Unlike OSPF, EIGRP hello and hold-time intervals do not need to match to
form
adjacencies. Just like OSPF for example, the locally configured Hello interval
defines the local rate interval for sending EIGRP hello packets but the value is
not
transmited in EIGRP Hello packets. Unlike OSPF for example, the locally
configured
Hold-Time interval defines for how long the remote router will wait for a EIGRP
packet before resetting the adjacency, thus the value is transmited in EIGRP
Hello
packets.
TIP:
The timers active-time command controls how long an EIGRP router will wait
for a
reply to a query message before considering the route Stuck In Active (SIA)
and
Declaring the neighbor from which a reply was not received as down. The
query and
reply process is used to discover alternate paths to a route for which
the successor
is lost.
If a reply had not come back from RX, RY would wait for the timers
active-time to expire. If this timer had expired, the route would have

been considered SIA, and the neighbor relationship to R8 would


have been reset.
o

EIGRP Stub Routing

A router that is configured as a stub with the eigrp stub command shares
connected and summary routing information with all neighbor routers by
default. Four optional keywords can be used with the eigrp stub command to
modify this behavior:

receive-only

connected

static

summary

This section provides configuration examples for all forms of the eigrp
stub command. The eigrp stub command can be modified with several
options, and these options can be used in any combination except for
the receive-only keyword. The receive-only keyword will restrict the
router from sharing any of its routes with any other router in that
EIGRP autonomous system, and the receive-only keyword will not
permit any other option to be specified because it prevents any type
of route from being sent. The three other optional keywords
(connected, static, and summary) can be used in any combination but cannot
be used with the receive-only keyword. If any of these three keywords is used
individually with the eigrp stub command, connected and summary routes
will not be sent automatically.
The connected keyword will permit the EIGRP Stub Routing feature to send
connected routes. If the connected routes are not covered by a network
statement, it may be necessary to redistribute connected routes with
the redistribute connected command under the EIGRP process. This option is
enabled by default.
The static keyword will permit the EIGRP Stub Routing feature to send static
routes. Without the configuration of this option, EIGRP will not send any static
routes, including internal static routes that normally would be automatically
redistributed. It will still be necessary to redistribute static routes with
the redistribute static command.

The summary keyword will permit the EIGRP Stub Routing feature to send
summary routes. Summary routes can be created manually with
the summary address command or automatically at a major network border
router with the auto-summary command enabled. This option is enabled by
default.

EIGRP Stub Routing with Leak Map

EIGRP Filtering with Passive Interface

EIGRP Filtering with Prefix-Lists

EIGRP Filtering with Standard Access-Lists

EIGRP Filtering with Extended Access-Lists

EIGRP Filtering with Offset Lists

EIGRP Filtering with Administrative Distance

EIGRP Filtering with Per Neighbor AD

EIGRP Filtering with Route Maps

EIGRP Bandwidth Pacing

EIGRP Default Metric

EIGRP Neighbor Logging

EIGRP Router-ID

EIGRP Maximum Hops

Things to remember.
The IP header of an EIGRP packet specifies protocol number 88.
To establish neighbor relationship, the neighbors must be in the same IP
subnet. While EIGRP supports secondary IP addresses and subnets, EIGRP
sources its messages always from the address in the primary subnet, so the
IP addresses of neighbors must be in the subnet of the primary subnets.
Routers will not form EIGRP neighbors over secondary networks.
Two sides must also match metric weights (K values) in order to form
EIGRP neighbor adjacency.
Unlike OSPF, the hello and hold time parameters do not need to match to
form EIGRP neighbor relationships.
By default, the hold time is three times the Hello interval; 180 seconds for
low-speed non-broadcast multiaccess (NBMA) networks and 15 seconds for all
other networks.
EIGRP auto-summarizes connected, internal routes across classful network
boundaries.
passive-interface command for an interface does not stop advertising of
that interface in the EIGRP updates.
Default route can be advertised in the EIGRP domain several ways:
e.g. (1) static route to 0.0.0.0, with the redistribute static
command, (2) ip summary-address 0.0.0.0 0.0.0.0 command,
and (3) ip default-network ... command.
Unlike RIP, for EIGRP to propagate the default route, the network specified by
the ip default-network command must be advertised into EIGRP.
While generating default route, "ip summary-address eigrp 100
0.0.0.0 0.0.0.0 250" should be used along with higher administrative
distance (floating route) if this router already has a default route in
its routing table leaned via any other means. Otherwise the default
route (to null interface) generated by this command, may black hole
the traffic.
leak-map option ("ip summary-address eigrp ... leak-map ...") is only
available under physical and virtual-template interfaces. Again, if the leakmap keyword is configured but the access-list does not exist or the route map
does not reference the access list, the summary address and all component
routes are sent.
leak-map option with eigrp stub ... command has the same functionality as
leak-map option with ip summary-address command.

Unlike RIP, EIGRP only needs neighbor command to send unicast


updates. passive-interface command should not be used along with it;
otherwise it will stop sending EIGRP hello packets.
passive interface command in the frame-relay physical interface does
not inherited by the subinterfaces. So configuring this command on the
frame-relay physical interface does not affect EIGRP process at all.
Unlike RIP, with EIGRP split horizon is enabled on all frame-relay multipoint
interfaces (physical or subinterface). The show ip interface command
doesnt verify split horizon for EIGRP, the only way to verify it, is by checking
running configuration.
In EIGRP authentication, key number must match along with key string on
both sides. If configured with multiple keys, EIGRP only sends the
lowest numbered valid key but accepts any valid key.
The administrative distance filtering technique only works for EIGRP internal
routes, doesnt work for EIGRP external routes. The distance of external
EIGRP cannot be changed on a per prefix basis.
The default-metric command does not affect in EIGRP-to-EIGRP
redistribution.
To change the EIGRP metric, its better to use delay, so it will not affect
other protocols (OSPF) dependent on bandwidth.
The ip bandwidth-percent ... command can have values greater than 100
percent if the bandwidth is configured (by the bandwidth interface
configuration command) artificially low due to policy reasons.
A route becomes active when no feasible successor exists in its topology
table. An active route becomes passive when a reply has been received from
every queried neighbor.
A route map may be configured with both the redistribute ... and the
distribute-list ... commands in the same routing process.
gateway option in distribute-list ... command is only available
with prefix-list, but not with ACL.
EIGRP does not automatically summarize external routes.
The router originating the external route inserts its EIGRP router-id in the
update. If an update is received back in with the router-id matching the local
router-id, the update is dropped.

CCIE R&S v5 Advanced Technology Labs OSPF

OSPF over Broadcast Media

OSPF over DMVPN

OSPF DR/BDR Election Manipulation

OSPF Network Point-to-Point

OSPF Network Point-to-Multipoint

OSPF Network Point-to-Multipoint Non-Broadcast

OSPF Network Loopback

OSPF Path Selection with Auto-Cost

OSPF Path Selection with Cost

OSPF Path Selection with Bandwidth

OSPF Path Selection with Per-Neighbor Cost

Discontiguous OSPF Areas with Virtual-Links

OSPF Path Selection with Non-Backbone Transit Areas

OSPF Path Selection with Virtual-Links

OSPF Demand Circuit

OSPF Flooding Reduction

OSPF Clear Text Authentication

OSPF MD5 Authentication

OSPF MD5 Authentication with Multiple Keys

OSPF SHA Authentication

OSPF Null Authentication

OSPF Internal Summarization

OSPF Path Selection with Summarization

OSPF External Summarization

OSPF Stub Areas

OSPF Totally Stubby Areas

OSPF Not-So-Stubby Areas

OSPF Not-So-Stubby Areas and Default Routing

OSPF Not-So-Totally-Stubby Areas

OSPF Stub Areas with Multiple Exit Points

OSPF NSSA Type-7 to Type-5 Translator Election

OSPF NSSA Redistribution Filtering

OSPF LSA Type-3 Filtering

OSPF Forwarding Address Suppression

OSPF Default Routing

OSPF Conditional Default Routing

OSPF Reliable Conditional Default Routing

OSPF Filtering with Distribute-Lists

OSPF Summarization and Discard Routes

OSPF Filtering with Administrative Distance

OSPF Filtering with Route-Maps

OSPF NSSA ABR External Prefix Filtering

OSPF Database Filtering

OSPF Stub Router Advertisement

OSPF Interface Timers

OSPF Global Timers

OSPF Resource Limiting

Miscellaneous OSPF Features

Things to remember:

The IP header of an OSPF packet specifies protocol number 89.

To establish OSPF neighbor adjacency, hello/dead timers, MTU (otherwise have to


use "ip ospf mtu-ignore") must match. Unique router-id is also required.
Routers in stub area can only be adjacent with the routers in stubs or totally stubby
area. Routers in NSSA can only be adjacent with the routers in NSSA or totally NSSA.
OSPF sees secondary networks as stub networks and cannot make adjacencies over
secondary addresses. OSPF will advertise a secondary network or subnet only if it is also
running on the primary network or subnet and OSPF routes of secondary addresses must
be in same area as the primary address to be advertised. To learn routes from a neighbor
connected to the secondary network, another routing protocol such as RIP should be
running and redistributed into OSPF. Another solution to this kind of problem is to create
dot1q subinterfaces.
The only time that OSPF will form adjacencies between neighbors that are not on the
same subnet is when the neighbors are connected through point-to-point links using "ip
unnumbered".
The primary interface and IP unnumbered interface will have OSPF enabled if a
network statement matches the IP address of the primary interface.
An OSPF external route cannot use another OSPF external route as its next hop.
Inside an area, OSPF uses Link State logic, but between areas OSPF acts much like a
Distance Vector (DV) protocol in some regard. For example, the advertisement of a Type
3 LSA from one area to another hides the topology in the original area from the second
area, just listing a destination subnet, metric (cost), and the ABR through which the
subnet can be reachedall DV concepts.
Only broadcast and non-broadcast network elect DR/BDR based on priority or routerid (in case of a tie in the priority).
In non-broadcast network, DR/BDR must have layer 2 connectivity to all other
routers in the same area.
With OSPF network types broadcast and non-broadcast, next hop values are not
modified when updates are transmitted across an NBMA media. Both point-to-multipoint
and point-to-multipoint non-broadcast network type update the next-hop value of routes
learned on partially meshed networks to the directly connected neighbor, and advertise
the network as a set of endpoints instead of a transit network.
OSPF network point-to-point is the default option for point-to-point interfaces such as
HDLC, PPP, or point-to-point NBMA subinterfaces.
As only broadcast and non-broadcast network type elects DR/BDR, they are
compatible with each other, but they are not compatible with any other network types.
OSPF cost can be modified using (i) interface "bandwidth ..." command, (ii) interface
"ip ospf cost ..." command, (iii) process "auto-cost reference-bandwidth ..." command, or
(iv) "neighbor ... cost ..." command on point-to-multipoint non-broadcast network.
Only OSPF point-to-multipoint and point-to-multipoint non-broadcast network types
support OSPF cost value on a per neighbor basis. On point-to-multipoint broadcast
networks, if the "neighbor..." command is used, a cost to that neighbor must be specified.
But on point-to-multipoint non-broadcast networks, the "neighbor ..." command must be
used to identify neighbors, assigning a cost to a neighbor is optional.
The internal OSPF routes can only be summarized on ABRs whereas the external
(redistributed) routes can only be summarized on ASBRs.

"area default-cost ..." command is used to specify a cost for the default summary
route (default cost 1) that is sent into a stub area or NSSA.
In NSSA, ABR with the highest router-id does the LSA 7 to 5 conversion.
In NSSA, default-information originate command cannot be used, since it
generates Type-5 LSA, which is prohibited in NSSA area.
NSSA ASBR can generate a default only when it has a default route in its routing
table whereas NSSA ABR can generate a default route with or without a default route in
its own routing table.
Virtual links are not allowed in the stubby area or NSSA. In this case OSPF can be
tunneled over a stub area using GRE tunnel (tunnel must be connected to area 0).
If the authentication is wrong on the virtual-link, the virtual-link interface will not go
down immediately. As the virtual-link does not support periodic hellos, clear ip ospf
process command should be issued if the authentication is enabled on the virtual link.
The virtual link will not come up if the only interface to reach the other end of the
virtual link has a cost that is maximized (65535).
For BGP to redistribute routes into OSPF, the router-id must be identical, in OSPF
and in BGP.
OSPF filtering using "distribute-list ...", "route-map ..." (match route-type, match ip
route-source, match ip next-hop), and "distance ..." commands can only block route from
entering into local RIB, but cannot stop LSAs propagation into the OSPF database.
OSPF filtering using "area ... filter-list prefix ...", "area ... range ... not-adv",
summary-address not-adv, ip ospf database-filter all out, or neighbor
database-filter all out commands can filter LSAs from OSPF database.
If the area range and "area ... filter-list prefix ... out" both commands are
configured for an area, then type 3 LSAs that correspond to the area range are sent to all
other areas, only if at least one prefix in the area range matches an entry in the prefix list.
OSPF defaults to cost 20 when redistributing from an IGP, and 1 when redistributing
from BGP.
neighbor database-filter all out only works on point-to-multipoint network
types.
If distribute-list out command is configured on an ASBR, then the ASBR generates
Type 5 external LSAs only for those networks that are explicitly permitted in the
distribute list.
OSPF demand circuit sets do not age flag on all LSAs learned and will only send
updates when there is a change in the OSPF topology. The command must be configured
in a point-to-point link and is needed only on one side. If the router is part of a point-tomultipoint topology, only the multipoint end must be configured with this command.
The main difference between flooding reduction ("ip ospf flood-reduction") and
demand circuits ("ip ospf demand-circuit") is that former suppresses only periodic LSA
refreshes; it does not suppress periodic hello packets. Thus, the flooding reduction feature
does not impair the detection of a neighbor router going down.
OSPF stub router (max-metric router-lsa) advertises all non self-originated
routes/LSAs with maximum metric.
When "redistribute maximum-prefix ..." command is configured, the redistribution
limit does not apply to default routes or prefixes that are generated as a result of Type-7
to Type-5 translation.

CCIE R&S v5 Advanced Technology Labs Redistribution

Redistribution Case 1

Redistribution Case 2

Redistribution Case 3

CCIE R&S v5 Advanced Technology Labs -

BGP

Establishing iBGP Peerings

Establishing eBGP Peerings

BGP Update Source Modification

Multihop EBGP Peerings

Neighbor Disable-Connected-Check

Authenticating BGP Peerings

iBGP Route Reflection

Large-Scale iBGP Route Reflection with Clusters

iBGP Confederation

BGP Next-Hop Processing - Next-Hop-Self

BGP Next-Hop Processing - Manual Modification

iBGP Synchronization

BGP over GRE

BGP Redistribute Internal

BGP Peer Groups

BGP Network Statement

BGP Auto-Summary

BGP Bestpath Selection - Weight

BGP Bestpath Selection - Local Preference

BGP Bestpath Selection - AS-Path Prepending

BGP Bestpath Selection - Origin Code

BGP Bestpath Selection - MED

BGP Bestpath Selection - Always Compare MED

BGP Bestpath Selection - AS-Path Ignore

BGP Bestpath Selection - Router-IDs

BGP Bestpath Selection - DMZ Link Bandwidth

BGP Bestpath Selection - Maximum AS Limit

BGP Backdoor

BGP Aggregation

BGP Aggregation - Summary Only

BGP Aggregation - Suppress Map

BGP Aggregation - Unsuppress Map

BGP Aggregation - AS-Set

BGP Aggregation - Attribute-Map

BGP Aggregation - Advertise Map

BGP Communities

BGP Communities - No-Advertise

BGP Communities - No-Export

BGP Communities - Local-AS

BGP Communities - Deleting

BGP Conditional Advertisement

BGP Conditional Route Injection

BGP Filtering with Prefix-Lists

BGP Filtering with Standard Access-Lists

BGP Filtering with Extended Access-Lists

BGP Regular Expressions

BGP Filtering with Maximum Prefix

BGP Default Routing

BGP Local AS

BGP Local AS Replace-AS/Dual-AS

BGP Remove Private AS

BGP Dampening

BGP Dampening with Route-Map

BGP Timers Tuning

BGP Fast Fallover

BGP Outbound Route Filtering

BGP Soft Reconfiguration

BGP Next-Hop Trigger

BGP TTL Security

BGP AllowAS in

CCIE R&S v5 Advanced Technology Labs MPLS

VRF Lite

MPLS LDP

MPLS Label Filtering

MP-BGP VPNv4

MP-BGP Prefix Filtering

PE-CE Routing with RIP

PE-CE Routing with OSPF

OSPF Sham-Link

PE-CE Routing with EIGRP

EIGRP Site-of-Origin

PE-CE Routing with BGP

BGP SoO Attribute

Internet Access

MPLS VPN Performance Tuning

CCIE R&S v5 Advanced Technology Labs IPSec VPN

IPsec VPNs with Crypto Maps

GRE over IPsec with Crypto Maps

GRE over IPsec with Crypto Profiles

IPsec Virtual Tunnel Interfaces (VTIs)

DMVPN without IPsec

DMVPN with IPsec

DMVPN Phase 1 with EIGRP

DMVPN Phase 1 with OSPF

DMVPN Phase 2 with EIGRP

CCIE R&S v5 Advanced Technology Labs Multicast

PIM Dense Mode

Multicast RPF Failure

PIM Sparse Mode

PIM Sparse-Dense Mode

PIM Assert

PIM Accept RP

PIM DR Election

PIM Accept Register

Multicast Tunneling

Auto-RP

Auto-RP - Multiple Candidate RPs

Auto-RP - Filtering Candidate RPs

Auto-RP Listener

Auto-RP and RP/MA Placement

Filtering Auto-RP Messages

Multicast Boundary

PIM Bootstrap Router

BSR - Multiple RP Candidates

Filtering BSR Messages

Stub Multicast Routing & IGMP Helper

IGMP Filtering

IGMP Timers

Multicast Helper Map

Bidirectional PIM

Source Specific Multicast

Multicast BGP Extension

MSDP

Anycast RP

Catalyst IGMP Snooping

Catalyst Multicast VLAN Registration

Catalyst IGMP Profiles

CCIE R&S v5 Advanced Technology Labs IPv6

IPv6 Link-Local Addressing

IPv6 Unique Local Addressing

IPv6 Global Aggregatable Addressing

IPv6 EUI-64 Addressing

IPv6 Auto-Configuration

RIPng

RIPng over NBMA

RIPng Summarization

RIPng Prefix Filtering

RIPng Metric Manipulation

RIPng Default Routing

EIGRPv6

EIGRPv6 Summarization

EIGRPv6 Prefix Filtering

EIGRPv6 Metric Manipulation

EIGRPv6 Default Routing

OSPFv3

OSPFv3 over NBMA

OSPFv3 Virtual Links

OSPFv3 Summarization

IPv6 Redistribution

IPv6 Filtering

IPv6 MP-BGP

IPv6 PIM and MLD

IPv6 PIM BSR

IPv6 Embedded RP

IPv6 SSM

IPv6 Tunneling

Automatic 6to4 Tunneling

ISATAP Tunneling


CCIE R&S v5 Advanced Technology Labs QoS

MQC Classification and Marking

MQC Bandwidth Reservations and CBWFQ

MQC Bandwidth Percent

MQC LLQ and Remaining Bandwidth Reservations

MQC WRED

MQC Dynamic Flows and WRED

MQC WRED with ECN

MQC Class-Based Generic Traffic Shaping

MQC Class-Based GTS and CBWFQ

MQC Single-Rate Three-Color Policer

MQC Hierarchical Policers

MQC Two-Rate Three-Color Policer

MQC Percent-Based Policing

QoS Pre-Classify

Advanced HTTP Classification with NBAR

CCIE R&S v5 Advanced Technology Labs Security

AAA Authentication Lists

AAA Exec Authorization

AAA Local Command Authorization

Traffic Filtering Using Standard Access-Lists

Traffic Filtering Using Extended Access-Lists

Filtering Fragmented Packets

Filtering Traffic with Time-Based Access Lists

Traffic Filtering with Policy-Based Routing

Preventing Packet Spoofing with uRPF

Using NBAR for Content-Based Matching

Packet Logging with Access-Lists

VLAN Filtering for IP Traffic

VLAN Filtering for Non-IP Traffic

Port Security

HSRP and Port Security

DHCP Snooping

DHCP Snooping and the Information Option

Dynamic ARP Inspection

IP Source Guard

Using Catalyst Ingress Access-Lists

Controlling Terminal Line Access

IOS Login Enhancements

Role-Based CLI

Controlling the ICMP Messages Rate

Control Plane Policing

IOS ACL Selective IP Option Drop

BGP Generic TTL Security Mechanism

S-ar putea să vă placă și