BGP Regular Expressions - explained with the examples


REMINDER of the META Characters

^ - START of Line
$ - END of Line
| - Logical OR
_ - ANY DELIMETER
? - ZERO instances of the PRECEDING character
* - ZERO OR MODE instances of the PRECEDING character
+ - ONE OR MORE instances of the PRECEDING character
(x) - Combine the enclosed String as a single entity
[x] - Wildcard where any position can match the position in AS-Path
. - Any Character


EXAMPLES

_65505$ - Prefixes that END with the AS 65505, meaning - they were originated by that AS

_65505_ - Prefixes that traversed the AS 65505

^$ - Locally Originated Prefixes (START and END of the line)

.* - ANY prefix (zero or more instances of ANY character)

^[0-9]+$ - All the prefixes from DIRECTLY CONNECTED ASs (meaning - they have only 1 AS in the AS PAth)


BEFORE CREATING THE AS-PATH ACL

If you want to STOP using the recursive algorithm in order to be able to control more complex  regular expressions

(config-router)#bgp regexp deterministic

Now you can actually DISPLAY the prefixes that match your condition in the AS-PATH before defining the AS-PATH ACL

#show ip bgp regexp REGULAR_EXPRESSION

*There is a TRICK here, you need to add a MEMORY location you want to temporarily place thhe results, so instead of the expression ^300$ you would have to type:

#show ip bgp regexp (^300$)(_\1)*$

You can also display the Filter List before applying it to the neighbor:

#show ip bgp filter-list 1

BGP Filters: Distribution and Prefix lists


The main difference between applying the DISTRIBUTE list and the PREFIX list to the BGP neighbor is:

- DISTRIBUTE LIST: You need to define the ACL, and apply it in the form of a Distribution List:

(config)#access-list 1 deny 172.12.25.0 0.0.0.255
(config-router)#neighbor 5.5.5.5 distribute-list 1 in

- PREFIX LIST: You define the PREFIX list, and apply the same prefix list to the BGP neighbor

(config-router)#neighbor 5.5.5.5 prefix-list PREF_LIST in

BGP: Advanced Tuning using the known Attributes


BGP is all about tuning. The non-tuned BGP is basically a RIP, but once you adjust it to your needs - no other routing protocol can come even close.

The basic and well-known BGP Tuning Attributes are:


1. AS-Path (The less ASs in the path - the Better)

Used to influence another AS by adding or PREPENDING the AS's to the prefix using the Route Map.

You can do a pretty granular control here using the AS-PATCH Access Lists. You do need a basic knowledge of TCL for this, so basically if you need to match all the prefixes that pass threw the AS 65505 you do this:

(config)#ip as-path access-list 10 permit ^65505$ <--- you can go wild with the filters
*in this case we are filtering the prefixes origineted and advertised directly by AS 200


The AS-PATH ACL can also be applied to a neighbor as a FILTER-LIST

(config-router)#neighbor 172.25.185.45 filter-list 10 in



REMINDER of the META Characters:

^ - START of Line
$ - END of Line
| - Logical OR
_ - ANY DELIMETER
? - ZERO instances of the PRECEDING character
* - ZERO OR MODE instances of the PRECEDING character
+ - ONE OR MORE instances of the PRECEDING character
(x) - Combine the enclosed String as a single entity
[x] - Wildcard where any position can match the position in AS-Path
. - Any Character

After this you just match this condition in the route-map in order to set some parameter later:

(config-route-map)#match as-path 10


2. Weight (the Higher - the Better)

It's a CISCO Proprietary Attribute, Used ONLY LOCALY to influence the LOCAL AS by assigning the WEIGHT attribute to prefixes announced from a BGP Neighbor

First you need to set up the route-map. You can use the MATCH condition, but you dont have to. In this case we will apply the weight to all the prefixes announced by a neighbor.

route-map SET_WEIGHT permit 10
 match ...
 set weight 500

And now apply the route-map to a neighbor in the INBOUND direction (prefixes coming IN, meaning - are announced by that neighbor):

router bgp 65535
 neighbor 172.21.12.2 remote-as 64500
 neighbor 172.21.12.2 route-map SET_WEIGHT in

Or you can simply apply the WEIGHT attribute to the neighbor directly:

router bgp 65535
 neighbor 172.21.12.2 remote-as 64500
 neighbor 172.21.12.2 weight 500

3. MED (Multi Exit Discriminator) Attribute; RFC 1771 - Optional and Non-Transitive; The Smaller the Better

