OSPF Overload

Posted on August 30, 2012 by bitcourier

Overload function overview

You can configure the local routing device so that it appears to be overloaded. An overloaded routing device determines it is unable to handle any more OSPF transit traffic, which results in sending OSPF transit traffic to other routing devices. OSPF traffic to directly attached interfaces continues to reach the routing device. You might configure overload mode for many reasons, including:

If you want the routing device to participate in OSPF routing, but do not want it to be used for transit traffic. This could include a routing device that is connected to the network for analysis purposes, but is not considered part of the production network, such as network management routing devices.
If you are performing maintenance on a routing device in a production network. You can move traffic off that routing device so network services are not interrupted during your maintenance window.

You configure or disable overload mode in OSPF with or without a timeout. Without a timeout, overload mode is set until it is explicitly deleted from the configuration. With a timeout, overload mode is set if the time elapsed since the OSPF instance started is less than the specified timeout.

Following output shows a quick test result of the overload command on a standard “P” network topology of 6 core routers.

Normally, trace from P1 to P3 following the following path: P1 — P 2 — P3

p1@vr-device:p1> traceroute 192.168.5.3 source 192.168.5.1       
traceroute to 192.168.5.3 (192.168.5.3) from 192.168.5.1, 30 hops max, 40 byte packets
 1  172.22.201.2 (172.22.201.2)  0.642 ms  0.507 ms  0.286 ms
 2  192.168.5.3 (192.168.5.3)  0.486 ms  0.488 ms  0.775 ms

p1@vr-device:p1> show ospf database detail lsa-id 192.168.5.2    

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   192.168.5.2      192.168.5.2      0x80000011    24  0x22 0x3703  72
  bits 0x0, link count 4
  id 172.22.206.2, data 172.22.206.1, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 172.22.205.2, data 172.22.205.1, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 172.22.201.2, data 172.22.201.2, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 192.168.5.2, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 172.22.201.2
      Metric: 1, Bidirectional
    Type: Transit, Node ID: 172.22.205.2
      Metric: 1, Bidirectional
    Type: Transit, Node ID: 172.22.206.2
      Metric: 1, Bidirectional

When OSPF overload is enabled on P2, other routers will see all links associated with that router being advertised with an infinite metric of 65535. This will force traffic to go via an alternative path, except traffic being addressed to the overload router itself. In this case, traffic from P1 to P3 goes via P1–P4–P5–P6–P3.

[edit protocols ospf]
p2@vr-device:p2# set overload 

[edit protocols ospf]
p2@vr-device:p2# commit 
commit complete

p1@vr-device:p1> show ospf database detail lsa-id 192.168.5.2 

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   192.168.5.2      192.168.5.2      0x8000000a   353  0x22 0xea59  72
  bits 0x0, link count 4
  id 172.22.206.2, data 172.22.206.1, Type Transit (2)
    Topology count: 0, Default metric: 65535
  id 172.22.205.2, data 172.22.205.1, Type Transit (2)
    Topology count: 0, Default metric: 65535
  id 172.22.201.2, data 172.22.201.2, Type Transit (2)
    Topology count: 0, Default metric: 65535
  id 192.168.5.2, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 172.22.201.2
      Metric: 65535, Bidirectional
    Type: Transit, Node ID: 172.22.205.2
      Metric: 65535, Bidirectional
    Type: Transit, Node ID: 172.22.206.2
      Metric: 65535, Bidirectional

p1@vr-device:p1> traceroute 192.168.5.3 source 192.168.5.1  
traceroute to 192.168.5.3 (192.168.5.3) from 192.168.5.1, 30 hops max, 40 byte packets
 1  172.22.202.2 (172.22.202.2)  0.435 ms  0.752 ms  0.481 ms
 2  172.22.203.2 (172.22.203.2)  0.709 ms  0.729 ms  0.660 ms
 3  172.22.204.2 (172.22.204.2)  1.088 ms  0.685 ms  0.572 ms
 4  192.168.5.3 (192.168.5.3)  0.836 ms  0.827 ms  0.867 ms

Reference

http://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/ospf-overload-mode.html

Clear OSPF database

Posted on August 30, 2012 by bitcourier

Difference between “none” and “purse”

In Junos, “clear OSPF database” will reset the neighbor relationship, while the same command with “purge” option only refresh the database by timeout the maxage timer, and get the latest LSA updates from neighbors.

The following debug output shows the difference:

lab@PE1> show configuration protocols ospf traceoptions 
file trace-ospf;
flag lsa-update;
flag database-description;

