Documente Academic
Documente Profesional
Documente Cultură
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.
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
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.
o
VTP Domain / Transparent/ VTP Password / VTP Pruning /
Prune-Eligible List
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.
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.
PDF:
VTP_configurations.pdf
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 )
src-ipSource IP addresses
dst-ipDestination IP addresses
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
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.
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 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 UplinkFast: OK
STP BackboneFast:OK
Indirect failures should start recalculating immediately!
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.
( Cisco-
Loop Guard cannot be enabled on a switch that also has Root Guard
enabled
Loop
Loop
Loop
Loop
Loop
Guard
Guard
Guard
Guard
Guard
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.
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.
Unlike other spanning tree protocols, in which all the spanning tree instances are independent; MST
establishes and maintains IST, CIST, and CST spanning trees:
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.
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 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
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.
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 Terminology
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.
Monitor port-A monitor port is also a destination SPAN port in Catalyst 2900XL/3500XL/2950
terminology.
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
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
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-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
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.
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.
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.
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.
PPPoE
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.
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.
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 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
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
!
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
Wireshark_capituras\(IP_GRE_OSPF).pcap
Wireshark_capituras\(IP_GRE_EIGR).pcap
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 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:
Configurations:
ODR.pdf
Packet capture:
Wireshark_capituras\(cdp.tlv.type) or (text)_ODR.pcap
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
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:
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)#
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
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
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
Wireshark_capituras\RIP_Summary address_1.1.2.0-21.pcap
o
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
*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
#
#
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
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)
#
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
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)
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
#
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
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)#
Topology:
R1 R2
R3
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
#
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
#
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)
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
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
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.
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.
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 Auto-Summary: 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
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.
http://hackingcisco.blogspot.com.br/2011/03/lab-60-eigrp-unicastcommunication.html
EIGRP Summarization:OK
Topology:
R1 R2
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#
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
D
D
D
D
D
D
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...
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*
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*
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.
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.
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
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
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 Router-ID
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.
Things to remember:
"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.
Redistribution Case 1
Redistribution Case 2
Redistribution Case 3
BGP
Neighbor Disable-Connected-Check
iBGP Confederation
iBGP Synchronization
BGP Auto-Summary
BGP Backdoor
BGP Aggregation
BGP Communities
BGP Local AS
BGP Dampening
BGP AllowAS in
VRF Lite
MPLS LDP
MP-BGP VPNv4
OSPF Sham-Link
EIGRP Site-of-Origin
Internet Access
PIM Assert
PIM Accept RP
PIM DR Election
Multicast Tunneling
Auto-RP
Auto-RP Listener
Multicast Boundary
IGMP Filtering
IGMP Timers
Bidirectional PIM
MSDP
Anycast RP
IPv6 Auto-Configuration
RIPng
RIPng Summarization
EIGRPv6
EIGRPv6 Summarization
OSPFv3
OSPFv3 Summarization
IPv6 Redistribution
IPv6 Filtering
IPv6 MP-BGP
IPv6 Embedded RP
IPv6 SSM
IPv6 Tunneling
ISATAP Tunneling
CCIE R&S v5 Advanced Technology Labs QoS
MQC WRED
QoS Pre-Classify
Port Security
DHCP Snooping
IP Source Guard
Role-Based CLI