Terminal Line Settings

IOS supports multiple timeout settings for terminal sessions, which can be divided

as follows. Absolute limits the maximum amount of time the user can spend on the

line. Exec limits the time an exec shell can be idle. Session is the maximum amount

of time a session opened from terminal (such as telnet to other router) can be idle. A

refuse message is displayed when someone tries to connect to a line already in use.

The vacant message is displayed when the current line is idle (not in use—no exec

shell started).

The transport input/output option specifies which protocols can be used to connect

to/from the terminal line. The preferred transport protocol is used when no session

protocol is specified at exec prompt and a station name is typed. By default, the

preferred transport is telnet, which is why the router tries to telnet when a command

is mistyped. The lock feature allows a user to lock the current terminal session and

require a password to unlock it.

When a user is telnetted into R3 and mistypes a command in exec mode,

R3 should not try to open a telnet session to the command as if it is a

hostname.

Configure VTY line 0 to listen for telnet at port 3001. - "line vty 0

                                                                                           rotary 1"

When the virtual terminal line is busy, issue the output Sorry, the line is

already in use to the connecting user.-"refuse-message # Sorry, the line is already in use #"

Exec sessions on a VTY line should timeout after 2 minutes of inactivity; - "exec-timeout 2 0"

 a user should not be able to hold the line busy for more than 5 minutes.-"absolute-timeout 5"

The terminal length should be no more than 20 lines.-"length 20"

IP netmasks should be displayed using hex numbers.-"ip netmask-format hexadecimal"

Allow a user to lock VTY terminal lines.- "lockable"

Sessions initiated from a VTY line should timeout in 1 minute.-- "session-timeout 1"

When the console line is idle, the user should see the output Welcome to IOS.

Allow no more than one session to be initiated from the console line

line console 0

session-limit 1

vacant-message # Welcome to IOS #

The netmask format can be verified as shown below.

R3#telnet 150.1.3.3

Trying 150.1.3.3 ... Open

!

!R3#show interface GigabitEthernet1.37

Serial1/0 is up, line protocol is up

Hardware is CD2430 in sync mode Internet address is 155.1.0.3 0xFFFFFF00

MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation FRAME-RELAY, loopback not set

Rotary groups allow bundling multiple lines into a pool and to give the option to

access the pool using the dedicated TCP port number 3000+N, where N is the

rotary group number. Those special port numbers can also be used as “backdoors”

for telnet access. Note that the refuse message is displayed when a user attempts

to connect to the busy line

BGP Route Reflection

iBGP Route Reflection:
=====================

A route reflector can have three types of peers: EBGP peers, client peers, and nonclient
peers. EBGP peers are neighbors in a different AS number, including peers in
different Sub-ASs in confederation. Client peers are iBGP neighbors that have the
route-reflector-client statement configured. Non-client peers are normal iBGP
peers that do not have the route-reflector-client statement configured. Routing
advertisements sent from the route reflector must conform to the following three
rules:
1. Routes learned from EBGP peers can be sent to other EBGP peers, clients, and nonclients.
2. Routes learned from client peers can be sent to EBGP peers, other client peers, and
non-clients.
3. Routes learned from non-client peers can be sent to EBGP peers, and client peers,
but not other non-clients.
In the simplest of route-reflection designs, a central peering point is chosen for

OSPF

OSPF over Broadcast Media:
==========================

router ospf 1
network 155.1.67.0 0.0.0.255 area 67

interface GigabitEthernet1.79
ip ospf 1 area 79

This task illustrates two different ways to enable the OSPF process. These include
the legacy network statement under the OSPF process and the interface-level
command ip ospf [process-id] area [area-id] . Both accomplish the same thing with
one minor exception. If an interface is IP unnumbered, and there is a network
statement that matches the IP address of the primary interface, both the primary
interface and the unnumbered interface will have OSPF enabled on them in the
designated area. Additionally, when enabled at the interface level, by default OSPF
will inject both primary and secondary subnets of the interface in the OSPF
database and advertise it to its neighbors. If you want to suppress the secondary
prefixes, use the ip ospf [process-id] area [area-id] secondaries none command.
The network statement in OSPF, just like the network statement under the EIGRP
process, is not used to originate a network advertisement. Instead it simply enables
the OSPF process on the interface. If multiple network statements overlap the same
interface, the most specific match based on the wildcard mask wins.

OSPF over DMVPN:
================

The default OSPF network types on the DMVPN interface (which is an mGRE
interface) is Point-to-Point,

The Non-Broadcast network type means that there will be a DR/BDR election, and
that hellos are exchanged as unicast. To unicast OSPF hellos, the neighbor
statement must be configured under the OSPF process of the DR. When the
DROTHERs and/or BDR hear the unicast hellos from the DR, they will automatically
respond back with their own unicast hellos. This implies that the neighbor statement
can be configured everywhere, but is only required on the DR. As within the DMVPN
cloud, OSPF packets are only between hub and spokes (not between spokes); R5
needs to be the DR. When R5 is configured with the neighbor statement, the
show ip ospf neighbor

OSPF Network Point-to-Point
========================
The Default OSPF network on Ethernet interfaces is Broadcast. OSPF network
point-to-point is the default option for point-to-point interfaces such as HDLC, PPP,
or point-to-point GRE tunnels. It uses multicast hellos, does not use the DR/BDR
election, and only supports the adjacency of exactly two neighbors on a segment.
No special design considerations need be accounted for with point-to-point OSPF
interfaces.

OSPF Network Point-to-Multipoint:
================================

√OSPF network type point-to-multipoint is specifically designed to solve reachability
problems in partially meshed NBMA network designs. Like network type point-topoint,
it sends hellos as multicasts and does not support the DR/BDR election.
Unlike point-to-point, however, multiple adjacencies on a single interface are
supported. When adjacency is established, the show ip ospf neighbor output
indicates that there is no DR or BDR for the segment with the null output in the State
field:

R5#show ip ospf neighbor tunnel0
Neighbor ID Pri State Dead Time Address Interface
150.1.4.4 0 FULL/ -
00:01:41 155.1.0.4 Tunnel0 150.1.3.3 0 FULL/ -
00:01:36 155.1.0.3 Tunnel0 150.1.2.2 0 FULL/ -
00:01:34 155.1.0.2 Tunnel0 150.1.1.1 0 FULL/ -
00:01:56 155.1.0.1 Tunnel0

For all routes that are learned from the hub of the DMVPN network, the next-hop
value has been updated to the interface IP address of the hub. With the broadcast
network type, the DR does not update the next-hop. The result of this is that when
route recursion is performed for traffic that must be routed between the spokes,
NHRP resolution needs to be performed for the hub, not for the spoke (hub NHRP
entry is statically configured on all spokes)

OSPF Network Point-to-Multipoint Non-Broadcast:
==============================================

OSPF network type point-to-multipoint non-broadcast is essentially the same as
network type point-to-multipoint, with one exception: Point-to-multipoint network type
uses multicast hellos, whereas point-to-multipoint non-broadcast uses unicast
hellos. Additionally, in non-broadcast mode, you can configure per-neighbor OSPF
cost using the command neighbor <IP_ADDRESS> cost <value> , which is helpful in huband-
spoke topology, allowing the hub to use different costs per spoke, although all
spokes are attached to the same interface from the hub perspective. Both do not
support the DR/BDR election, automatically 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. The
show ip ospf neighbor output is identical between the two network types. In this
case, we can see that the spokes are adjacent with R5, the hub, and the hub is
adjacent with the spokes. The null field under the State field indicates that no
DR/BDR election has occurred.