This is the most similar Attribute to the OSPF Metric that there is in BGP. The nature of this attribute is similar to the AS-Path, because they are both used to influence the other AS by tuning the attributes of the Locally Originated&Advertised Prefixes
You can simply set it (set metric X) within the route-map configuration, and apply it to the BGP Neighbor in the OUTBOUND direction

If you wish to RE-ARRANGE the Attribute Comparison order, and for example wish to compare the MED value before the AS-Path (meaning - prefer the lower MED, regardless of the AS-Path), you can use this command under the BGP configuration:

(config-router)#bgp always-compare-med <--- to compare MED value even if there is higher ranked attribute that decides
(config-router)#bgp bestpath as-path ignore <--- to IGNORE the AS-Path attribute, HIDDEN COMMAND on IOS!!!
*BE CAREFULL with the second command, the TAB key will not work and the "?" will not show you the "as-path" option

By default the MISSING MED value is considered the BEST one because on most IOS-s it picks up the value 0. To change this use:

(config-router)#bgp bestpath med missing-as-worst <--- Treat the non-defined MED as the WORST

BGP Community Attribute


Community attribute is one of those non-standard BGP attributes that you really need to know well if you wish to use it. The big advantage is that from time to time you will just swoop in and solve a big architecture problem your colleague Network Engineers are having. The down side is that it's a bit tacky. For example, these are the communities you can set within the route-map configuration>

Cisqueros_R1(config-route-map)#set community ?
  <1-4294967295>  community number
  aa:nn           community number in aa:nn format
  additive        Add to the existing community
  internet        Internet (well-known community) <--- ADVERTISE these networks
  local-AS        Do not send outside local AS (well-known community) <--- ONLY advertise within the AS
  no-advertise    Do not advertise to any peer (well-known community) <--- The neighbor will not advertise what was matched to neither eBGP nor iBGP neighbors
  no-export       Do not export to next AS (well-known community) <--- Like previous, but ONLY for eBGP
  none            No community attribute
  <cr>


*IMPORTANT: Do not forget to actually SEND the community to the neighbor, otherwise your configuration will not work!!!

 (config-router)#neighbor x.x.x.x send-community

You can of course apply the BGP community attributes on the INBOUND and OUTBOUND direction, where you automatically override the existing value.

Besides these well-known community values, you can also assign a random community number and use them later as BGP TAGS.

BGP Conditional Advertisements - Advertise Maps


This is a pretty complex BGP issue because you really need to know the BGP philosophy and maybe even have some basic experience in programming. The trick is to change the behavior of the BGP advertisements depending on the routes that are being learned.

router bgp 65545
 neighbor 172.25.13.3 advertise-map ADV_ROUTE_MAP non-exist-map CONDITION_ROUTE_MAP

Intuitively we can see that the ADV_ROUTE_MAP is the route map that defines the routes that will be broadcast, in this case if the conditions defined in the route-map CONDITION_ROUTE_MAP is NOT satisfied, meaning - if the prefixes are NOT in the table.



BGP Backdoor Route


When you need to prefer LESS the eBGP route - you need a way to tune it, because not many routing protocols "beat" the eBGPs Administrative Distance (20). The "backdoor" argument sets the routes AD to 200 (like it were an iBGP instead of eBGP route), and alters the order of preference in the routing table.

It's quite easy to configure - you configure a regular network using a "network" command, but add a "backdoor" argument at the end.
*BE CAREFUL!!! The BACKDOOR argument is applied to the network advertised TO YOU, not from you like in the normal "network" command application

(config-router)#network 150.1.3.0 mask 255.255.255.0 backdoor 

Note that you will not SEE this route in the routing table unless the route with the bigger AD is down.

BGP Route Reflectors

First of all, why was the concept of Route Reflectors introduced? It´s quite simple actually. If there is no Route Reflector in the iBGP Network - the prefixes are advertised to the first iBGP neighbor, and that's it, he will not advertise it to the next iBGP neighbor due to the BGP inter protocol loop prevention mechanism. What can we do? We have 2 options:
1. Do a full mesh between all the iBGP neighbors, so that all the prefixes of each router are advertised to each and every one of the other BGP routers separately.
2. Introduce a concept of Route Reflector.

As explained below, like the BGP Confederations - Route Reflectors remove the need for a full-mesh iBGP peering. They let all the routers learn all the iBGP routes (prefixes), and they propagate those prefixes to the other iBGP neighbors, not causing loops in the network. There are 2 types of Route Reflector routers, and they are decided based on  their role in the network. These are Route Reflector SERVER and CLIENT.