lab@PE1> clear ospf database ?               
Possible completions:
  <[Enter]>            Execute this command
  advertising-router   Router ID of advertising router
  area                 OSPF area ID
  asbrsummary          Summary AS boundary router link-state advertisements
  external             External link-state advertisements
  instance             Name of OSPF instance
  link-local           Link local link-state advertisements
  logical-system       Name of logical system, or 'all'
  lsa-id               Link-state advertisement ID
  netsummary           Summary network link-state advertisements
  network              Network link-state advertisements
  nssa                 Not-so-stubby area link-state advertisements
  opaque-area          Opaque area-scope link-state advertisements
  purge                Purge database entries instead of deleting them
  router               Router link-state advertisements
  |                    Pipe through a command

lab@PE1> clear log trace-ospf         

lab@PE1> clear ospf database purge    

lab@PE1> show log trace-ospf          
Aug 7 00:32:29 PE1 clear-log[50901]: logfile cleared
Aug  7 00:32:33.102583 OSPF sent LSUpdate 172.22.210.1 -> 224.0.0.5 (em1.210 IFL 68 area 0.0.0.0)
Aug  7 00:32:33.102612   Version 2, length 1316, ID 192.168.1.1, area 0.0.0.0
Aug  7 00:32:33.102620   adv count 27
Aug  7 00:32:33.102684 OSPF sent LSUpdate 172.22.211.1 -> 224.0.0.5 (em2.211 IFL 70 area 0.0.0.0)
Aug  7 00:32:33.102703   Version 2, length 1316, ID 192.168.1.1, area 0.0.0.0
Aug  7 00:32:33.102714   adv count 27
Aug  7 00:32:33.102741 OSPF sent LSUpdate 172.22.210.1 -> 224.0.0.5 (em1.210 IFL 68 area 0.0.0.0)
Aug  7 00:32:33.102751   Version 2, length 1392, ID 192.168.1.1, area 0.0.0.0
Aug  7 00:32:33.102758   adv count 11
Aug  7 00:32:33.102781 OSPF sent LSUpdate 172.22.211.1 -> 224.0.0.5 (em2.211 IFL 70 area 0.0.0.0)
Aug  7 00:32:33.102791   Version 2, length 1392, ID 192.168.1.1, area 0.0.0.0
Aug  7 00:32:33.102797   adv count 11
Aug  7 00:32:33.102817 OSPF sent LSUpdate 172.22.210.1 -> 224.0.0.5 (em1.210 IFL 68 area 0.0.0.0)
---(more)---

lab@PE1> clear log trace-ospf         

lab@PE1> clear ospf database          

lab@PE1> show log trace-ospf     
Aug 7 00:33:02 PE1 clear-log[50909]: logfile cleared
Aug  7 00:33:08.102983 RPD_OSPF_NBRDOWN: OSPF neighbor 172.22.210.2 (realm ospf-v2 em1.210 area 0.0.0.0) state changed from Full to Down due to KillNbr (event reason: command to clear database was issued without purge option)
Aug  7 00:33:08.103182 RPD_OSPF_NBRDOWN: OSPF neighbor 172.22.211.2 (realm ospf-v2 em2.211 area 0.0.0.0) state changed from Full to Down due to KillNbr (event reason: command to clear database was issued without purge option)
Aug  7 00:33:08.106824 RPD_OSPF_NBRUP: OSPF neighbor 172.22.210.2 (realm ospf-v2 em1.210 area 0.0.0.0) state changed from Init to ExStart due to 2WayRcvd (event reason: neighbor detected this router)
Aug  7 00:33:08.106921 OSPF sent DbD 172.22.210.1 -> 172.22.210.2 (em1.210 IFL 68 area 0.0.0.0)
Aug  7 00:33:08.106933   Version 2, length 32, ID 192.168.1.1, area 0.0.0.0
Aug  7 00:33:08.106941   options 0x42, i 1, m 1, ms 1, seq 0xc0aad08e, mtu 1496
Aug  7 00:33:08.109438 RPD_OSPF_NBRUP: OSPF neighbor 172.22.211.2 (realm ospf-v2 em2.211 area 0.0.0.0) state changed from Init to ExStart due to 2WayRcvd (event reason: neighbor detected this router)
---(more)---

Reference

http://www.juniper.net/techpubs/software/cable/junosg30/swcmdref30/html/ospf-monitor2.html

clear ospf database <purge>

Description

Delete the entries in the OSPF link-state advertisement database.

This command is useful only for testing. Use it with care because it causes significant network perturbation.

Options

none—Discard all link-state advertisements (LSAs) other than the system’s own (the system’s own link-state advertisements are regenerated). To resynchronize the database, all adjacent neighbors that are in the state EXSTART or higher are destroyed. They will be reacquired and the databases will be synchronized again.

purge—(Optional) Discard all entries in the link-state advertisement database; that is, all link-state advertisements are set to MAXAGE and are flooded. The database will be repopulated when the originators of the link-state advertisements receive the MAXAGE link-state advertisements and reissue them.