OSPF Network Loopback:
=====================
OSPF network type Loopback is a special case that is used for Loopback and
looped-back interfaces. Similar to point-to-multipoint, an interface running network
type Loopback is advertised as a stub endpoint instead of a transit subnet. The
result of this network type that we see in our configuration is that when the
Loopback160 interfaces of these devices are advertised into OSPF, they appear in
the routing table as /32 host routes instead of the actual subnet mask of /24.
Because network type for Loopback170 interfaces has been changed, these are
correctly advertised with their subnet mask

OSPF Path Selection with Auto-Cost:
================================

router ospf 1
auto-cost reference-bandwidth 30000

Technically, OSPF auto-cost reference-bandwidth does not need to match for
neighbors to form an adjacency. However, if different neighbors throughout
the topology calculate SPF based on conflicting cost calculations, loops can
occur. For this reason, it is always recommended to set the auto-cost value
consistently throughout the entire OSPF domain


Interface Cost = Reference Bandwidth / Interface Bandwidth

Discontiguous OSPF Areas with Virtual-Links
=============================
 area 1
area0 R1---R4---R6 area 3

R1:
router ospf 1
area 1 virtual-link 150.1.6.6
R6:
router ospf 1
area 1 virtual-link 150.1.1.1


OSPF Demand Circuit:
==================
interface GigabitEthernet1.79
ip ospf demand-circuit

Per RFC 1793, Extending OSPF to Support Demand Circuits, “OSPF Hellos and the
refresh of OSPF routing information are suppressed on demand circuits, allowing
the underlying data-link connections to be closed when not carrying application
traffic.” This feature allows low-speed and pay-per-use links, such as analog dial
and ISDN, to run OSPF without the need for periodic hellos and LSA flooding.
Periodic hellos are only suppressed for point-to-point and point-to-multipoint OSPF
network types. This feature is enabled with the interface-level command ip ospf
demand-circuit and is negotiated as part of the neighbor adjacency establishment,
thus only one OSPF router on the segment requires that the feature be enabled. If
routers on the segment do not support it, it will just ignore the option in the HELLO
packet, but OSPF neighbors will still be established. Note the difference before and
after the feature is enabled, for example on R7.

Clear Text Authentication:
========================
interface GigabitEthernet1.37
ip ospf authentication
ip ospf authentication-key CLEARKEY

OSPFv2 supports three types of authentication as defined in RFC 2328: type 0, or
null authentication (no authentication), type 1, or clear text authentication, and type
2, or Keyed-MD5 authentication. As we'll see in following labs, type 2 also support
HMAC-SHA authentication. The type of authentication can be configured at the
interface level with the ip ospf authentication command or at the process level with
the area [id] authentication command. The only difference between these
commands is whether authentication is enabled on all interfaces in the area at the
same time or on a per-link basis. In either case, the password must still be
configured at the interface level with the ip ospf authentication-key or ip ospf
message-digest-key commands.

A failure in authentication can occur for two reasons: a mismatch in
authentication type or a mismatch involving the authentication key. An
authentication type mismatch occurs when one neighbor is configured with
clear text while the other is running MD5, or one is running MD5 and the
other is running null, etc. A key mismatch is simply when the routers are
using different passwords. Failure in authentication type can be verified as
follows:
R9#debug ip ospf adj
OSPF adjacency debugging is on
!R9#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.R9(config)#interface gigabitEthernet1.79
R9(config-subif)#ip ospf authentication message-digest
!
! OSPF-1 ADJ Gi1.79: Rcv pkt from 155.1.79.7 :
Mismatched Authentication type. Input packet specified type 1, we use type 2
OSPF-1 ADJ Gi1.79: Rcv pkt from 155.1.79.7 :
Mismatched Authentication type. Input packet specified type 1, we use type 2

OSPF MD5 Authentication:
=====================

router ospf 1
area 3 authentication message-digest
!
interface GigabitEthernet1.58
ip ospf message-digest-key 1 md5 MD5KEY

Remember that a virtual-link is an interface in area 0. This means that if the
area 0 authentication [message-digest] command is enabled, authentication is
also enabled on the virtual-link. If MD5 authentication is enabled on the
virtual-link with the area 0 authentication message-digest command, the
password must still be assigned on the virtual-link interface itself with the
area <NR> virtual-link <RID> message-digest-key <NR> md5 <STRING> command.
Alternatively, authentication can be enabled at the virtual-link interface level
with the area <NR> virtual-link <RID> authentication message-digest command,
and the key is applied with the area <NR> virtual-link <RID> message-digest-key
<NR> md5 <STRING> command. In some versions, these two commands are
combined automatically in the running config to the single statement
area <NR> virtual-link <RID> authentication message-digest message-digest-key
<NR> md5 <STRING> , but the result of either syntax is the same. After
authentication is enabled on the virtual-link, make sure to issue the clear ip
ospf process command, because the virtual-link does not support periodic
hellos. This means that if the authentication is wrong the virtual-link interface
will not immediately go down, but if there is a change in the topology it won’t
actually be propagated across the virtual-link.

OSPF Null Authentication:
=======================
router ospf 1
area 2 authentication
!
interface GigabitEthernet1.79
ip ospf authentication-key PASSWORD
!
interface GigabitEthernet1.37
ip ospf authentication null

Type 0 authentication or Null authentication means that basically authentication is
disabled, which is the default on all OSPF enabled interface. The use case for this
authentication type is when for example you have globally configured clear-text or
MD5/SHA authentication for one OSPF area, but want one or multiple interfaces in
that area to actually use no authentication. Because the interface level configuration
overrides the area level configuration, interfaces for which ip ospf authentication
null is configured will require no OSPF authentication.


OSPF Internal Summarization:
===========================

router ospf 1
area 3 range 155.1.8.0 255.255.252.0

Because devices in an OSPF area require the same copy of the database to
compute correct SPF, filtering or summarization of routes in the database can only
occur between areas or domains, not within an area. The below configuration
illustrates how an Intra-Area Summary Network LSA (LSA 3) can be summarized as
it is originated by an ABR.
Without any modification, R1 sees two separate routes and LSAs to reach the
networks 155.1.8.0/24 and 155.1.10.0/24. Because they are both originated by R5
(150.1.5.5), it implies that only R5 can modify R1’s view of these. By configuring the
area 3 range 155.1.8.0 255.255.252.0 command, R5 stops sending the specific LSAs
from area 3 into area 0 and groups them into the single route 155.1.8.0/22. Verify
the outputs on R1 before configuration changes:

OSPF External Summarization:
===========================

R9#
route-map CONNECTED->OSPF permit 10
match interface Loopback100 Loopback200
!
router ospf 1
redistribute connected metric 50 subnets route-map CONNECTED->OSPF
summary-address 160.1.9.0 255.255.255.0