Route Reflector SERVER- are allowed to learn the iBGP routes from their CLIENTS, and advertise them to other iBGP peers
*RR Servers act as normal BGP peers with the NON-RR-CLIENT peers and the eBGP peers, meaning - they send all the BGP Updates

Route Reflector CLUSTER - One or more RR Servers and their clients. With MULTIPLE Clusters - at least one of the RRs must be peered with at least one RR in Each Cluster.

There are 3 implemented Loop Prevention Mechanisms:

1. CLUSTER_LIST - The Cluster ID is automatically included into the BGP PA when generated, so the RR rejects the prefixes where their own Cluster ID appears

2. ORIGINATOR_ID - The PA that lists the RID of the first iBGP peer to advertise the route into the AS.

3. Only advertise BEST routes

The configuration is rather simple, and it contains of 2 steps:

Step 1: Define the CLUSTER ID on ALL the routers (in this Example it's 3)

(config-router)#bgp cluster-id 3

Step 2: There is a difference between the RR SERVER and RR CLIENT (under the BGP configuration):

On RR SERVER configure ALL the clients:

(config-router)#neighbor 172.25.185.22 route-reflector-client
(config-router)#neighbor 172.25.186.59 route-reflector-client

Check the status of each Client on the RR SERVER ROUTER:

Cisqueros_R1#show ip bgp neighbors 172.25.185.22 | i Reflector
  Route-Reflector Client
Cisqueros_R1#

*DONT forget to remove the iBGP sessions between CLIENTS, because... well, thats the point of implementing the RRs, to decrease the number of BGP peerings
The Route Reflector will "reflect" the routes received from one iBGP peer to the others.

Have in mind that the RR is a single point of failure in the Network, so - BEST PRACTICE is to have MULTIPLE RR SERVERS

BGP Authentication


It's configured on PER-NEIGHBOR, or as described in the Previous Post - on the PER-PEER-GROUP basis.

 (config-router)#neighbor CISQUEROS password cisco

From Jeff Doyle's ROUTING TCP/IP Vol2 (Routing Bible in my opinion, even though I hope it gets updated soon, is't been 12 years!):

The IOS uses MD5 authentication when a BGP neighbor password is configured. MD5 is a one-way message digest or secure hash function produced by RSA Data Security, Inc. It also is occasionally referred to as a cryptographic checksum, because it works in somewhat the same way as an arithmetic checksum. MD5 computes a 128-bit hash value from a plain-text message of arbitrary length (in this case, a BGP message) and a password. This "fingerprint" is transmitted along with the message. The receiver, knowing the same password, calculates its own hash value. If nothing in the message has changed, the receiver's hash value should match the sender's value transmitted with the message. The hash value is impossible to decipher (without a huge amount of computing power) without knowing the password so that an unauthorized router cannot, either maliciously or by accident, peer with a router running neighbor authentication.

BGP peer-group


It's a simple concept, just a group of neighbors we want to configure with the same group of parameters. It's defined in 3 steps:

1. Define/Configure the Peer Group

 (config-router)#neighbor CISQUEROS peer-group 

2. Add the individual neighbors into the configured peer group

 (config-router)#neighbor 2.2.2.2 peer-group CISQUEROS
 (config-router)#NEIghbor 3.3.3.3 PEER-group CISQUEROS

Expect the following message:

*May  5 10:13:21.395: %BGP_SESSION-5-ADJCHANGE: neighbor 3.3.3.3 IPv4 Unicast topology base removed from session  Member added to peergroup
*May  5 10:13:21.395: %BGP-5-ADJCHANGE: neighbor 3.3.3.3 Down Member added to peergroup
*May  5 10:13:22.283: %BGP-5-ADJCHANGE: neighbor 3.3.3.3 Up 

Both neighbors remain UP!

3. Apply the set of parameters to the Peer Group, and the parameters will apply to each of the Peers. For example, lets configure the Password:

 (config-router)#neighbor CISQUEROS password cisco

BGP "no sync" and "no auto-summary"


Two first things that are considered the "BGP configuration best practice" are to disable the SYNCHRONIZATION and disable the Auto Summarization. Why?

Auto-summary - to enable the CLASSLESS BGP behavior

 (config-router)#no auto-summary

