VTP Mode
|
Description
|
|---|---|
VTP server
|
In VTP server mode, you can create, modify, and delete VLANs, and specify other configuration parameters (such as the VTP version) for the entire VTP domain. VTP servers advertise their VLAN configurations to other switches in the same VTP domain and synchronize their VLAN configurations with other switches based on advertisements received over trunk links.
VTP server is the default mode.
Note
 In VTP server mode, VLAN configurations are saved in NVRAM. If the switch detects a failure while writing a configuration to NVRAM, VTP mode automatically changes from server mode to client mode. If this happens, the switch cannot be returned to VTP server mode until the NVRAM is functioning. |
VTP client
|
A VTP client behaves like a VTP server and transmits and receives VTP updates on its trunks, but you cannot create, change, or delete VLANs on a VTP client. VLANs are configured on another switch in the domain that is in server mode.
In VTP versions 1 and 2, in VTP client mode, VLAN configurations are not saved in NVRAM. In VTP version 3, VLAN configurations are saved in NVRAM in client mode.
|
VTP transparent
|
VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements. However, in VTP version 2 or version 3, transparent switches do forward VTP advertisements that they receive from other switches through their trunk interfaces. You can create, modify, and delete VLANs on a switch in VTP transparent mode.
In VTP versions 1 and 2, the switch must be in VTP transparent mode when you create extended-range VLANs. VTP version 3 also supports creating extended-range VLANs in client or server mode. See the "Configuring Extended-Range VLANs" section on page 13-10.
When the switch is in VTP transparent mode, the VTP and VLAN configurations are saved in NVRAM, but they are not advertised to other switches. In this mode, VTP mode and domain name are saved in the switch running configuration, and you can save this information in the switch startup configuration file by using the copy running-config startup-config privileged EXEC command. The running configuration and the saved configuration are the same for all switches in a stack.
|
VTP off
|
A switch in VTP off mode functions in the same manner as a VTP transparent switch, except that it does not forward VTP advertisements on trunks.
|
Monday 28 December 2015
VTP
Tuesday 22 December 2015
SSH Rotary option
https://blog.initialdraft.com/archives/2377/
Let’s imagine we are asked to configure Router1 to run SSH access using the port 2009.
As we already know, SSH uses the tcp port 22 by default. So, how can we change the port that R1 uses to listen for SSH connections? There is a way to do it straightforward, with a configuration only in R1. This feature is called SSH rotary.
Let’s see how to configure it, the first thing we have to do is to generate the RSA key pair for the router with the command crypto key generate rsa. But first, we need to configure the hostname and the domain-name server in the router:
router(config)# hostname R1 R1(config)# ip domain name cisco.com R1(config)# crypto key generate rsa The name for the keys will be: R1.cisco.com Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
Once we have created the RSA key pair, it’s necessary to configure the user and password to access the router, and to apply it into the VTY line settings:
R1(config)# username cisco password CISCO R1(config)# line vty 0 4 R1(config-line)# login local
Now, we will configure the router to expect ssh connections on port 2009. This is done with the command ip ssh port and applying arotary group. Then, that rotary group is configured on the VTY lines:
R1(config)# ip ssh port 2009 rotary 1 R1(config)# line vty 0 4 R1(config-line)# rotary 1
Let’s verify that the configuration its actually working:
R1#ssh -l cisco -p 2009 2.2.2.1
Password:
R1>sh tcp brief
TCB Local Address Foreign Address (state)
66CCF71C 2.2.2.1.18922 2.2.2.1.2009 ESTAB
66CCFC78 2.2.2.1.2009 2.2.2.1.18922 ESTAB
So here you have it, how to configure a router to be accesed via SSH with a non-by-default port.
OSPF Forward Address
In Normal Areas:
http://www.costiser.ro/2013/05/26/ospf-understanding-the-forwarding-address-fa/
Without the concept of FA, traffic from RT-B towards those external destinations will go via the ASBR (RT-A), as shown in the traceroute output.
If RT-A set FA = 192.168.1.3, then RT-B would route directly to FA instead of ASBR, as you can see below:
IN NSSA AREAS:
http://www.costiser.ro/2013/05/26/ospf-understanding-the-forwarding-address-fa/
In the beginning, let’s see why FA (Forwarding Address) exists in the first place. We all know that packets destined to external destinations are routed through the advertising ASBR. According to RFC 2328 (see page 141), there might be situations when this behaviour is not desirable and they introduced the concept of FA in order to avoid extra hops in the path.
Consider the diagram below, where both RT-A and RT-B are connected to RT-X (a partner company), but only RT-A speaks eBGP with partner company (let’s say that RT-B does not have enough memory to run BGP). RT-A redistributes the BGP routes (ex: 172.16.10.0/24) into the OSPF domain, thus becoming an ASBR.
Consider the diagram below, where both RT-A and RT-B are connected to RT-X (a partner company), but only RT-A speaks eBGP with partner company (let’s say that RT-B does not have enough memory to run BGP). RT-A redistributes the BGP routes (ex: 172.16.10.0/24) into the OSPF domain, thus becoming an ASBR.
Without the concept of FA, traffic from RT-B towards those external destinations will go via the ASBR (RT-A), as shown in the traceroute output.
If RT-A set FA = 192.168.1.3, then RT-B would route directly to FA instead of ASBR, as you can see below:
Now, let’s see what are the conditions required to have a non-zero FA. According to Cisco documentation, all of these conditions need to be true:
- 1. OSPF is enabled on the ASBR’s next hop interface AND
- 2. ASBR’s next hop interface is non-passive under OSPF AND
- 3. ASBR’s next hop interface is not point-to-point AND
- 4. ASBR’s next hop interface is not point-to-multipoint AND
- 5. ASBR’s next hop interface address falls under the network range specified in the router ospf command
Note the AND logical operator between each condition. An easier way to remember this: next-hop interface must be a broadcast interface that is natively advertised in OSPF.
- See more at: http://www.costiser.ro/2013/05/26/ospf-understanding-the-forwarding-address-fa/#sthash.69acUFQA.dpufIN NSSA AREAS:
he selection process is to choose the highest IP of a loopback advertised
into the NSSA area. If no loopback is advertised then choose the highest
physical interface IP advertised into the NSSA area.
into the NSSA area. If no loopback is advertised then choose the highest
physical interface IP advertised into the NSSA area.
I hope that I have provide another piece to the OSPF puzzle and you now have
a good understanding of the forwarding address.
a good understanding of the forwarding address.
BGP Regular Expressions
Filtering based on the AS_PATH attribute is done using BGP regular expressions.
Regular expressions are matched against the AS_PATH strings. Remember that
AS_PATH can be constructed of the following elements: AS_SET (unordered list of
AS numbers), AS_SEQUENCE (ordered list of AS numbers), AS_CONFED_SET,
and AS_CONFED_SEQUENCE, which are the same elements but consist of the
confederation AS numbers. For the purpose of matching, the AS_PATH attribute is
viewed as a string starting with the adjacent AS number on the leftmost position,
and the originating AS number in the rightmost position. When matching the
AS_SET attribute, enclose the AS numbers in curly brackets and separate them
with commas; for example, {100,200,300}. When matching a confederation path,
enclose the AS numbers in parentheses, using backslashes to escape the special
meaning of the character: “\(100\)”.
We will discuss the most useful types of regexp patterns suitable for many “real-life”
situations. You may read more about BGP regular expressions basics in our blog
post Understanding BGP Regular Expressions. First, recall the basic regular
expression meta-characters or modifiers:
1. “.” – any character
2. “?” – repeat the previous character one or zero times
3. “*” – repeat the previous character zero or any times
4. “+” – repeat the previous character one or more times
5. “^” – match the beginning of a string
6. “$” – match the end of a string
7. “[]” – range or elements
8. “_” – match the “space” separating AS numbers OR the end of the AS_PATH list
Other important regexp features include grouping and back-referencing. You can
use parentheses to group AS numbers, such as (123 124 1+), and every group is
assigned a number starting from left to right. For example, in the string “1 2 (3 4) 5 6
(7 8)”, the first group is assigned the number 1 and the second group number 2. You
can later “recall” the grouping by using the commands \1, \2, and so on for the group
numbers. For example, the string “(1 2) 3 \1” would match “1 2 3 1 2”. You may use
the pipe character “|” in addition to the grouping characters for the concept of
alternation. For example, (1 2)|(5 6) would match “1 2” or “5 6”. Now the practical
examples:
“^$” - means an empty AS_PATH attribute, which identifies the prefixes advertised
in the local AS.
“^254_” - means prefixes received from the directly adjacent AS 254. Note that
using “_” is important, because there could be another adjacent AS with the number
starting with 254.
“_254_” - prefixes transiting AS 254. The “_” characters are needed to clearly
separate the AS number.
“_254$” - means prefixes originated in the AS 254. This expression matches the
rightmost position in the string, meaning that the expression could be of arbitrary
length.
“^([0-9]+)_254” - routes from the AS 254 when it’s just “one-hop” away.
“^254_([0-9]+)” - prefixes from the clients of the directly connected AS 254.
“^(254_)+([0-9]+)” - prefixes from the clients of the adjacent AS 254, accounting for
the fact that AS 254 may do AS_PATH prepending.
“^254_([0-9]+_)+” - prefixes from the clients of the adjacent AS 254, accounting for
the fact that the clients may do AS_PATH prepending.
^\(65100\) - prefixes learned from the confederation peer 65100.
You configure BGP regular-expression using the IP AS-PATH access-lists:
ip as-path access-list <N> {permit|deny} <Regexp> . This access-list might be applied
as a filter-list to a peer using the syntax: neighbor <IP> filter-list <N> [in|out] .
However, the best approach is to match AS_PATH access-lists under a route-map
applied to the peer ( match as-path ),
Monday 21 December 2015
BGP Access-list Prefix-List Distribute-list
Order of preference
For inbound updates:
1. route-map
2. filter-list
3. prefix-list OR distribute-list
For outbound updates:
1. prefix-list OR distribute-list
2. filter-list
3. route-map
Prefix-List:
ip prefix-list <NAME>seq <Num> {permit|deny} <Subnet>/<Prefix > [ge <Length1>] [le
<Length2>]
Can be used in 2 ways.
Way 1:
ip prefix-list BLOCK_222 deny 222.22.2.0/24
ip prefix-list BLOCK_222 permit 0.0.0.0/0 le 32
!
router bgp 200
neighbor 192.10.1.254 prefix-list BLOCK_222 in
Way 2:
ip prefix-list SHORTER_THAN_22 permit 0.0.0.0/0 le 22
!
route-map FROM_R9 permit 100
match ip address prefix-list SHORTER_THAN_22
!
router bgp 300
neighbor 155.1.79.9 route-map FROM_R9 in
Standar Access-List:
Way 1:
R2 so that it does not accept any prefix with the address 222.22.2.0 from R10:
ip access-list standard BLOCK_222
deny 222.22.2.0
permit any
!
router bgp 200
neighbor 192.10.1.254 distribute-list BLOCK_222 in
ip access-list standard ODD_FIRST_OCTET
permit 1.0.0.0 254.255.255.255
!
route-map FROM_R9 permit 100
match ip address ODD_FIRST_OCTET
!
router bgp 300
neighbor 155.1.79.9 route-map FROM_R9 in
Way 2:
Configure a standard access-list on R7 so that it does not accept any prefixes with
an even number in the first octet from R9
R7
ip access-list standard ODD_FIRST_OCTET
permit 1.0.0.0 254.255.255.255
!
route-map FROM_R9 permit 100
match ip address ODD_FIRST_OCTET
!
router bgp 300
neighbor 155.1.79.9 route-map FROM_R9 in
Extended Access-Lists:
Extended access-lists add more functionality to BGP prefixes filtering. In addition to
matching the subnet numbers, they also allow for subnet mask matching. A typical
extended access-list entry in the format permit {proto} <src-subnet> <src-mask> <dstsubnet>
<dst-mask> [options] is treated as follows. First, the protocol field and other
options are ignored. Next, the <src-subnet> <src-mask> pair is used to build an
expression for prefix subnet matching. The pair <dst-subnet> <dst-mask> is used as
an expression to match prefixes subnet mask.
permit ip 10.0.0.0 0.0.0.0 255.255.0.0 0.0.0.0 - matches 10.0.0.0/16 - Only
permit ip 10.0.0.0 0.0.0.0 255.255.255.0 0.0.0.0 - matches 10.0.0.0/24 - Only
permit ip 10.1.1.0 0.0.0.0 255.255.255.0 0.0.0.0 - matches 10.1.1.0/24 - Only
permit ip 10.0.0.0 0.0.255.0 255.255.255.0 0.0.0.0 - matches 10.0.X.0/24 - Any
permit ip 10.0.0.0 0.255.255.255 255.255.255.0 0.0.0.255 - matches 10.X.X.X/24 to
10.X.X.X/32 - Any number in the second, third, and fourth octet of the network with a
/24 to /32 subnet mask
permit ip 10.0.0.0 0.255.255.255 255.255.255.128 0.0.0.127 - matches 10.X.X.X/25 to
10.X.X.X/32 - Any number in the second, third, and fourth octet of the network with a
/25 to /32 subnet mask
Ex:
Configure an extended access-list on R7 as follows:
It does not accept any prefixes with an even third octet and with a subnet mask greater than or equal to /22 from R9.
This list should apply directly to the neighbor
R7:
ip access-list extended EVEN_3RD_MASK_GT_22
deny ip 0.0.0.0 255.255.254.255 255.255.252.0 0.0.3.255
permit ip any any
!
router bgp 300
neighbor 155.1.79.9 distribute-list EVEN_3RD_MASK_GT_22 in
BGP Conditional Advertisement
BGP Conditional Advertisement
BGP, by default, advertises all the best paths in its BGP table to external peers. Sometimes, it might be required that BGP advertises some paths conditionally, meaning, advertise paths only if some other routes are available.
Conditional advertisement has two forms- advertisement of some prefix(es) when some other prefix(es) do not exist and advertisement of some prefix(es) when some other prefix(es) exist. The prefixes to be advertised are defined by advertise-map. The condition is defined by a route-map called non-exist-map for conditions that do not exist or by a route-map called exist-map for conditions that do exist.
The first form of conditional advertisement is configured as follows-
BGP, by default, advertises all the best paths in its BGP table to external peers. Sometimes, it might be required that BGP advertises some paths conditionally, meaning, advertise paths only if some other routes are available.
Conditional advertisement has two forms- advertisement of some prefix(es) when some other prefix(es) do not exist and advertisement of some prefix(es) when some other prefix(es) exist. The prefixes to be advertised are defined by advertise-map. The condition is defined by a route-map called non-exist-map for conditions that do not exist or by a route-map called exist-map for conditions that do exist.
The first form of conditional advertisement is configured as follows-
The map2 route-map tracks the prefix(es) in the local router. If a match is made, the status of the non-exist-map is Withdraw; when no match is made, the status is Advertise.
The map1 route-map defines the prefix(es) that are to be advertised when the status of non-exist-map is Advertise. When the status of the non-exist-map isWithdraw, the prefix(es) in advertise-map are not advertised.
The second form of conditional advertisement is configured as follows-
Again, the map2 route-map tracks the prefix(es) in the local router. If a match is made, the status of the exist-map is Advertise; when no match is made, the status of the exist-map is Withdraw. The function is map1 route-map is same as above.
BGP Maps
BGP Aggregation - Attribute-Map:
========================
R8#show ip bgp 112.0.0.0 255.0.0.0
BGP routing table entry for 112.0.0.0/8, version 49 Paths: (1 available, best #1, table default,
not advertised to EBGP peer
)
Advertised to update-groups:
5
Refresh Epoch 3
54 50 60
155.1.108.10 from 155.1.108.10 (31.3.0.1)
Origin IGP, localpref 100, valid, external, best Community: no-export
rx pathid: 0, tx pathid: 0x0
R5#aggregate-address 112.0.0.0 248.0.0.0 summary-only as-set
R5#show ip bgp 112.0.0.0 248.0.0.0
BGP routing table entry for 112.0.0.0/5, version 75 Paths: (1 available, best #1, table default,
not advertised to EBGP peer
)
Advertised to update-groups:
21 22
Refresh Epoch 1
{54,50,60}, (aggregated by 200 150.1.5.5)
0.0.0.0 from 0.0.0.0 (150.1.5.5)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best Community: no-export
rx pathid: 0, tx pathid: 0x0
When you use the as-set parameter to the aggregate-address command, the
resulting prefix will inherit “additive” attributes of the specific prefixes. This includes
the AS_PATH attributes, condensed into AS_SET and the community attributes,
which are grouped together from all prefixes. We will explore community signaling in
further detail, but for now remember that any prefix bearing the community attribute
value of “no-export” is not advertised to the adjacent ASs.
In our scenario, we have R8 tagging just one prefix—112.0.0.0/8 with the
community value of “no-export”. However, when R5 aggregates all prefixes into one,
the summary prefix inherits the “no-export” community from one of the specific
routes. In effect, AS 200 speakers will not be able to advertise the summary prefix to
the neighbors.
The solution to this problem is the use of the attribute-map parameter to the
aggregate-address command. This parameter specifies the route-map that sets BGP
attributes for the newly generated prefix. You may set any configuration BGP value,
such as metric, origin, local-preference, and so on. However, in our case we are
interested in setting the community attribute value for the summary. The route-map
applies the set community none command and erases all communities for the new
prefix. Naturally, all routers are configured to propagate communities across AS 200.
R5#route-map ATTR_MAP
set community none
!
router bgp 200
aggregate-address 112.0.0.0 248.0.0.0 summary-only as-set attribute-map ATTR_MAP
R5#show ip bgp 112.0.0.0 248.0.0.0
BGP routing table entry for 112.0.0.0/5, version 76
Paths: (1 available, best #1, table default)
Advertised to update-groups:
20 21 22
Refresh Epoch 1
{54,50,60}, (aggregated by 200 150.1.5.5)
0.0.0.0 from 0.0.0.0 (150.1.5.5)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
rx pathid: 0, tx pathid: 0x0
BGP Aggregation - Advertise Map:
=======================
When using the as-set keyword with BGP aggregation, some of the specific prefix
attributes got mixed together in the new prefix. Specifically, you should watch out for
the resulting AS_SET and list of community attributes. In the previous task, you
learned how to modify some of the aggregated prefix attributes. However, you
cannot manipulate an important attribute such as AS_SET directly. Instead, you
may specify the specific prefixes that will be used to make up the attribute list for the
aggregate prefix. This is accomplished by using the advertise-map parameter to the
aggregate-address command. The route-map used as advertise-map should permit
specific prefixes to be used to compose the aggregate attributes, such as AS_SET.
You can use only access-list, prefix-list, or as-path access-lists to match the specific
prefixes. Information from the prefixes denied by the route-map is not used when
constructing the resulting summary-prefix. You may use this method to remove the
prefixes with unwanted BGP community attributes as well.
In our scenario, the AS_SET attribute for the summary route should be composed of
AS numbers 200, 254, and 300. However, by using the advertise-map parameter,
we filter out prefix originated in AS 300 and thus end up with AS_SET of {200,254}.
This allows AS 300 accepting back the summary prefix.
On R4 before map with just aggregate-address and as-set:
*> 222.22.0.0/22 0.0.0.0 100 32768 {200,254,300} ?
R4, R6:
ip prefix-list AS300_PREFIX permit 222.22.3.0/24
!
route-map ADVERTISE_MAP deny 10
match ip address prefix-list AS300_PREFIX
!
route-map ADVERTISE_MAP permit 100
!
router bgp 100
aggregate-address 222.22.0.0 255.255.252.0 summary-only as-set advertise-map ADVERTISE_MAP
After:
fa
*> 222.22.0.0/22 0.0.0.0 100 32768 {200,254} ?
Saturday 19 December 2015
NAT
ip nat outside source list:
translates the source of the IP packets that are traveling outside to inside
translates the destination of the IP packets that are traveling inside to outside
ip nat inside source list:
translates the source of IP packets that are traveling inside to outside
translates the destination of the IP packets that are traveling outside to inside
Quite many people don’t pay attention to the difference in handling packets on interfaces configured for NAT inside and outside. Here is an example to demonstrate how NAT “domains” interact with routing. Consider three routers connected in the following manner:
Example:
=======
For this scenario we have no routing configured. Let’s use static NAT to provide connectivity between R1 and R2. R2 would see R1 as a host on local connected segment with the IP address 155.1.23.1 and R1 would see R2 as a host on it’s local segment with the IP address 155.1.13.2. This goal could be achieved with the following configuration:
R3: ! interface Serial 1/0.301 point-to-point ip address 155.1.13.3 255.255.255.0 ip nat inside no ip route-cache ! interface Serial 1/0.302 multipoint ip address 155.1.23.3 255.255.255.0 frame-relay map ip 155.1.23.2 302 ip nat outside no ip route-cache ! ! Static NAT: translations are effectively bi-directional ! ip nat inside source static 155.1.13.1 155.1.23.1 ip nat outside source static 155.1.23.2 155.1.13.2 R2: ! ! Add a Frame-Relay mapping for the new IP (representing R1) ! so that R2 would know how to reach the address over multipoint FR interface ! interface Serial 1/0.203 multipoint ip address 155.1.23.2 255.255.255.0 frame-relay map ip 155.1.23.3 203 frame-relay map ip 155.1.23.2 203
Let’s see how it’s working. Note that we disabled route-cache on both interfaces to intercept packets via CPU.
Rack1R3#debug ip nat detailed IP NAT detailed debugging is on Rack1R3#debug ip packet detail IP packet debugging is on (detailed) Rack1R2#ping 155.1.23.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Hmm…it fails. Look at the debugging output on R3:
Rack1R3#
!
! Packet on NAT outside (o - for outside) hits the interface
!
NAT*: o: icmp (155.1.23.2, 16) -> (155.1.23.1, 16) [84]
!
! Source and destination for the packet rewritten according to NAT rules
!
NAT*: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [84]
NAT*: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [84]
!
! The packet is routed after translation (with new source and destination IPs). Note that routing decision
! and the actual forwarding take place only after translation rules were triggered by NAT tables
!
P: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
ICMP type=8, code=0
!
! The response packet from R1 comes in - to destination 155.1.13.2 - routed via RIB (to the same interface)
! But no NAT rules were triggered since the destination interface is the same as input interface!
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), routed via RIB
IP: s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), len 100, rcvd 3
ICMP type=0, code=0
OK hold here for a second.. Now we recall that for inside NAT routing is tried first, and only then the packet is translated according to the NAT rules. This is how the NAT order of operations works on the inside. So now it’s clear: IOS first tries to route packet to 155.1.13.2 – which is the same interface as it came in.. therefore the inside->outside translation never occurs! To fix this, let’s add a static route on R3:
R3: ip route 155.1.13.2 255.255.255.255 155.1.23.2
Verification:
Rack1R2#ping 155.1.23.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/33/52 ms
Rack1R3#
!
! Outside: translate & route
!
NAT*: o: icmp (155.1.23.2, 17) -> (155.1.23.1, 17) [89]
NAT*: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [89]
NAT*: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [89]
!
! Routing decision and forwarding
!
IP: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
ICMP type=8, code=0
!
! Inside: Routing decision - the packet is routed using our fixup static route
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.302), routed via RIB
!
! NAT rule (i - for inside) is triggered by the packet
!
NAT: i: icmp (155.1.13.1, 17) -> (155.1.13.2, 17) [89]
!
! Source and destination addresses rewritten in the "opposite" direction
!
NAT: s=155.1.13.1->155.1.23.1, d=155.1.13.2 [89]
NAT: s=155.1.23.1, d=155.1.13.2->155.1.23.2 [89]
!
! Packet is sent to R2 (with the new source and destination) - forwarding takes place
!
IP: s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), g=155.1.23.2, len 100, forward
ICMP type=0, code=0
Nice. So now we know the difference for sure: packets on the NAT outside are first translated and then routed. On the inside interface routing decision kicks in first and only then translation rules get applied followed by forwarding. Before we finish with that, recall new 12.3T feature called NAT Virtual Interface. With this feature we can now configure any interface as “NAT enabled” an get rid of those “inside” and “outside” domains . All NAT traffic passed through new virtual interface called NVI, in symmetric manner. Let’s reconfigure out task using this new concepts.
R3: interface Serial 1/0.301 point-to-point no ip nat inside ip nat enable ! interface Serial 1/0.302 multipoint no ip nat outside ip nat enable ! ! Remove old rules ! no ip nat inside source static 155.1.13.1 155.1.23.1 no ip nat outside source static 155.1.23.2 155.1.13.2 ! ! Add "domainless" rules ! ip nat source static 155.1.13.1 155.1.23.1 ip nat source static 155.1.23.2 155.1.13.2 no ip route 155.1.13.2 255.255.255.255 155.1.23.2
Verification:
Rack1R2#ping 155.1.23.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/40/60 ms
Rack1R3#
!
! Routing decision it taken: packet classified for NAT, since destination is in NAT table
! Note that no actual forwarding occurs, just routing decision to send packet
!
IP: tableid=0, s=155.1.23.2 (Serial1/0.302), d=155.1.23.1 (Serial1/0.302), routed via RIB
!
! Packet translated according to NAT rules (note "i" for inside NAT)
!
NAT: i: icmp (155.1.23.2, 19) -> (155.1.23.1, 19) [95]
NAT: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [95]
NAT: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [95]
!
! Another routing decision, for translated packet - now actual forwarding occurs
!
IP: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
ICMP type=8, code=0
!
! Response comes in, first routing decision - NAT table entry matched
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), routed via RIB
!
! Packet translated ("i" - inside NAT)
!
NAT: i: icmp (155.1.13.1, 19) -> (155.1.13.2, 19) [95]
NAT: s=155.1.13.1->155.1.23.1, d=155.1.13.2 [95]
NAT: s=155.1.23.1, d=155.1.13.2->155.1.23.2 [95]
!
! Another routing decision, for post-translated packet, followed by forwarding
!
IP: tableid=0, s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), routed via RIB
IP: s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), g=155.1.23.2, len 100, forward
ICMP type=0, code=0
So what’s the difference with NVI? First, we see that now NAT behaves symmetrically. Next, we see that NAT translation tables are used to take a “routing decision” to send packet to virtual interface. Packet is translated there and then another routing decision takes place, followed by packet forwarding. So the difference from the old model is that now routing decision is taken twice: before and after translation. This allows to get rid of any static routes needed by “legacy” NAT, since lookup is performed after translation.
To summarize: Domain-based NAT uses different orders of operations for inside and outside domain. NVI based NAT is symmetrical and performs routing lookup twice: first to send packet to NVI, second to route packet using the post-translated addresses.
Friday 18 December 2015
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
=====================
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
==========================
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
Subscribe to:
Posts (Atom)