External OSPF summarization is configured at the redistribution point between
routing domains with the summary-address command. These summaries inherit their
attributes from the subnets that make them up. For example, a summary comprised
of External Type-1 routes will result in an External Type-1 summary. This means
that on R10 in this configuration, the metric-type 1 command is set at the time of
redistribution instead of on the summary itself. External Type-2 OSPF routes, which
are the default, do not install the end-to-end metric in the routing table. Instead, only
the metric that was reported via the ASBR is installed. The actual routing path is
determined by the addition of the reported metric and the metric toward the ASBR,
which is called the forward metric:
Verify that redisstributed prefixes are summarized with correct metric and metrictype,
and routers in the OSPF domain have IP reachability with the redistributed
prefixes


Let's identify how the metric is computed for both external route types, starting with
E2, from R5's perspective. Being a E2 route, the metric showing up in the routing
table is the one which was set by the ASBR at redistribution

R5#show ip ospf database external 160.1.9.0
OSPF Router with ID (150.1.5.5) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 625
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link Link State ID: 160.1.9.0 (External Network Number )
Advertising Router: 150.1.9.9
LS Seq Number: 80000001
Checksum: 0xB479
Length: 36 Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0 Metric: 50
Forward Address: 0.0.0.0

!R5#show ip route 160.1.9.0
Routing entry for 160.1.9.0/24 Known via "ospf 1", distance 110,
metric 50, type extern 2, forward metric 1002

In the above output, R5 sees the summary 160.1.9.0/24 as an External Type-2 route
originated by the ASBR 150.1.9.9.The Forward Address: 0.0.0.0 field means that
R5 must now compute the metric toward the advertising router, R9, and install this
metric in the routing table as the forward metric. Specifically, this is calculated as
follows: first, R5 needs to identify the metric towards the ABR generating the Type4
LSA, which in this case is R3 (because is the router with links in the same area as
the ASBR, R9, and links in the same area as R5). The cost to reach R3 is 1000:

R5#show ip ospf database router adv-router 150.1.5.5
|
|
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 150.1.3.3
(Link Data) Router Interface address: 155.1.0.5
Number of MTID metrics: 0 TOS 0 Metrics: 1000

Next, the metric to reach the ASBR is signaled through a Type4 LSA, generated by
R3, thus R5 needs to know the cost from this LSA and add it to the cost to reach R3
in order to compute the forwarding metric of 1002. The routing table output for the
specific routing lookup should now show a metric of 50 to the destination, but a
forward metric of 1002 toward the ASBR. This forward metric is used to determine
the path toward the exit point:

R5#show ip ospf database asbr-summary adv-router 150.1.3.3
OSPF Router with ID (150.1.5.5) (Process ID 1)
Summary ASB Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1089
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router) Link State ID: 150.1.9.9 (AS Boundary Router address)
Advertising Router: 150.1.3.3
LS Seq Number: 80000002
Checksum: 0xA34E
Length: 28
Network Mask: /0 MTID: 0 Metric: 2
!
!R5#show ip ospf border-routers
OSPF Router with ID (150.1.5.5) (Process ID 1)
Base Topology (MTID 0)
Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 150.1.1.1 [1000] via 155.1.0.1, Tunnel0, ABR, Area 0, SPF 1840
i 150.1.10.10 [2] via 155.1.58.8, GigabitEthernet1.58, ASBR, Area 3, SPF 28
i 150.1.2.2 [1000] via 155.1.0.2, Tunnel0, ABR, Area 0, SPF 1840
i 150.1.3.3 [1000] via 155.1.0.3, Tunnel0, ABR, Area 0, SPF 1840
i 150.1.4.4 [1] via 155.1.45.4, GigabitEthernet1.45, ABR, Area 0, SPF 1840
I 150.1.9.9 [1002] via 155.1.0.3
, Tunnel0, ASBR, Area 0, SPF 1840
!
!R5#show ip route 160.1.9.0
Routing entry for 160.1.9.0/24 Known via "ospf 1", distance 110, metric 50, type extern 2,
forward metric 1002
Last update from 155.1.0.3 on Tunnel0, 00:51:02 ago
Routing Descriptor Blocks:
* 155.1.0.3, from 150.1.9.9, 00:51:02 ago, via Tunnel0
Route metric is 50, traffic share count is 1
!

OSPF Stub Areas:
===============

OSPF stub area types are used to filter information out of the OSPF database
based on LSA Type. The stub flag is part of the OSPF adjacency formation, which
implies that all devices in an area must agree on that parameter for adjacencies to
establish. The four stub types that IOS supports are stub areas, totally stubby areas,
not-so-stubby areas (NSSA), and not-so-totally-stubby areas. The first option, the
stub area, is used to remove Type-5 External link states from the database and
replace them with a default route. The logic behind this feature stems from how
external lookups between areas occur in OSPF.
When an OSPF router redistributes a route into the domain, it originates a Type-5
External LSA representing the route and its attributes. Inside this LSA, the
originating router sets the advertising router field to its local router-id and, generally,
the forward address field to 0.0.0.0.
When an OSPF router in the same area as the originator looks up the Type-5 LSA,
it looks at the forward address. If the forward address is set to 0.0.0.0, it means that
the traffic should be sent toward the advertising router to reach the destination. To
find out how to reach the advertising router, the advertising router’s Type-1 Router
LSA is consulted, and intra-area SPF is performed. This is similar to inter-area
routing logic, because the router doing the lookup does not compute SPF to the final
destination, only the intermediary advertising router. For external routing between
areas, the logic is modified slightly.
When an Area Border Router receives a Type-5 External LSA from a device in its
own area and passes it into a different area, a Type-4 ASBR Summary LSA is
generated. The Type-4 LSA tells devices in the new area how to forward toward the
ASBR, which in turn tells them how to forward toward the external route. For
example, examine the following situation in this topology. R4 redistributes the
directly connected route 160.1.4.4/32 into OSPF, originating a Type-5 External LSA:


R4#show ip ospf database external 160.1.4.4
OSPF Router with ID (150.1.4.4) (Process ID 1)
Type-5 AS External Link States
LS age: 36
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 160.1.4.4 (External Network Number ) Advertising Router: 150.1.4.4
LS Seq Number: 80000001
Checksum: 0xD77F
Length: 36 Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20 Forward Address: 0.0.0.0
External Route Tag: 0

When R5 wants to reach the destination 160.1.4.4/32, it sees that the forward
address is 0.0.0.0 and the advertising router is 150.1.4.4. R5 now does a Type-1
Router LSA lookup on 150.1.4.4 (R4):


OSPF LSA Type-3 Filtering:
=======================

ip prefix-list AREA_3_ROUTES deny 150.1.10.10/32
ip prefix-list AREA_3_ROUTES deny 155.1.108.0/24
ip prefix-list AREA_3_ROUTES permit 0.0.0.0/0 le 32
!
router ospf 1
area 3 filter-list prefix AREA_3_ROUTES out

OSPF Forwarding Address Suppression:
===================================

ip prefix-list AREA_3_ROUTES permit 0.0.0.0/0 le 32
!
router ospf 1
area 3 filter-list prefix AREA_3_ROUTES out
area 3 nssa translate type7 suppress-fa

Recall that with OSPF database lookups on external routes, the Forward Address
field determines who the next recursive lookup should be performed toward. With
typical Type-5 External LSAs, such as R4's Loopback100 redistributes into OSPF,
the forward address is normally set to 0.0.0.0. This means that the next lookup
should be performed toward the Advertising Router

OSPF Default Routing:
====================
router ospf 1
default-information originate always metric 40 metric-type 1