Synchronization - it's an old loop prevention mechanism that is no longer used, so there is no need to have it enabled. In the newer versions of IOS it's disabled by default.
It was originally created to preven the BLACK HOLE Advertising. Basically the SYNC Logic is: Do not consider an iBGP route in the BGP table BEST unless the EXACT PREFIX was learned via IGP and is currently in the routing table.

 R2(config-router)#no synchronization

*TIP: When using OSPF and BGP in the same Network - use the same Router ID due to the Sync Logic!


Once you've got the neighbors configured using the "neighbor" command, you should be able to identify the outputs:

(config-router)#do show ip bgp summary
BGP router identifier 192.168.2.2, local AS number 100
BGP table version is 5, main routing table version 5
4 network entries using 480 bytes of memory
4 path entries using 208 bytes of memory
2/2 BGP path/bestpath attribute entries using 248 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 936 total bytes of memory
BGP activity 4/0 prefixes, 4/0 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
100.11.1.1        4          100       9       9        5    0    0 00:05:23        1
100.11.1.3        4          100       9       9        5    0    0 00:05:12        1
100.11.1.4        4          100       8       8        5    0    0 00:04:57        1

(config-router)#do show ip bgp <--- ONLY iBGP in this case
BGP table version is 5, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.0.0.0          10.1.1.1                 0    100      0 i
*> 2.0.0.0          0.0.0.0                  0         32768 i
*>i3.0.0.0          10.1.1.3                 0    100      0 i
*>i4.0.0.0          10.1.1.4                 0    100      0 i

 * - The entry in the table is valid

 > - It's the BEST entry for that prefix

 i - learned via iBGP

 (config-router)#do show ip bgp <--- ONLY eBGP in this case
BGP table version is 5, local router ID is 192.168.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  1.0.0.0          10.1.1.1                               0 300 100 i
*                       10.1.1.1                               0 200 100 i
*>                     10.1.1.1                 0             0 100 i
*  2.0.0.0          10.1.1.2                               0 100 200 i
*                       10.1.1.2                               0 300 200 i
*>                     10.1.1.2                 0             0 200 i
*> 3.0.0.0         10.1.1.3                 0             0 300 i
*> 4.0.0.0         0.0.0.0                  0         32768 i


Notice that the PATH is no longer marked as "i" for iBGP, but it shows an entire AS-PATH now (list of all the BGP Autonomous Systems the route needs to pass in order to reach the route)

Also Local Preference is no longer marked as 100 (default for iBGP)

OSPF Non-Broadcast Multiple-Access (NBMA) Networks


On the Multipoint Frame-Relay network the default OSPF type is NON-BROADCAST. This means that the OSPF Neighbors will not be formed like on the standard Broadcast Network Segment.

 Cisqueros_R1#show ip ospf inter s1/0
 Serial1/0 is up, line protocol is up 
   Internet Address 10.1.1.1/24, Area 0 
   Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64
   Topology-MTID    Cost    Disabled    Shutdown      Topology Name
         0           64        no          no            Base
        ...
        
So in order to establish the OSPF Neighbors, we can for example use the "network" command in order to transform the OSPF link from MULTICAST to UNICAST

 (config-router)#neighbor 172.128.185.66

*In HUB-AND-SPOKE the Spokes do not have the Layer 2 reachability, so this command makes no sense. Instead just be sure to set their OSPF priority to 0, so that they dont participate the DR/BDR Election

 (config-if)#ip ospf priority 0

 The HUB Router will be elected as DR on every Link and exchange OSPF Database with each of the Spokes:

 Cisqueros_R1#show ip ospf neighbor <--- R1 IS THE HUB

 Neighbor ID     Pri   State           Dead Time   Address         Interface
 2.2.2.2           0   FULL/DROTHER    00:01:51    10.1.1.2        Serial1/0
 3.3.3.3           0   FULL/DROTHER    00:01:51    10.1.1.3        Serial1/0
 4.4.4.4           0   FULL/DROTHER    00:01:56    10.1.1.4        Serial1/0

*In this kind of OSPF Topology - it's not necessary to have the Frame-Relay interface configured with the "broadcast" keyword, because we are manually defining the OSPF Neighbor and turning the Links into UNICASTS.


OSPF BROADCAST Networks v.s. POINT-TO-POINT Networks

If you wish to convert the previous network into the Broadcast Network, the following command needs to be applied:

 (config-if)#ip ospf network broadcast

And in case it needs to be Point-to-Point:

 (config-if)#ip ospf network point-to-point