OSPF route selection process

Posted on August 20, 2012 by bitcourier

Task

Lab a multi-area OSPF network to demonstrate the OSPF route selection process between intra-area and inter-area routes. Through the lab, we will show that the actual path that packets take from the source to the destination routers could be different from the shortest path associated with the smallest end-to-end total costs calculated by the source router.

Topology

Given the above diagram, and the link metrics, what the path a packet takes from R1 to R6 is?

Configuration

I use a single router, with multiple routing instances to simulate this network topology. Router instances are linked via a hair-pin connection from interface em1 to em2. For example, we use VLAN12 to link between em1.12 of instance r1 to em2.12 of instance r2

Router configuration on routers are straight forward, similar to the one below for r1:

instance-type virtual-router;
interface em1.12;
interface em1.13;
interface lo0.1;
routing-options {
    router-id 1.1.1.1;
}
protocols {
    ospf {
        area 0.0.0.123 {
            interface em1.12 {
                metric 20;
            }
            interface em1.13 {
                metric 5;
            }
            interface lo0.1 {
                passive;
            }
        }
    }
}

Verification

The OSPF metric for the Summary Route 6.6.6.6/32 as seen by R1 as 25, which is is the sum of all link metrics along the shortest path R1-R3-R2-R4-R5-R6. However, the path that traffic actually takes is driven by the destination based principle, and OSPF route selection rule by individual router. This could be (and in this case it is actually) different from the best path seen by the Source Router. The actual path that traffic takes is R1-R3-R2-R4-R6.

lab@vr> show ospf database instance r1 detail netsummary lsa-id 6.6.6.6 

    OSPF database, Area 0.0.0.123
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary  6.6.6.6          2.2.2.2          0x80000008  1341  0x22 0xc046  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 15
Summary  6.6.6.6          3.3.3.3          0x8000000a  1341  0x22 0xd02b  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 20

lab@vr> show route table r1.inet.0 6.6.6.6 

r1.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

6.6.6.6/32         *[OSPF/10] 00:18:11, metric 25
                    > to 13.0.0.3 via em1.13

lab@vr> traceroute routing-instance r1 6.6.6.6 source 1.1.1.1    
traceroute to 6.6.6.6 (6.6.6.6) from 1.1.1.1, 30 hops max, 40 byte packets
 1  13.0.0.3 (13.0.0.3)  0.958 ms  0.447 ms  0.373 ms
 2  23.0.0.2 (23.0.0.2)  0.462 ms  0.474 ms  0.646 ms
 3  24.0.0.4 (24.0.0.4)  0.775 ms  0.771 ms  0.533 ms
 4  6.6.6.6 (6.6.6.6)  0.852 ms  1.076 ms  1.176 ms

Likewise, the actual path taken for the return traffic from R6 to R1 is via R6-R5-R4-R2-R1, resulting in an asymmetric routing, even though the topology is very symmetric.

lab@vr> traceroute routing-instance r6 1.1.1.1 source 6.6.6.6    
traceroute to 1.1.1.1 (1.1.1.1) from 6.6.6.6, 30 hops max, 40 byte packets
 1  56.0.0.5 (56.0.0.5)  0.540 ms  0.425 ms  0.417 ms
 2  45.0.0.4 (45.0.0.4)  0.520 ms  0.525 ms  0.505 ms
 3  24.0.0.2 (24.0.0.2)  0.718 ms  0.794 ms  0.782 ms
 4  1.1.1.1 (1.1.1.1)  0.692 ms  0.709 ms  0.685 ms

The path traffic takes are shown the the below picture:

This is because when traffic from R1 toward R6 reaches R4, it goes directly to R6, due to the router prefers the direct R4-R6 Intra-Area route (in Area 456), than the Inter-Area route via R5, even though that the Intra-Area route is longer!

lab@vr> show ospf database instance r4 detail lsa-id 6.6.6.6    

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary *6.6.6.6          4.4.4.4          0x80000004  1805  0x22 0xbe3f  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 20
Summary  6.6.6.6          5.5.5.5          0x80000004  1801  0x22 0xafe   28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 5

    OSPF database, Area 0.0.1.200
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   6.6.6.6          6.6.6.6          0x80000022  1801  0x22 0xeebe  60
  bits 0x0, link count 3
  id 46.0.0.6, data 46.0.0.6, Type Transit (2)
    Topology count: 0, Default metric: 20
  id 56.0.0.6, data 56.0.0.6, Type Transit (2)
    Topology count: 0, Default metric: 5
  id 6.6.6.6, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 56.0.0.6
      Metric: 5, Bidirectional          
    Type: Transit, Node ID: 46.0.0.6
      Metric: 20, Bidirectional

Note

OSPF route selection process is as follows:

Intra-area routes are preferred over inter-area or external routes, regardless of their cost.
Inter-area routes are preferred over external routes.
External type 1 (E1) routes are preferred over external type 2 (E2).

More on routes selection between external routes, see the article “OSPF route selection rules” at http://blog.ioshints.info/2008/01/e1-and-e2-routes-in-ospf.html

OSPF NSSA Area, and Summarization

Posted on August 15, 2012 by bitcourier

Network Topology

Task

In this lab, we will practice configuration of OSPF routing with a NSSA area, summarisation of the external and internal routes.

Instead of advertising individual external routes 3.3.x.0/24, we will advertise them as a single /22 into area 0. Also we will advertise 23.0.0.0/8 as a summary internal route for the area 1 between Router 2 and Router 3.

Configuration & Verification

lab@R2# show 
area 0.0.0.0 {
    interface em1.0;
}
area 0.0.0.1 {
    nssa;
    area-range 23.0.0.0/8;
    interface em2.0;
}

Note that the summary route that R1 receive 23.0.0.0/8 instead of /24.

lab@R1# run show route protocol ospf         

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3.3.1.0/24         *[OSPF/150] 00:03:49, metric 0, tag 0
                    > to 12.0.0.2 via em1.0
3.3.2.0/24         *[OSPF/150] 00:03:49, metric 0, tag 0
                    > to 12.0.0.2 via em1.0
3.3.3.0/24         *[OSPF/150] 00:03:49, metric 0, tag 0
                    > to 12.0.0.2 via em1.0
23.0.0.0/8         *[OSPF/10] 00:01:53, metric 2
                    > to 12.0.0.2 via em1.0
224.0.0.5/32       *[OSPF/10] 00:13:10, metric 1
                      MultiRecv

This command can not apply to External routes that are advertised (i.e. “exported” from the routing table) into OSPF. In other words, the following command will not produce the 3.3.0.0/16 summary route into Area 0.

[edit protocols ospf]
lab@R2# set area 1 area-range 3.3.0.0/16

lab@R1# run show route protocol ospf     

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3.3.1.0/24         *[OSPF/150] 00:08:44, metric 0, tag 0
                    > to 12.0.0.2 via em1.0
3.3.2.0/24         *[OSPF/150] 00:08:44, metric 0, tag 0
                    > to 12.0.0.2 via em1.0
3.3.3.0/24         *[OSPF/150] 00:08:44, metric 0, tag 0
                    > to 12.0.0.2 via em1.0
23.0.0.0/8         *[OSPF/10] 00:06:48, metric 2
                    > to 12.0.0.2 via em1.0
224.0.0.5/32       *[OSPF/10] 00:18:05, metric 1
                      MultiRecv

Instead, summarisation of external route in NSSA is achieved with the following NSSA specific command:

[edit protocols ospf]
lab@R2# set area 1 nssa area-range 3.3.0.0/16 

lab@R2> show configuration protocols ospf   
area 0.0.0.0 {
    interface em1.0;
}
area 0.0.0.1 {
    nssa {
        area-range 3.3.0.0/16;
    }
    area-range 23.0.0.0/8;
    interface em2.0;
}

lab@R1# run show route protocol ospf    

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3.3.0.0/16         *[OSPF/150] 00:00:15, metric 1, tag 0
                    > to 12.0.0.2 via em1.0
23.0.0.0/8         *[OSPF/10] 00:08:36, metric 2
                    > to 12.0.0.2 via em1.0
224.0.0.5/32       *[OSPF/10] 00:19:53, metric 1
                      MultiRecv

lab@R1> show ospf database summary 
Area 0.0.0.0:
   2 Router LSAs
   1 Network LSAs
   1 Summary LSAs
   1 ASBRSum LSAs
Externals:
   1 Extern LSAs
Interface em1.0:
Area 0.0.0.0:

lab@R1> show ospf database            

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router  *1.1.1.1          1.1.1.1          0x80000004  1222  0x22 0x8a83  36
Router   2.2.2.2          2.2.2.2          0x80000005   115  0x22 0x53ad  36
Network *12.0.0.1         1.1.1.1          0x80000001  1226  0x22 0x61bb  32
Summary  23.0.0.0         2.2.2.2          0x80000005   115  0x22 0x23f5  28
ASBRSum  3.3.3.3          2.2.2.2          0x80000001   823  0x22 0xbe68  28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Extern   3.3.0.0          2.2.2.2          0x80000001   115  0x22 0x8320  36

Packet Corner

Think like a router!

Category Archives: OSPF

OSPF Overload

Overload function overview

Reference

Clear OSPF database

Difference between “none” and “purse”

Reference

OSPF route selection process

Task

Topology

Configuration

Verification

Note

OSPF NSSA Area, and Summarization

Network Topology

Task

Configuration & Verification

Reference