Default routing for non-stub areas in OSPF is accomplished through the origination
of Type-5 External LSAs via the default-information originate command. Without
any additional arguments, the OSPF process first checks to see if a default route is
installed in the routing table. If a default route is already installed, such as via a
static route or learned via BGP, the OSPF default route is originated. If the default
route is not found, no origination occurs. This behavior is typically desirable in
designs with multiple exit points out of the OSPF domain to upstream networks.
For example, imagine an OSPF network with exit points A and B out to the Internet.
Both router A and B are running BGP with upstream peers, and learning a default
route via BGP. As long as both devices maintain their upstream peerings, a default
route can be advertised into OSPF. However, if A’s link to the upstream neighbor is
lost, and hence its default route via BGP is lost, its OSPF default route
advertisement is withdrawn. The result of this design is that an individual exit point
will only collect default traffic if they themselves have a default exit point to upstream
networks. This behavior can be modified by adding the always argument to the
default-information originate statement, which essentially skips the checking for a
default route already being installed in the table.
The below view of the OSPF database on R1 indicates that both R4 and R6 are
originating a default route. Without additional arguments on the command, the
default route would have been advertised as a Type-2 External route with a metric
of 20. The same route lookup logic is applied to these default routes as normal Type-
5 External LSAs, where E1 is preferred over E2, and if multiple E2 routes exist with
the same metric, the forward metrics are compare


OSPF Conditional Default Routing:
================================

ip prefix-list LOOPBACK66 seq 5 permit 66.66.66.66/32
!
route-map TRACK_LOOPBACK66 permit 10
match ip address prefix-list LOOPBACK66
!
router ospf 1
default-information originate route-map TRACK_LOOPBACK66


OSPF Reliable Conditional Default Routing:
=========================================

ip sla 1
icmp-echo 155.1.108.10
frequency 5
!
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 state
!
ip route 169.254.0.1 255.255.255.255 Null0 track 1
ip prefix-list PLACEHOLDER seq 5 permit 169.254.0.1/32
!
route-map TRACK_PLACEHOLDER permit 10
match ip address prefix-list PLACEHOLDER
!
router ospf 1
default-information originate route-map TRACK_PLACEHOLDER


OSPF Filtering with Distribute-Lists:
======================================

Configure distribute-list filtering on R5, R8, and R10 so that these devices do not
install routes to the Loopback0 networks of R1 and R2.

router ospf 1
distribute-list 1 in
!
access-list 1 deny 150.1.1.1 0.0.0.0
access-list 1 deny 150.1.2.2 0.0.0.0
access-list 1 permit any

Recall that to properly compute SPF, all routers within an OSPF area must agree on
their view of the database. This implies that OSPF filtering in the database can be
accomplished between areas, but not within an area. Inter-area filtering has been
previously demonstrated with stub areas, and the Type-3 LSA Filter. Intra-area
filtering can be accomplished in OSPF with an inbound distribute-list; however, this
filtering only affects the local routing table, not the OSPF database.

Before applying distribute-list:

R5#show ip route ospf | i 150.1.
150.1.0.0/32 is subnetted, 10 subnets
O 150.1.1.1 [110/1001] via 155.1.0.1, 00:50:45, Tunnel0
O IA 150.1.2.2 [110/1001] via 155.1.0.2, 00:50:45, Tunnel0

When the distribute-list has been applied on R5, the routes 150.1.2.2/32 and
150.1.1.1/32 no longer appear in the routing table:

R5#show ip route ospf | i 150.1.
150.1.0.0/32 is subnetted, 8 subnets
O 150.1.3.3 [110/1001] via 155.1.0.3, 00:00:03, Tunnel0
O 150.1.4.4 [110/2] via 155.1.45.4, 00:00:03, GigabitEthernet1.45
O IA 150.1.6.6 [110/3] via 155.1.45.4, 00:00:03, GigabitEthernet1.45
O IA 150.1.7.7 [110/1002] via 155.1.0.3, 00:00:03, Tunnel0

OSPF Summarization and Discard Routes:
=====================================

router ospf 1
no discard-route internal
area 2 range 150.1.0.0 255.255.240.0

When summarization is configured in OSPF, similar to EIGRP and BGP, a matching
route to Null0 for the summary is installed locally in the routing table. This “discard”
route is used to prevent the forwarding of traffic toward a shorter match, such as a
default route, if no specific route toward the actual destination exists in the network.
The automatic origination of the discard route can be disabled with the no discardroute
[internal | external], where internal refers to inter-area summarization
performed with the area range command, and external refers to redistributed
summarization performed with the summary-address command. The operation of
the discard route can be illustrated as follows. R3 and R5 have the prefixes
150.1.7.7/32 and 150.1.9.9/32 filtered out of the routing table with a distribute-list.
Additionally, R3 is originating the summary 150.1.0.0/20 into area 0, which
encompasses addresses 150.1.0.0 through 150.1.15.255

OSPF Filtering with Administrative Distance:
===========================================

access-list 10 permit 155.1.146.0
!
router ospf 1
distance 255 150.1.5.5 0.0.0.0 10

OSPF Filtering with Route-Maps:
============================

access-list 3 permit 155.1.146.0
access-list 4 permit 155.1.0.4
!
route-map DENY_VLAN146_FROM_R4 deny 10
match ip address 3
match ip next-hop 4
!
route-map DENY_VLAN146_FROM_R4 permit 20
!
router ospf 1
distribute-list route-map DENY_VLAN146_FROM_R4 in


OSPF NSSA ABR External Prefix Filtering:
======================================

router ospf 1
summary-address 160.1.10.10 255.255.255.255 not-advertise

OSPF NSSA

OSPF Not-So-Stubby Areas

A Note On Section Initial Configuration Files: You must load the

initial configuration files for the section, named Basic OSPF Routing,

which can be found in CCIE R&S v5 Topology Diagrams & Initial

Configurations. Reference the Advanced Technology Labs OSPF

Diagram to complete this task.

Task

Configure Loopback100 on R6 and R8 with IP addressing in the format of

160.1.Y.Y/32, wherr Y is the router number.

Redistribute these prefixes into OSPF.

Configure OSPF area 3 so that R5 filters external routes out as they are sent from

area 0 to area 3.

Routers in area 3 should still be allowed to redistribute into OSPF.

Configuration

R5, R8 , R10:

router ospf 1

area 3 nssa

R6:

interface Loopback100

ip address 160.1.6.6 255.255.255.255

!

route-map CONNECTED->OSPF permit 10

match interface Loopback100

!

router ospf 1

redistribute connected subnets route-map CONNECTED->OSPF

R8:

interface Loopback100

ip address 160.1.8.8 255.255.255.255

!

route-map CONNECTED->OSPF permit 10

match interface Loopback100

!

router ospf 1

redistribute connected subnets route-map CONNECTED->OSPF

Verification

The OSPF Not-So-Stubby Area (NSSA) Option, as defined in RFC 3101, extends

the functionality of a stub area to allow the importing of a subset of external routes

into the area. Recall that with the stub area, Type-5 External LSA information is

suppressed from entering the database and is replaced with a default route

originated by the ABR(s). Because all Type-5 LSAs are suppressed, this also

implies that redistribution cannot occur within the area as well. This problem can be

seen from the parser error generated when redistribution and stub areas are

configured together:

R10#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.R10(config)#router ospf 1

R10(config-router)#area 3 stub

R10(config-router)#redistribute connected subnets