The main difference here is the NEXT HOP:
 BROADCAST: Next Hop is the router that ORIGINATED the Route
 POINT-TO-POINT: Next Hop is the router that ADVERTISED the Route

OSPF Route Filtering


First be sure which type of LSA you need to filter by making sure in which part of database the route is:

#show ip ospf database [router | network | summary | internal | external]

There are 5 ways to perform OSPF Route Filtering:

1. DISTRIBUTE LIST - Filters all LSAs from the Routing Table, but they stay in the OSPF Database
!!!distribute-list OUT works on both, routing table and OSPF database, but ONLY on ASBR for LSA5 and 7!!!
2. FILTER LIST - Filters only LSA3, so - only on ABR, but filters from OSPF Database.
filter-list can be applied: IN - into the area, OUT - out of the area
3. NOT-ADVERTISE - ONLY filter LSA Types 1 and 2, apply on ABR (filters both, routing table and OSPF Database)
Can be used with both, "area X range" (ABR) and "summary-address" (ASBR) commands
4. DISTANCE - Set the AD of the advertised routes to 255, so that they are UNREACHABLE
(config-router)#distance 255 3.3.3.3 0.0.0.0 10 <- 10 is an ACL
5. DATABASE-FILTER - If you want to prevent ANY LSAs from being advertised (can be applied per neighbor or on INT):
(config-subif)#ip ospf database-filter all out <- PER INTERFACE
(config-router)#neighbor x.x.x.x database-filter all out <- PER NEIGHBOR

Be sure which type of LSA you need to filter by making sure in which part of database the route is:
#show ip ospf database [router | network | summary | internal | external]

The easiest way to filter the OSPF routes from being added to the Routing Table is the distribute-list.
!!!DISTRIBUTE-LIST only affects the local router!!! Meaning - the Update will be distributed to the other routers, the subnets will only be filtered out the local IP ROUTING TABLE
The advantage is that it's rather easy to implement, and it can filter any type of LSA:
(config-router)#distribute-list prefix MY_PREFIX_LIST in <--- OUT would only work on ASBR TO FILTER LSA5 & LSA7

The big CON is that even though the Route is not added to the Routing Table - it will stay in the database,
and it will be further propagated to the other OSPF Neighbors. The route will therefore appear in the Routing Table,but it will not be reachable, as one of the routers along the path does not have it in it's Routing Table.

*If you need to reach the route without passing through the router that cannot reach it - define the route-map with the next hop pointing towards an alternative path, and apply it in the Global Configuration mode:
(config-router)#ip local policy route-map ROUTE_MAP

Filter using Distribute List

The easiest way to filter the OSPF routes from being added to the Routing Table is the distribute-list. The advantage is that it's rather easy to implement, and it can filter any type of LSA:

Cisqueros_R2(config-router)#distribute-list prefix MY_PREFIX_LIST in <--- OUT would only work on OSBR TO FILTER LSA5 & LSA7

The big CON is that even though the Route is not added to the Routing Table - it will stay in the database, and it will be further propagated to the other OSPF Neighbors.
The route will therefore appear in the Routing Table, but it will not be reachable, as one of the routers along the path does not have it in it's Routing Table.

*If you need to reach the route without passing through the router that cannot reach it - define the route-map with the next hop pointing towards an alternative path, and apply it in the Global Configuration mode:

(config-router)#ip local policy route-map ROUTE_MAP


OSPF filter-list - LSA-3 FILTERING

This ONLY works for LSA-3 (Summary), and therefore needs to be configured on the ABR only. Lets say that we want to filter the network 172.25.185.0/24 from the Area 2. Then on the ABR we define the prefix list that DENIES that network, and ALLOWS everything else

(config)#ip prefix-list JEDANES seq 10 deny 172.25.185.0/24
(config)#ip prefix-list JEDANES seq 20 permit 0.0.0.0/0 le 32

Then apply the prefix-list as a filter-list within a OSPF configuration process for Area 2:

(config-router)#area 2 filter-list prefix JEDANES in 

This will prevent the network from being redistributed into Area 2. Note that IN/OUT means that the network is being advertised into or out-from the AREA 2


OSPF "not-advertise" LSA1 & LSA2 FILTERING

If you need to filter LSAs 1 and 2, you can use the "not-advertise" command, but also ONLY ON ABR!

(config-router)#area 1 range 172.25.182.0 255.255.255.0 not-advertise


Tune the ADVERTISED DISTANCE to Filter the Prefix