%OSPF-4-ASBR_WITHOUT_VALID_AREA: Router is currently an ASBR while having only one area which is a stub area

The OSPF NSSA option changes this behavior by allowing redistribution to occur

within the stub area, while still blocking external routes from entering the area

through the ABR(s). Specifically, this is implemented through the introduction of a

new link-state advertisement type, the Type-7 NSSA External LSA.

Routes that are redistributed directly into the NSSA are generated as Type-7 NSSA

External LSAs. Like Type-5 External LSAs, two subtypes of Type-7 NSSA External

LSAs exist, type 1 (N1) and type 2 (N2). N1, similar to E1, considers the metric that

the ASBR reports into the OSPF domain along with the metric needed to reach the

ABSR. N2, similar to E2, separates the metric into the flat value that the ASBR

reports into the OSPF domain, which is installed in the routing table, and the value

needed to reach the ASBR, known as the forwarding metric.

From the output below, we can see that with the default redistribution values, R8

originates the Type-7 NSSA External LSAs as metric-type 2, with a metric value of

20. The detailed output from R5’s routing table indicates a metric of 20 reported in

by R8, and a forward metric of 2, R5’s metric to reach R8's Loopback:

R5#show ip route ospf | include N

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

O N2 160.1.8.8 [110/20] via 155.1.58.8, 00:08:26, GigabitEthernet1.58

!

!R5#show ip route 160.1.8.8

Routing entry for 160.1.8.8/32 Known via "ospf 1", distance 110,

metric 20, type NSSA extern 2, forward metric 2

Last update from 155.1.58.8 on GigabitEthernet1.58, 00:08:39 ago

Routing Descriptor Blocks:

* 155.1.58.8, from 150.1.8.8, 00:08:39 ago, via GigabitEthernet1.58

Route metric is 20, traffic share count is 1

!

!R5#show ip ospf database nssa-external

OSPF Router with ID (150.1.5.5) (Process ID 1)

Type-7 AS External Link States (Area 3)

Routing Bit Set on this LSA in topology Base with MTID 0

LS age: 646

Options: (No TOS-capability, Type 7/5 translation, DC, Upward)

LS Type: AS External Link Link State ID: 160.1.8.8 (External Network Number )

Advertising Router: 150.1.8.8

LS Seq Number: 80000001

Checksum: 0x187D

Length: 36 Network Mask: /32

Metric Type: 2 (Larger than any link state path)

MTID: 0

Metric: 20 Forward Address: 150.1.8.8

External Route Tag: 0

When the Type-7 NSSA External LSA is received by the ABR and is moved into

area 0, the information contained in the Type-7 LSA is translated to a normal Type-5

External LSA. If multiple ABRs exist, only one of them performs the translation

through an election process, which is discussed in depth in a later task. In this

fashion, OSPF devices outside of the NSSA do not know that the NSSA exists,

which is analogous to how a Confederation works in BGP.

Note that R5 receives the Type-7 NSSA External LSA with the forward address set

to 150.1.8.8, which happens to be R8’s router-ID. With the previous Type-5 external

lookups, we saw the forward address set to 0.0.0.0, which meant to route toward the

advertising router to reach the final destination. In this case, the forward address is

non-zero, which causes the lookup to be performed toward 150.1.8.8. This is a

subtle difference in the lookup process, and this particular case results in the same

path selection even if the lookup had occurred on the advertising router (150.1.8.8)

instead of the forward address (150.1.8.8). There can, however, be certain designs

where there is a shorter path to the forward address than the advertising router’s

address, which is explored in a later task related to multiple exit points out of the

NSSA. The result of the translation on R5 is that devices in area 0 see the routes as

Type-5 External LSAs, not Type-7:

R1#show ip ospf database | begin Type-5

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag 160.1.6.6 150.1.6.6

909 0x80000001 0x0093BB 0

160.1.8.8 150.1.5.5 895 0x80000001 0x00D3D1 0

!

!R1#show ip ospf database external 160.1.8.8

OSPF Router with ID (150.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA in topology Base with MTID 0

LS age: 870

Options: (No TOS-capability, DC, Upward)

LS Type: AS External Link

Link State ID: 160.1.8.8 (External Network Number ) Advertising Router: 150.1.5.5

LS Seq Number: 80000001

Checksum: 0xD3D1

Length: 36 Network Mask: /32

Metric Type: 2 (Larger than any link state path)

MTID: 0

Metric: 20 Forward Address: 150.1.8.8

External Route Tag: 0

R1 performs a lookup on the now Type-5 External LSA, and, like R5, sees the

forward address set to 150.1.8.8. Again, note that the lookup process for this

translated Type-7 LSA is performed differently than a normal inter-area Type-5

external LSA lookup, because R1 computes its metric toward 150.1.8.8, and not a

Type-4 LSA describing the ASBR. Furthermore, note that R5 does not generate a

Type-4 ASBR Summary LSA describing R8:

R5#show ip ospf database asbr-summary 150.1.8.8

OSPF Router with ID (150.1.5.5) (Process ID 1) R5#

!

!R5#show ip route 150.1.8.8

Routing entry for 150.1.8.8/32 Known via "ospf 1", distance 110, metric 2, type intra area

Last update from 155.1.58.8 on GigabitEthernet1.58, 00:17:43 ago

Routing Descriptor Blocks: * 155.1.58.8, from 150.1.8.8, 00:17:43 ago, via GigabitEthernet1.58

Route metric is 2, traffic share count is 1

R1’s metric to the forwarding address 150.1.8.8 is 1002 via R5. This is the value

installed as the forward metric for the translated Type-7 LSA, with a metric of 20

from the Type-5 LSA itself:

R1#show ip route 150.1.8.8

Routing entry for 150.1.8.8/32 Known via "ospf 1", distance 110, metric 1002, type inter area

Last update from 155.1.0.5 on Tunnel0, 00:19:03 ago

Routing Descriptor Blocks: * 155.1.0.5, from 150.1.5.5, 00:19:03 ago, via Tunnel0

Route metric is 1002, traffic share count is 1

!

!R1#show ip route 160.1.8.8

Routing entry for 160.1.8.8/32 Known via "ospf 1", distance 110,

metric 20, type extern 2, forward metric 1002

Last update from 155.1.0.5 on Tunnel0, 00:19:06 ago

Routing Descriptor Blocks: * 155.1.0.5, from 150.1.5.5, 00:19:06 ago, via Tunnel0

Route metric is 20, traffic share count is 1

Similar to the stub area, the NSSA flag must be agreed upon by all devices in the

area, or adjacency cannot occur. This implies that the area is a normal area, a stub

area, or an NSSA, but no combination of the three. Furthermore, like the stub area,

Type-5 external LSAs are blocked from entering the NSSA area on the ABR(s), note

that R6's Loopback0 is known in area 0, but not in area 3:

R5#show ip route 160.1.6.6

Routing entry for 160.1.6.6/32 Known via "ospf 1", distance 110,

metric 20, type extern 2, forward metric 2

Last update from 155.1.45.4 on GigabitEthernet1.45, 00:20:55 ago

Routing Descriptor Blocks: * 155.1.45.4, from 150.1.6.6, 00:20:55 ago, via GigabitEthernet1.45

Route metric is 20, traffic share count is 1

!

!R8#show ip route 160.1.6.6

% Subnet not in table

Pitfall

The other key difference between stub and NSSA areas is how default

routing works. The stub area removes external LSAs and replaces them with

a default route. The totally stubby area extends this by replacing external

LSAs and inter-area LSAs with a default route. However, with the NSSA, a

default route is not automatically originated by the ABR. This means that

devices within the NSSA will have reachability to their own area and to other

areas, but not to destinations outside of the OSPF domain:

R8#show ip route 150.1.4.4

Routing entry for 150.1.4.4/32

Known via "ospf 1", distance 110, metric 3, type inter area

Last update from 155.1.58.5 on GigabitEthernet1.58, 00:23:20 ago

Routing Descriptor Blocks: * 155.1.58.5, from 150.1.5.5, 00:23:20 ago, via GigabitEthernet1.58

Route metric is 3, traffic share count is 1

!

!R8#traceroute 150.1.4.4

Type escape sequence to abort.

Tracing the route to 150.1.4.4

VRF info: (vrf in name/id, vrf out name/id)

1 155.1.58.5 11 msec 2 msec 3 msec 2 155.1.45.4 17 msec * 6 msec

!

!R8#show ip cef 160.1.6.6

0.0.0.0/0 no route

!

!R8#traceroute 160.1.6.6 ttl 2 2

Type escape sequence to abort.

Tracing the route to 160.1.6.6

VRF info: (vrf in name/id, vrf out name/id) 2 * * *

Verify that area 3 is configured as NSSA:

R5#show ip ospf | begin Area 3

Area 3

Number of interfaces in this area is 2 It is a NSSA area

Perform type-7/type-5 LSA translation

Area has no authentication

SPF algorithm last executed 00:39:47.094 ago

SPF algorithm executed 36 times

Area ranges are

Number of LSA 28. Checksum Sum 0x0D7257

Number of opaque link LSA 0. Checksum Sum 0x000000

Number of DCbitless LSA 0

Number of indication LSA 0

Number of DoNotAge LSA 0

Flood list length 0

EIGRP

EIGRP Summarization with Default Routing:
=====================================
ip prefix-list CONNECTED_TO_EIGRP seq 5 permit 4.0.0.0/24
ip prefix-list CONNECTED_TO_EIGRP seq 10 permit 4.0.1.0/24
ip prefix-list CONNECTED_TO_EIGRP seq 15 permit 4.0.2.0/24
ip prefix-list CONNECTED_TO_EIGRP seq 20 permit 4.0.3.0/24
!
route-map CONNECTED_TO_EIGRP permit 10
match ip address prefix-list CONNECTED_TO_EIGRP
!
router eigrp 100
redistribute connected route-map CONNECTED_TO_EIGRP
!
interface Tunnel0
ip summary-address eigrp 100 0.0.0.0 0.0.0.0


Summarization can also be used to originate a default route in EIGRP. The
disadvantage of this configuration, however, is that all subnets previously advertised
out an interface will be suppressed, because all IPv4 networks are a subnet of the

EIGRP Summarization with Leak Map
=================================

ip prefix-list CONNECTED_TO_EIGRP seq 5 permit 4.0.0.0/24
ip prefix-list CONNECTED_TO_EIGRP seq 10 permit 4.0.1.0/24
!
route-map CONNECTED_TO_EIGRP permit 10
match ip address prefix-list CONNECTED_TO_EIGRP
!
ip prefix-list LOOPBACK40 seq 5 permit 4.0.0.0/24
!
route-map LEAK_LOOPBACK40 permit 10
match ip address prefix-list LOOPBACK40
!
router eigrp 100
redistribute connected route-map CONNECTED_TO_EIGRP
!
interface Tunnel0
ip summary-address eigrp 100 0.0.0.0 0.0.0.0 leak-map LEAK_LOOPBACK40

EIGRP Floating Summarization:
============================

When summaries are created in EIGRP, OSPF, and BGP, the router automatically
installs a route to Null0 to match the summary. This is used to prevent the router
from forwarding traffic for destinations inside the summary that it does not have a
longer match for. However, in certain designs this can be an undesirable behavior.
To resolve this, EIGRP sets its interface-level summaries to have an administrative
distance of 5 by default. This means that any other route with a distance of 1–4 will
take precedence over the summary.

EIGRP Poisoned Floating Summarization:
======================================

On R5:

router eigrp 100
network 155.1.45.0 0.0.0.255
network 155.1.58.0 0.0.0.255
network 160.1.5.0 0.0.0.255
summary-metric 160.1.4.0/23 distance 255
!
interface GigabitEthernet1.58 -- To R8
ip summary-address eigrp 100 160.1.4.0 255.255.254.0

Before Applying:
---------------

R8#show ip route eigrp | b Gateway
Gateway of last resort is 155.1.58.5 to network 0.0.0.0
D* 0.0.0.0/0 [90/3328] via 155.1.58.5, 00:19:31, GigabitEthernet1.58
155.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
D 155.1.45.0/24 [90/3072] via 155.1.58.5, 00:19:31, GigabitEthernet1.58
160.1.0.0/24 is subnetted, 1 subnets
D 160.1.5.0 [90/130816] via 155.1.58.5, 00:00:32, GigabitEthernet1.58

With only summary route:
------------------------
!R8#show ip route eigrp | b Gateway
Gateway of last resort is 155.1.58.5 to network 0.0.0.0
D* 0.0.0.0/0 [90/3328] via 155.1.58.5, 00:23:16, GigabitEthernet1.58
155.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
D 160.1.4.0 [90/130816] via 155.1.58.5, 00:00:22, GigabitEthernet1.58

!R5#show ip route eigrp | b Gateway
Gateway of last resort is 155.1.45.4 to network 0.0.0.0
D* 0.0.0.0/0 [90/3072] via 155.1.45.4, 00:23:37, GigabitEthernet1.45
160.1.0.0/16 is variably subnetted, 3 subnets, 3 masks
D 160.1.4.0/23 is a summary, 00:00:42, Null0

After poisoning:
---------------
!R5#show ip route eigrp | b Gateway
Gateway of last resort is 155.1.45.4 to network 0.0.0.0
D* 0.0.0.0/0 [90/3072] via 155.1.45.4, 00:27:26, GigabitEthernet1.45
!R8#show ip route eigrp | b Gateway
Gateway of last resort is 155.1.58.5 to network 0.0.0.0
D* 0.0.0.0/0 [90/3328] via 155.1.58.5, 00:27:39, GigabitEthernet1.58


EIGRP Metric Weights
====================

By default, EIGRP uses only bandwidth and delay to calculate its composite metric,
as K1=K3=1 and K2=K4=K5=K6=0. Load, reliability, and extended attributes can
also be used, or the ratio at which bandwidth and delay are used can be changed,
by modifying the metric weights . Specifically, the calculation is as follows for
Classic EIGRP, which uses a 32-bit metric:

For 32 bit:

Metric = 256*[(K1*Scaled Bw) + (K2*Scaled Bw)/(256 - Load) + (K3*Scaled Delay)]*[K5/(Reliability + K4)]

For 64 bit:

Metric = [(K1*Minimum Throughput + (K2*Minimum Throughput/(256-Load) + (K3*Total Latency) + (K6*Extended Attributes)

If K5 equals zero, the second half of the equation is ignored in both cases. "Scaled
Bw" equals 107/(Minimum Bw/Kbps) and "Scaled Delay" equals (Delay/10) in
microseconds. "Minimum Throughput" equals (107 * 65535)/(Minimum Bw/Kbps),
"Total Latency" equals (Delay * 65536)/10 in microseconds for links below 1
GigabitEthernet and (107 * 65536/10)/Bw in microseconds for links above 1
GigabitEthernet.

R8#show ip protocols | section eigrp
Routing Protocol is "eigrp 100"
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 Protocol for AS(100) Metric weight K1=0, K2=0, K3=1, K4=0, K5=0

EIGRP Unequal Cost Load Balancing:
=================================

router eigrp 100
variance 5

EIGRP Convergence Timers:
=========================

interface GigabitEthernet1.146
ip hello-interval eigrp 100 1
ip hold-time eigrp 100 3

Unlike OSPF, EIGRP hello and hold-time intervals do not need to match to form
adjacencies. Just like OSPF, the locally configured Hello interval defines the local
rate interval for sending EIGRP hello packets, but the value is not transmitted in
EIGRP Hello packets. Unlike OSPF, the locally configured Hold-Time interval
defines for how long the remote router will wait for a EIGRP packet before resetting
the adjacency, so the value is transmitted in EIGRP Hello packets

EIGRP Stub Routing:
===================

router eigrp 100
eigrp stub connected

The EIGRP stub feature is used to limit the scope of EIGRP query messages and to
further limit which routes a neighbor advertises

EIGRP Stub Routing with Leak Map:
=============================
ip prefix-list R8_LOOPBACK0 seq 5 permit 150.1.8.8/32
!
route-map STUB_LEAK_MAP deny 10
match ip address prefix-list R8_LOOPBACK0
!
route-map STUB_LEAK_MAP permit 20
!
router eigrp 100
eigrp stub connected leak-map STUB_LEAK_MAP

EIGRP Filtering with Passive Interface:
====================================
router eigrp 100
passive-interface default
no passive-interface GigabitEthernet1.67

The passive-interface command in EIGRP, like in RIPv2, stops the sending of
updates out an interface. Unlike RIPv2, however, passive-interface in EIGRP will
prevent forming of an adjacency on the interface because it stops sending EIGRP
Hello packets as well, and hence the learning of any updates on the link.


EIGRP Filtering with Prefix-Lists:
=================================

Configure prefix-list filtering on R1 so that it does not install any updates received
from R4 on the VLAN 146 segment.
Allow all routes to be received from all other EIGRP neighbors

ip prefix-list NOT_FROM_R4 seq 5 deny 155.1.146.4/32
ip prefix-list NOT_FROM_R4 seq 10 permit 0.0.0.0/0 le 32
!
ip prefix-list PERMIT_ALL seq 5 permit 0.0.0.0/0 le 32
!
router eigrp 100
distribute-list prefix PERMIT_ALL gateway NOT_FROM_R4 in

EIGRP Filtering with Standard Access-Lists:
=========================================

Configure a one-line standard access-list on R9 to filter out all routes coming from R7
that have an odd number in the third octet.

access-list 1 permit 0.0.0.0 255.255.254.255
!
router eigrp 100
distribute-list 1 in GigabitEthernet1.79

EIGRP Filtering with Extended Access-Lists:
==========================================

Like RIP, extended access-lists when called as a distribute-list in IGP have a
different meaning than in redistribution or in BGP. With BGP and redistribution, the
“source” field in the ACL represents the network address, and the “destination” field
represents the subnet mask. In IGP distribute-list application, the “source” field in
the ACL matches the update source of the route, and the “destination” field
represents the network address. This implementation allows us to control which
networks we are receiving, but more importantly who we are receiving them from.
With VLAN 45 interface disabled and before the filter is applied, R5 routes as
follows

EIGRP Filtering with Offset Lists:
=================================

Configure an offset-list on R7 so traffic destined for R3’s Loopback0 prefix is sent to
R6.
If the Ethernet link to R6 is down, traffic should be rerouted directly to R3.

R7:
access-list 1 permit host 150.1.3.3
!
router eigrp 100
offset-list 1 in 2000 GigabitEthernet1.37


Like in RIP, the offset-list feature in EIGRP is used to modify the metric on a perroute
basis or a per-interface basis. Before any metric modifications, we can see
that R7 is routing directly to R3 to reach 150.1.3.3/32. There are no additional
entries in the EIGRP topology table of R7 for this prefix because R6 also routes
through R7 to reach it:

R7#show ip route 150.1.3.3
Routing entry for 150.1.3.3/32
Known via "eigrp 100", distance 90, metric 130816, type internal
Redistributing via eigrp 100
Last update from 155.1.37.3 on GigabitEthernet1.37, 01:05:42 ago
Routing Descriptor Blocks: * 155.1.37.3, from 155.1.37.3, 01:05:42 ago, via GigabitEthernet1.37

!R7#show ip eigrp topology 150.1.3.3/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.7.7) for 150.1.3.3/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 130816
Descriptor Blocks: 155.1.37.3 (GigabitEtherGigabitEthernet1.37), from 155.1.37.3, Send flag is 0x0
Composite metric is (130816/128256)
****************

R7#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.R7(config)#router eigrp 100
R7(config-router)#offset-list 1 in 2000 GigabitEthernet1.37****************

!R7#show ip route 150.1.3.3
Routing entry for 150.1.3.3/32
Known via "eigrp 100", distance 90, metric 131328, type internal
Redistributing via eigrp 100
Last update from 155.1.67.6 on GigabitEthernet1.67, 00:00:15 ago
Routing Descriptor Blocks: * 155.1.67.6, from 155.1.67.6, 00:00:15 ago, via GigabitEthernet1.67
!R7#show ip eigrp topology 150.1.3.3/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.7.7) for 150.1.3.3/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131328
Descriptor Blocks: 155.1.67.6 (GigabitEthernet1.67), from 155.1.67.6, Send flag is 0x0
Composite metric is (131328/131072)
155.1.37.3 (GigabitEthernet1.37), from 155.1.37.3, Send flag is 0x0
Composite metric is (132816/130256), route is Internal*************************


EIGRP Filtering with Administrative Distance:
============================================

Configure administrative distance filtering on R6 so that it does not install the route to
R4’s Loopback0 prefix.

R6:
access-list 4 permit host 150.1.4.4
!
router eigrp 100
distance 255 0.0.0.0 255.255.255.255 4

EIGRP Filtering with Per Neighbor AD:
======================================

Configure administrative distance filtering on R3 so that traffic destined for R7’s
Loopback0 prefix is sent to R1.
ensure R3 never uses the direct path via R7.

R3:
access-list 7 permit host 150.1.7.7
!
router eigrp 100
distance 255 155.1.37.7 0.0.0.0 7

The administrative distance for EIGRP internal routes can be changed on a
per-prefix basis, but external EIGRP routes cannot

EIGRP Filtering with Route Maps:
=================================

route-map FILTER_ON_TAGS deny 10
match tag 4
!
route-map FILTER_ON_TAGS permit 20
!
router eigrp 100
distribute-list route-map FILTER_ON_TAGS in

Unlike BGP, filtering with route-maps in IGP is usually limited to redistribution
filtering only. However, EIGRP supports route-map filtering as a distribute-list with
matches on metric and tag values. Route tags are set at the time of redistribution
and can be used like BGP community values to group prefixes together without
having to match on the actual route in a prefix-list or access-list.

EIGRP Bandwidth Pacing:
======================

Configure R5 so that EIGRP cannot use more than 200Kbps of bandwidth on its
DMVPN connection, assuming that the link speed is 2Mbps.

interface Tunnel0
bandwidth 2000
ip bandwidth-percent eigrp 100 10

By default EIGRP can use up to maximum 50% of the administrative bandwidth of
the interface. The absolut value can be changed by modifying the bandwidth on the
interface or by changing the percentage level with interface-level command
ip bandwidth-percent eigrp <AS_NR> <percentage> . Verify the SRTT and Pacing timers
for the tunnel interface before bandwidth usage is changed:

EIGRP Default Metric:
=====================

ip route 160.1.2.2 255.255.255.255 155.1.23.2
!
router eigrp 100
redistribute static
default-metric 100000 10 255 1 1500

When redistributing static and connected prefixes into EIGRP or between EIGRP
processes, metrics are automatically derived from the source prefix. For all other
redistribution, the metric must be manually set on the redistribute statement, under a
route-map, or from the default metric. The default metric affects all redistributed
prefixes for which a specific metric has not been configured.

EIGRP Neighbor Logging:
=====================
router eigrp 100
no eigrp log-neighbor-changes
eigrp log-neighbor-warnings 20

EIGRP Router-ID:
==============

EIGRP uses the router-id field in external routes as a loop prevention mechanism.
The router that originates the external route inserts its EIGRP router-id into the
update. If an update is received back in with a router-id in this field matching the
local router-id, the update is dropped.

EIGRP Maximum Hops:
==================
Configure all devices in EIGRP AS 100 so that routes with a hop count of greater
than 5 are considered invalid


R1 – R10:
router eigrp 100
metric maximum-hops 5

RIP

RIPv2 Offset List --
================
router rip
offset-list 1 in 3 GigabitEthernet1.13

RIPv2 Filtering with Prefix-Lists --
=================================
router rip
distribute-list prefix RIP_FILTER_TO_R8 out GigabitEthernet1.58
distribute-list prefix PERMIT_ALL gateway NOT_FROM_R4 in

The prefix-list named RIP_FILTER_TO_R8 filters R6 and R7
Loopback0 prefixes from being advertises out on VLAN 58 and
permits all others. The syntax 0.0.0.0/0 le 32 in a prefix-list
means match all routes, similar to the any keyword from accesslists.
The second route filtering is based on both the routes being
learned and whom they are learned from. This filter says match any
route coming in any interface, per the PERMIT_ALL prefix-list, and
allow them to come in as long as they were not learned from R4, per
the deny 155.1.0.4/32 syntax.

RIPv2 Filtering with  Access-Lists:
==========================================
Configure a one-line standard access-list on R6 to filter out the IPv4 prefixes that
have an even number in the third octet

access-list 1 permit 0.0.1.0 255.255.254.255
!
router rip
distribute-list 1 in

When extended access-lists are used as distribute-list for IGP filtering, the
functionality is different than when used for route redistribution or in BGP. With BGP
and redistribution, the source field in the ACL represents the network address, and
the destination field represents the subnet mask. In IGP distribute-list application,
the source field in the ACL matches the update source of the route, and the
destination field represents the network address. This implementation allows us to
control which routes we accept, but more importantly who do we accept it from.
Before the filter is applied, R5 routes to R3 for VLANs 7 and 9, and to R1 for VLAN
146 and R1’s Loopback

Admin Distance:
===============

access-list 1 permit host 150.1.4.4
!
router rip
distance 255 0.0.0.0 255.255.255.255 1


access-list 2 permit 150.1.3.3
!
router rip
distance 255 155.1.37.3 0.0.0.0 2

Default Route:
===============

Note in the above output that R6 does not have a default route installed in
the routing table. Unlike OSPF, RIP does not require that a default route
actually be installed in the routing table before originating one. For this
reason, route feedback of R6’s default origination will occur in this topology


Conditional Default Route
--------------------------
ip prefix-list ROUTE_TO_R9_LOOP seq 5 permit 150.1.9.9/32
!
route-map TRACK_ROUTE_TO_R9_LOOP permit 10
match ip address prefix-list ROUTE_TO_R9_LOOP
!
router rip
default-information originate route-map TRACK_ROUTE_TO_R9_LOOP

Reliable Conditional Default Route:
-----------------------------------
Configure R1 to originate a default route.
Configure IP SLA on R1 to track ICMP reachability to R7's IPv4 address on VLAN 7.
ICMP Echo-Request should be sent each 5 seconds.
Configure IP SLA tracking on R1 so that if an ICMP Echo-Reply is not received from
VLAN 7, R1 withdraws its default route advertisement.

ip sla 1
frequency 5
icmp-echo 155.1.7.7
!
ip sla schedule 1 start-time now life forever
!
track 1 ip sla 1
!
ip route 169.254.0.1 255.255.255.255 Null0 track 1
!
ip prefix-list DUMMY_ROUTE_TRACKED_VIA_SLA seq 5 permit 169.254.0.1/32
!
route-map RELIABLY_TRACK_LINK_TO_VLAN7 permit 10
match ip address prefix-list DUMMY_ROUTE_TRACKED_VIA_SLA
!
router rip
default-information originate route-map RELIABLY_TRACK_LINK_TO_VLAN7

As long as R4 has a route to the network 150.1.9.9/32 installed in the routing table,
it will advertise a default route.

RIPv2 Source Validation:
========================

R7:
router rip
no validate-update-source
R9:
interface GigabitEthernet1.79
ip unnumbered Loopback0

Verify that before IP unnumbered is configured on R9, RIP routes are correctly
installed in both the R7 and R9 routing tables, and there is IPv4 connectivity.

After applying the IP unnumbered configuration on R9, because R9 will be sending
RIP updates out on VLAN 79 Ethernet segment with a IPv4 address not in the same
subnet as R7's IPv4 address, R7 will ignore these updates, and all RIP routes
learned from R9 will slowly be removed from the routing table based on the flush
timer.

MPLS-LDP

1) To enable MPLS switching on an interface and start LDP on the same

interface, you must enter the interface-level command "mpls ip" . If you have

too many interfaces to enable MPLS on, you may use MPLS LDP auto

configuration, which is available when you run OSPF as your IGP protocol.

Under the OSPF process, enter the command "mpls ldp autoconfig" to

activate LDP/MPLS switching on all interfaces running OSPF.

2) Upon hearing from the other LDP routers, LDP learns their LDP Router IDs,

which is by default the highest Loopback IP addresses. You may change

the Router-ID by using the command 

"mpls ldp router-id <interface> force"

3) If for some reason the Loopback IP addresses are unreachable, a TCP

connection will not be established. If you want LDP to establish a TCP

connection using the physical interface IP address, use the interface-level

command "mpls ldp discovery transport-address interface"

4) Using the Router ID IP addresses as sources, two routers that heard from

each other establish a TCP transport connection using the destination port

of 646. This connection could be authenticated using an MD5 hash TCP

option. The hashing key is defined per-neighbor by using the command

mpls ldp neighbor <IP> password <password> . The IP address here is the

neighbor’s LDP Router ID. To make the use of passwords mandatory, you

need the global command mpls ldp password required .

To disable mpls labels during trace router issue command "no mpls label ttl-prop"