Another way to filter the OSPF networks is manually setting the distance to 255, which is UNREACHABLE. It's not the most elegant way, but you should know that it's also an option.

Cisqueros_R4(config-router)#distance 255 3.3.3.3 255.255.255.0 10 <--- 10 IS AN ACCESS-LIST WITH THE PREFIXES WE WANT TO FILTER



Filter EXTERNAL OSPF Routes: LSA5 & LSA7

The first way to filter there routes was already mentioned above:

Cisqueros_R2(config-router)#distribute-list prefix MY_PREFIX_LIST OUT


The second way is reserved ONLY for the External Routes, and it's the "not-advertised" applied to the "summary-address" command

(config-router)#summary-address 172.29.189.0 255.255.255.0 not-advertise <--- MUST BE APPLIED ON ASBR


Filter OSPF per Interface

If you wish to prevent LSAs to be sent via particular Interface:

(config-if)#ip ospf database-filter all out

*ALL and OUT are the only options, which means you cannot apply a specific filter on the OSPF interface


Filter OSPF per NEIGHBOR

Even though OSPF doesn't require that we manually configure the Neighbors, we do need to use the "neighbor" command in order to configure the OSPF database filtering:

(config-router)#neighbor 5.5.5.5 database-filter all out

*Network MUST be configured as POINT-TO-POINT (on the Interface Configuration)

OSPF Stub Area Types


First lets make sure we're comfortable with the LSA types, because you will not understand Stubs before you understand LSAs 100%

*LSA - Link State Advertisement, Each LSA has a LSID (Link State ID, like Router-ID for the LSAs)

LSA 1 - Router LSA, One per Router (Generated by Each Router)
LSA 2 - Network LSA, One per Network (Generated by DR)
LSA 3 - Summary LSA, One per Area (generated by ABR when LSAs 1 and 2 are injected into another Area). LSA3 = Subnet + Mask + Cost to reach the Network
LSA 4 - Summary External LSA, One per Autonomous System (Generated by ASBR)
LSA 5 - External LSA, Injected into OSPF from another routing process (non-ospf)
LSA 6 - Grout Membership LSA, Not supported by Cisco
LSA 7 - NSSA External, Generated by ASBR inside the NSSA instead of LSA 5 (details explained below, NSSA Section)
LSA 8-11 - Not implemented by Cisco

Check the LSA Statistics using the command:

Cisqueros_R3(config-router)#do show ip ospf stat

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

  Area 0: SPF algorithm executed 4 times

  Summary OSPF SPF statistic

  SPF calculation time
Delta T   Intra D-Intra Summ    D-Summ  Ext     D-Ext   Total   Reason
00:22:26   0    0       0       0       0       0       0       R
00:22:16   0    0       0       0       0       0       0       R
00:21:47   0    0       0       0       0       0       0       R, N, SN
00:20:01   0    0       0       0       0       0       0       R, SN



Check the OSPF DATABASE and all the LSAs currently in it:

Cisqueros_R3#show ip ospf database 

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

                Router Link States (Area 0) <--- LSA1

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         79          0x80000003 0x000E94 2
3.3.3.3         3.3.3.3         78          0x80000007 0x006F2C 4
4.4.4.4         4.4.4.4         52          0x80000004 0x007781 3

                Net Link States (Area 0) <--- LSA2

Link ID         ADV Router      Age         Seq#       Checksum
10.1.23.3       3.3.3.3         78          0x80000001 0x00658F

                Summary Net Link States (Area 0) <--- LSA3

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.0         2.2.2.2         124         0x80000002 0x00B33C
2.2.2.0         2.2.2.2         124         0x80000002 0x000D20
10.1.12.0       2.2.2.2         124         0x80000002 0x00BA22
10.1.45.0       4.4.4.4         43          0x80000001 0x00F5F4
44.4.4.0        4.4.4.4         43          0x80000001 0x008077
          
                Router Link States (Area 1) <--- LSA1, Area 1

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         89          0x80000007 0x00AC78 0

                Router Link States (Area 2) <--- LSA2, Area 1

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         90          0x80000006 0x00AE77 0



STUB - No LSA 5 (E1 and E2) advertised on ABRs. You cannot use a Virtual Link here, but GRE Tunnel is an option.

Totally Stubby Area - Stub without the Summary Routes (LSA3), so no Intra-Area (IA O). Only Route and Network LSAs (LSA1 and LSA2) within the Area
The "no-summary" attribute is ONLY necessary on ABR, because the ABR is the only router that actually originates the LSA 3.

* STUB and Totally Stubby Area: DO NOT FORGET to configure the "area X stub" on all the routers in the Area X. The routers that ONLY belong to the Area X will BY DEFAULT get the Default Route injected with the ABR as a Default Gateway.

NSSA - LSA3 and LSA7 copied into LSA5 (External, E1 and E2)
* ASBR Generates LSA 7 instead of LSA 5 because the LSA 5 is not supported by NSSA. Then the ABR transforms it into LSA 5 on the ingress from NSSA to the regular OSPF Area.

Totally Stubby NSSA - No Summary (LSA3), but External Routes Included (LSA5)

GRE Tunnel used as a OSPF Virtual-Link


GRE - Generic Routing Encapsulation, is a method of tunneling data from one router to another. Packets of one routing protocol - PASSANGER PROTOCOL are being encapsulated into another routing protocol - TRANSPORT PROTOCOL.

In this example there is a need to establish the connectivity between some OSPF Areas that are not connected to the Area 0, and we do not want to use the Virtual Links.
GRE is a pretty simple concept, you need to configure the following on the BOTH ENDS of the tunnel:

 1. Create a Tunnel Interface and assign the IP Address

    (config)#int tunnel 1
    (config-if)#ip add 172.25.185.3 255.255.255.0

 2. Define the SOURCE and the DESTINATION of the tunnel

   (config-if)#tunnel source 100.10.34.3
   (config-if)#tunnel destination 100.10.34.4

If we are using OSPF then the Tunnel subnet needs to be advertised with the "network" command on both ends of the tunnel.

   (config-router)#network 172.25.185.0 0.0.0.255 area 0

*The IP Address of the Tunnel MUST be advertised into Area 0!!!

You will see that the OSPF Neighbor will be formed on the Tunnel 1 interface.

Cisqueros_R4#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           0   FULL/  -        00:00:38    172.25.185.3    Tunnel1 <--- GRE-Neighbor
3.3.3.3           0   FULL/  -        00:00:38    100.10.34.3       Serial1/0.43
5.5.5.5           1   FULL/DR         00:00:38    100.10.45.5       GigabitEthernet5/12

OFPF Cost Tuning


NLRI - Network Layer Reachability Information

OSPF routes are mainly classified based on their metric, where the Metric and Cost are calculated based only on the Link Bandwidth.

Cost = 100/(BW[Mbps])

There are two things you could play with here:

 1. Set the REFERENCE BW (because with the formula above the Max cost value is 1, and we dont want the same values for 100M and 10G link)

  (config-router)#auto-cost reference-bandwidth 10000

   *10000 is 10000 Mbps

  * Dont forget to clear the OSPF process in order for the changes to take effect:
 
  #clear ip ospf process

 2. Change the COST in the Interface Configuration

  (config-if)#ip ospf cost 20

   and check the result:

    Cisqueros_R1#show ip ospf inter Lo0 | i Cost    
    Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 20

Then check the metric on the OSPF Neighbor:

Cisqueros_R2#show ip route 1.0.0.0
Routing entry for 1.0.0.0/8
  Known via "ospf 1", distance 110, metric 84, type intra area <--- METRIC 84
  Last update from 10.1.12.1 on Serial1/0.21, 00:02:31 ago
  Routing Descriptor Blocks:
  * 10.1.12.1, from 1.1.1.1, 00:02:31 ago, via Serial1/0.21
      Route metric is 84, traffic share count is 1

Metric is 84, which is the cost of the Serial interface between routers 1 and 2, and the Cost of the Loopback0 interface on Router 1.

Default cost of the Loopback interface is 1, so it actually increased for 20-1 = 19

OSPF Advanced Virtual Link configuration: Multiple Virtual-Link


At this level I suppose you know how to configure the Virtual Link, and what is it's purpose. Let's get some deeper into clearing out some doubts.

1. What happens with the OSPF Neighbors, and how do I check the Virtual Link?
Configure between two routers out of which none is in the Area 0 (Backbone Area). Once it's configured - a new OSPF neighbor will be added as a Virtual-Link neighbor:

Cisqueros_R3#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           0   FULL/  -        00:00:05    10.1.34.4       OSPF_VL0 <--- VIRTUAL LINK NEIGHBOR
2.2.2.2           0   FULL/  -        00:00:30    10.1.23.2       Serial1/0.32
4.4.4.4           0   FULL/  -        00:00:34    10.1.34.4       Serial1/0.34


2. What do I do if I have more areas connected to each other, but none connected to Area 0. Can I form multiple Virtual Links?

The answer is YES, you can! So for example if we have the following scenario:

Cisqueros_R1 - Area 0 - Cisqueros_R2 - Area 1 - Cisqueros_R3 - Area 2 - Cisqueros_R4 - Area 3 - Cisqueros_R5

We would need to create 2 virtual links
 - AREA 1 VIRTUAL LINK between Cisqueros_R2 and Cisqueros_R3 so that Area 2 would have the communication with the Area 0
 - AREA 2 VIRTUAL LINK between Cisqueros_R3 and Cisqueros_R4 so that Area 3 could communicate with Area 1, and therefore with Area 0

 Cisqueros_R2:
 (config-router)#area 1 virtual-link 3.3.3.3

 Cisqueros_R3:
 (config-router)#area 1 virtual-link 2.2.2.2
 (config-router)#area 2 virtual-link 4.4.4.4

 Cisqueros_R4:
 (config-router)#area 2 virtual-link 3.3.3.3

Let's check the OSPF Neighbors again on Cisqueros_R3 router:

Cisqueros_R3#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -           -        10.1.23.2       OSPF_VL1
4.4.4.4           0   FULL/  -           -        10.1.34.4       OSPF_VL0
2.2.2.2           0   FULL/  -        00:00:34    10.1.23.2       Serial1/0.32
4.4.4.4           0   FULL/  -        00:00:33    10.1.34.4       Serial1/0.34
Cisqueros_R3#

Check the Virtual Link Details:

#show ip ospf virtual-links  

Have in mind that routers Cisqueros_R3 and Cisqueros_R4 are now VIRTUALLY connected to Area 0, so if you enable the authentication on the Cisqueros_R1 interface towards Cisqueros_R2, you also must enable authentication for Area 0 on Cisqueros_R3 and Cisqueros_R4!!!

OSPF Authentication


OSPF supports two types of Authentication:
 1. Plain Text (64-bit Password)

    (config-if)#ip ospf authentication-key ^&*(^*&&%
   
 2. MD5 (ID + 128-bit Password):

    (config-if)#ip ospf message-digest-key 1 MD5 ^&*^&^*


You can enable the OSPF Authentication:

 1. Globally on the Router, in the "router ospf" configuration, so it's enabled on all the Interfaces
   
     (config-router)#area 0 authentication [message-digest]

*If you enable the Authentication globaly on the routing process configuration, have in mind that you MUST configure the Authentication Key on ALL the OSPF Interfaces. If you need to DISABLE the authentication on some of the interfaces, use the following Interface command:
    (config-if)#ip ospf authentication null


**When you've got the Authentication enabled only for one of the Areas within the OSPF process - it will BREAK all the Virtual Links with the non-authentication Areas, and you will get the following message:
*May  1 14:58:46.971: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on OSPF_VL1 from FULL to DOWN, Neighbor Down: Interface down or detached
It will also not receive any Intra-area routes (marked as O IA in the Routing Table)


 2. Directly on the Interface

    (config-if)#ip ospf authentication [message-digest]
   
*When you configure per-interface Authentication, the other routers NO NOT NEED TO HAVE THE AUTHENTICATION ENABLED!

Check what type of OSPF Authentication has been configured and what Key/Password is applied:

Cisqueros_R1#show ip ospf interface s1/0.12

Serial1/0.12 is up, line protocol is up 
  Internet Address 10.1.12.1/24, Area 0 
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:01
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 2.2.2.2
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled <--- AUTHENTICATION TYPE
    Youngest key id is 1 <--- THE APPLIED AUTHENTICATION KEY

If you need to seemlessly change the authentication key, here is how it's done:
 1. Add the MD5 authentication Key 2
 2. Make sure that both keys are configured using the command from above. Note that these lines will be added to the bottom of the output:

   Message digest authentication enabled
    Youngest key id is 2
    Rollover in progress, 1 neighbor(s) using the old key(s):
      key id 1

 3. Configure the Key 2 on the Neighbor routers, and do the same command as above. You will notice that the output changes to:

   Message digest authentication enabled
    Youngest key id is 2

4. It is now safe to remove the Key 1. KEY NUMBERS HAVE NOTHING TO DO WITH THE ORDER!!! This means that next time you need to change Keys, you can use Key 1 again with a different Password.



Most Popular Posts