BGP - 1 - Foundation

BGP does not use a metric to select the best route among alternate routes to the same destination. Instead, BGP uses several BGP path attributes (PA). BGP uses the BGP autonomous system path (AS_PATH) PA as its default metric mechanism when none of the other PAs has been overly set and configured.

After the TCP connection is established, BGP begins with BGP Open messages. After a pair of BGP Open messages has been exchanged, the neighbors have reached the established state, which is the stable state of two working BGP peers. At this point, BGP Update messages can be exchanged.

Peer-group allows fewer configuration commands, and improves processing efficiency by having to prepare only one set of outbound Update packets for the peer group. BGP builds one set of Update messages for the peer group, applying routing policies for the entire group—rather than one router at a time—thereby reducing some BGP processing and memory overhead.

For eBGP connections, Cisco IOS defaults the IP packet’s TTL field to a value of 1, based on the assumption that the interface IP addresses will be used for peering.

Checks Before Becoming BGP Neighbors
1. The router must receive a TCP connection request with a source address that the router finds in a BGP neighbor command.
2. A router’s ASN (on the router bgp asn command) must match the neighboring router’s reference to that ASN with its neighbor remote-as asn command. (This requirement is not true of confederation configurations.)
3. The BGP RIDs of the two routers must not be the same.
4. If configured, MD5 authentication must pass.

BGP uses a keepalive timer to define how often that router sends BGP keepalive messages, and a Hold timer to define how long a router will wait without receiving a keepalive message before resetting a neighbor connection. The Open message includes each router’s stated keepalive timer. If they do not match, each router uses the lower of the values for each of the two timers, respectively. Mismatched settings do not prevent the routers from becoming neighbors.

BGP Messages and Neighbor States

The desired state for BGP neighbors is the established state in which the routers have formed a TCP connection, and they have exchanged Open messages, with the parameter checks having passed. At this point, topology information can be exchanged using Update messages. If the IP addresses mismatch, the neighbors settle into an active state.

Building the BGP Table

The BGP topology table , also called the BGP Routing Information Base (RIB) , holds the network layer reachability information (NLRI) learned by BGP, as well as the associated PAs. Technically, BGP does not advertise routes; rather, it advertises PAs plus a set of NLRI that shares the same PA values. However, most people simply refer to NLRI as BGP prefixes or BGP routes.

The BGP network command instructs that router’s BGP process to do the following:

• Look for a route in the router’s current IP routing table that exactly matches the parameters of the network command; if the IP route exists, put the equivalent NLRI into the local BGP table.
• With this logic, connected routes, static routes, or IGP routes could be taken from the IP routing table and placed into the BGP table for later advertisement. When the router removes that route from its IP routing table, BGP then removes the NLRI from the BGP table, and notifies neighbors that the route has been withdrawn.

Impact of Auto-Summary on Redistributed Routes and the network Command

As it does with IGPs, the BGP auto-summary command causes a classful summary route to be created if any component subnet of that summary exists. However, unlike IGPs, the BGP auto-summary router subcommand causes BGP to summarize only those routes injected because of redistribution on that router. It simply looks for routes injected into the BGP because of the redistribute and network commands on that same router.

The logic differs slightly based on whether the route is injected with the redistribute command or the network command. The logic for the two commands is summarized as follows:

redistribute: If any subnets of a classful network would be redistributed, do not redistribute, but instead redistribute a route for the classful network.

network: If a network command lists a classful network number, with the classful default mask or no mask, and any subnets of the classful network exist, inject a route for the classful network.

For redistribution, the auto-summary command causes the redistribution process to inject only classful networks into the local BGP table, and no subnets. The network command, with auto-summary configured, still injects subnets based on the same logic. In addition to that logic, if a network command matches the classful network number, BGP injects the classful network, as long as at least any one subnet of that classful network exists in the IP routing table.

Manual Summaries and the AS_PATH Path Attribute

BGP manual summarization with the aggregate-address command can summarize based on any routes in the BGP table, creating a summary of any prefix length. It does not always suppress the advertisement of the component subnets, although it can be configured to do so. The aggregate route must include the AS_PATH PA, just like it is required for every other NLRI in the BGP table.

The AS_PATH PA consists of up to four different components, called segments , as follows:

• AS_SEQ (short for AS Sequence)
• AS_SET
• AS_CONFED_SEQ (short for AS Confederation Sequence)
• AS_CONFED_SET

When the component subnets of the summary route have differing AS_SEQ values, the router simply can’t create an accurate representation of AS_SEQ, so it uses a null AS_SEQ. However, this action introduces the possibility of creating routing loops. 

The AS_PATH AS_SET segment solves the problem when the summary route has a null AS_SEQ. The AS_SET segment holds an unordered list of all the ASNs in all the component subnets’ AS_SEQ segments.

"atomic-aggregate" refers to the fact that the ATOMIC_AGGREGATE PA has also been set; this PA simply states that this NLRI is a summary.

The following list summarizes the actions taken by the aggregate-address command when it creates a summary route:

• It does not create the summary if the BGP table does not currently have any routes for NLRI inside the summary.
• If all the component subnets are withdrawn from the aggregating router’s BGP table, it also then withdraws the aggregate. (In other words, the router tells its neighbors that the aggregate route is no longer valid.)
• It sets the NEXT_HOP address of the summary, as listed in the local BGP table, as 0.0.0.0.
• It sets the NEXT_HOP address of the summary route, as advertised to neighbors, to the router’s update source IP address for each neighbor, respectively.
• If the AS_SEQ of the component subnets differs in any way, it sets the AS_SEQ of the new summary route to null.
• When the as-set option has been configured, the router creates an AS_SET segment for the aggregate route, but only if the summary route’s AS_SEQ is null.
• It suppresses the advertisement of all component subnets if the summary-only keyword is used, advertises all of them if the summary-only keyword is omitted, or advertises a subset if the suppress-map option is configured.

Adding Default Routes to BGP

Default routes can be injected into BGP in one of three ways:

• By injecting the default using the network command
• By injecting the default using the redistribute command
• By injecting a default route into BGP using the neighbor neighbor-id defaultoriginate [ route-map route-map-name ] BGP subcommand

   When you inject a default route into BGP using the network command, a route to 0.0.0.0/0 must exist in the local routing table, and the network 0.0.0.0 command is required.

   Injecting a default route through redistribution requires an additional configuration command—default-information originate . The default route must first exist in the IP routing table.

   Injecting a default route into BGP by using the neighbor neighbor-id default-originate [ route-map route-map-name ] BGP subcommand does not add a default route to the local BGP table; instead, it causes the advertisement of a default to the specified neighbor. In fact, this method does not even check for the existence of a default route in the IP routing table by default, but it can.

ORIGIN Path Attribute

The ORIGIN PA provides a general descriptor as to how a particular NLRI was first injected into a router’s BGP table. Routes redistributed into BGP from an IGP actually have an ORIGIN code of incomplete.

BGP Update Message

If a router needs to advertise a set of NLRIs, and each NLRI has a different setting for at least one PA, separate Update messages will be required for each

NLRI. However, when many routes share the same PAs—typical of prefixes owned by a particular ISP, for example—multiple NLRIs are included in a single Update. This reduces router CPU load and uses less link bandwidth.

For a route to be a candidate to be considered best, the NEXT_HOP must be either

• 0.0.0.0, as the result of the route being injected on the local router.
• Reachable according to that router’s current IP routing table. In other words, the NEXT_HOP IP address must match a route in the routing table.

Note that the NEXT_HOP PA cannot be set through a route map. 

For the received-routes option to work, the router on which the command is used must have the neighbor neighbor-id soft-reconfiguration inbound BGP subcommand configured for the other neighbor.

These show ip bgp neighbor commands with the advertised-routes option list the BGP table entries that will be advertised to that neighbor. However, note that any changes to the PAs inside each entry are not shown in the command output.

Summary of Rules for Routes Advertised in BGP Updates

The following list summarizes the rules dictating which routes a BGP router sends in its update messages:

• Send only the best route listed in the BGP table.
• To iBGP neighbors, do not advertise paths learned from other iBGP neighbors.
• Do not advertise suppressed or dampened routes.
• Do not advertise routes filtered through configuration.

Adding eBGP Routes to the IP Routing Table

Cisco IOS Software uses simple logic when determining which eBGP routes to add to the IP routing table. 

• The eBGP route in the BGP table is considered to be a “best” route.
• If the same prefix has been learned through another IGP or through static routes, the AD for BGP external routes must be lower than the ADs for other routing source(s).

BGP sets the AD differently for eBGP routes, iBGP routes, and for local (locally injected) routes—with defaults of 20, 200, and 200, respectively.

The actual IP route added to the IP routing table contains the exact same prefix, prefix length, and next-hop IP address as listed in the BGP table—even if the NEXT_HOP PA is an IP address that is not in a connected network. As a result, the IP forwarding process might require a recursive route lookup.

Backdoor Routes(network backdoor) will use the local AD (default 200) for the eBGP-learned route to network. 

Adding iBGP Routes to the IP Routing Table

Cisco IOS has the same two requirements for adding iBGP routes to the IP routing table as it does for eBGP routes:

• The route must be the best BGP route.
• The route must be the best route (according to the AD) in comparison with other routing sources.

Additionally, for iBGP-learned routes, IOS considers the concept of BGP synchronization. 

The key to understanding BGP sync is to know that redistribution solves the routing

black-hole problem, and sync solves the problem of advertising a black-hole route to

another AS. 

The BGP sync logic controls that decision as follows: Do not consider an iBGP route in the BGP table as “best” unless the exact prefix was learned through an IGP and is currently in the routing table. The route must be IGP-learned not via own's static route.

Sync includes an additional odd requirement when OSPF is used as the IGP. If the OSPF RID of the router advertising the prefix is a different number than the BGP router advertising that same prefix, sync still does not allow BGP to consider the route to be the best route.

Disabling Sync and Using BGP on All Routers in an AS

A second method to overcome the black-hole issue is to simply use BGP to advertise all the BGP-learned prefixes to all routers in the AS. BGP needs the full mesh of iBGP peers inside an AS because BGP does not advertise iBGP routes (routes learned from one iBGP peer) to another iBGP peer. BGP offers two tools (confederations and route reflectors) that reduce the number of peer connections inside an AS, prevent loops, and allow all routers to learn about all prefixes.

Confederations

Peers inside the same sub-AS are considered to be confederation iBGP peers , and routers in different subautonomous systems are considered to be confederation eBGP peers. Confederation eBGP peer connections act like true eBGP peers in some respects. In a single sub-AS, the confederation iBGP peers must be fully meshed, because they act exactly like normal iBGP peers. 

Confederations prevent loops inside a confederation AS by using the AS_PATH PA. BGP routers in a confederation add the subautonomous systems into the AS_PATH as part of an AS_PATH segment called the AS_CONFED _SEQ. (The AS_PATH consists of up to four different components, called segments—AS_SEQ, AS_SET, AS_CONFED_ SEQ, and AS_CONFED_SET.

The following list summarizes the key topics regarding confederations:

• Inside a sub-AS, full mesh is required, because full iBGP rules are in effect.
• The confederation eBGP connections act like normal eBGP connections in that iBGProutes are advertised—as long as the AS_PATH implies that such an advertisement would not cause a loop.
• Confederation eBGP connections also act like normal eBGP connections regarding Time to Live (TTL), because all packets use a TTL of 1 by default. (TTL can be changed with the neighbor ebgp-multihop command.)
• Confederation eBGP connections act like iBGP connections in every other regard—for example, the NEXT_HOP is not changed by default.
• Confederation ASNs are not considered part of the length of the AS_PATH when a router chooses the best routes based on the shortest AS_PATH. 
• Confederation routers remove the confederation ASNs from the AS_PATH in Updates sent outside the confederation; therefore, other routers do not know that a confederation was used

Route Reflectors

In an iBGP design using RRs, a partial mesh of iBGP peers is defined. Some routers are configured as RR servers; these servers are allowed to learn iBGP routes from their clients and then advertise them to other iBGP peers. Note that only the RR server itself uses different logic, with clients and nonclients acting as normal iBGP peers.

One of the main motivations for using RRs is to allow sync to be disabled.
RR feature uses several tools to prevent loops, as follows:
CLUSTER_LIST: RRs add their cluster ID into a BGP PA called the CLUSTER_LIST before sending an Update. When receiving a BGP Update, RRs discard received
prefixes for which their cluster ID already appears. As with AS_PATH for confederations, this prevents RRs from looping advertisements between clusters.
ORIGINATOR_ID: This PA lists the RID of the first iBGP peer to advertise the route into the AS. If a router sees its own BGP ID as the ORIGINATOR_ID in a received route, it does not use or propagate the route.
Only advertise the best routes: RRs reflect routes only if the RR considers the route to be a “best” route in its own BGP table. This further limits the routes reflected by the RR. (It also has a positive effect compared with confederations in that an average router sees fewer, typically useless, redundant routes.)

Multiprotocol BGP 

Some of these configurations carry VPN-IPv4 routes, some only IPv4 routes, and others carry VPN-IPv4 and IPv4 routes. The type of BGP session and the specification of which routes the peering sessions will carry are controlled through the use of the address families.

Configure a BGP address family for each Virtual Routing and Forwarding (VRF) configured on the PE router and a separate address family to carry no IPv4 routes between PE routers. The initial BGP process, the portion of the configuration that cites no address family specifications, becomes the default address family. This default context becomes the “catch all” where any non-VRF-based or IPv4-specific sessions can be configured. Any prefixes learned or advertised in this default address family will be injected into the global routing table. The configuration of these BGP sessions is exactly the same as the standard BGP configuration with the exception that the session needs to be activated.

R1(config-router)# address-family vpnv4
R1(config-router)# neighbor 194.22.15.3 activate

The configuration of the VPNv4 address family also adds a further command to the BGP configuration to support the MP-BGP-specific extended community attributes. This command will be added by the IOS by default and is necessary because it instructs BGP to advertise the extended community attributes.

The default behavior is to send only the extended community attribute. If the network design requires the standard community attribute to be attached to these non-IPv4 prefixes, this behavior can be changed through the neighbor 194.22.15.3 send-community both command.

Note that MP-iBGP communicates these routes across the MP-iBGP sessions running between PE routers. To this end, the routing context must be configured under the BGP process to communicate to BGP which VRF prefixes it needs to advertise.

Summary

address-family vpnv4 

- BGP mode; allows the creation of the MP-BGP session necessary to form the VPNv4 session between PE devices

bgp client-to-client reflection

- BGP mode; on by default, tells an RR server to reflect routes learned from a client to other clients

default-information originate 

- BGP mode; required to allow a static default route to be redistributed into BGP

distance bgp external-distance internal distance local-distance 

- BGP mode; defines the administrative distance for eBGP, iBGP, and locally injected BGP routes

neighbor { ip-address | peer-group-name } default-originate [ route-map map-name ]

- BGP mode; tells the router to add a default route to the BGP Update sent to this neighbor, under the conditions set in the optional route map

show ip bgp injected-paths

- Exec mode; lists routes locally injected into BGP

OSPF - Labbing Notes 2

OSPF is sometimes described as being partially link-state and partially distance vector. This is because SPF calculations are only performed for Intra-Area routing, whereas the Area Border Routers’ (ABRs) advertised information is trusted for Inter-Area and External calculations. R10 does not know the detailed information about the path selection that is occurring behind R5 (ABR). R10 trusts R5’s calculation for the prefix, which is typically a distance vector behavior, and then calculates the shortest Intra-Area path to reach R5, which is a link-state behavior.

Metric of the route is 41 and it’s an ospf inter-area route. Next hop is 155.1.108.8 and the route is from 150.1.5.5 with the cost of 21.

First finding out who R10 is adjacent with by viewing its Router LSA (LSA 1).

So, from above total cost from R10 to 150.1.6.6 is 21+10+10=41. 

Now, let’s see how R5 gets the cost of 21.

To view possible paths to Network Summary LSA (LSA 3), below shows both R1 and R4 with advertising cost of 11.

To find shortest path cost to R1 and R4, 

The cost to reach all ABR routers can also be identified from the following output.

Setting a ospf cost for an interface is only effective for its router’s shortest path calculation; not the directly connected router at the other end of the interface. OSPF cost calculation for a segment is based on the bandwidth value of the outgoing interface.

To have different OSPF cost per neighbor, the network type’s point-to-multipoint and point-to-multipoint non-broadcast support the setting of the OSPF cost value on a per-neighbor basis.

---------------------------------------------------------------------------------------

Inter-area routing can only occur through area 0.

Non-backbone (not area 0) areas can be used for inter-area transit if a shorter path can be found through them, and if the "TransitCapability parameter has been set to TRUE in Step 2 of the Dijkstra algorithm." In Cisco’s IOS implementation, this flag is controlled with the capability transit routing process-level command, and is on by default. The design case when the feature is used is very specific and has to do with a shorter Inter-Area path being found via a non-area 0 router as compared to the target router of a virtual-link.

Flooding Reduction – LSA’s LS age is never incremented past the value MaxAge. When the link state age reaches MaxAge, the router must attempt to flush the LSA by reflooding the MaxAge LSA just as if it was a newly originated LSA. MaxAge value is 3600 sec or 60 minutes by default. To ensure the an LSA is not aged out, which means it will be flushed from the OSPF database, each LSA is reflooded after 30 minutes, regardless of whether the topology is stable or not. This periodic flooding behavior is commonly referred to as the “paranoid update.” The ip ospf flood-reduction feature stops unnecessary LSA flooding by setting the DoNotAge (DNA) bit in the LSA, removing the requirement for the periodic refresh. This needs to be enabled on links with OSPF neighbors attached.

OSPF Summarization

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. Use "area <area no from where routes summarized> range address mask".

External OSPF summarization is configured at the redistribution point between routing domains with the summary-address command.

The Forward Address: 0.0.0.0 field means that R5 must now compute the metric toward the advertising router, ASBR, and install this metric in the routing table as the forward metric.

The calculation for External Type-1 OSPF routes does not distinguish in the routing table between the metric reported by the ASBR and the metric to the ASBR via the forward metric. Instead, External Type-1 routes represent the metric as one cumulative value of the reported metric and the metric to the ASBR.

OSPF Stub Area

The stub area, is used to remove Type-5 External link states from the database and replace them with a default route. 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.

OSPF NSSA

When the Type-7 NSSA External LSA is received by the ABR and is moved into area 0, the information contained in the Type-7 LSA is translated to a normal Type-5 External LSA. If multiple ABRs exist, only one of them performs the translation through an election process.

Note that ABR R5 receives the Type-7 NSSA External LSA with the forward address set to 150.1.8.8. With the previous Type-5 external lookups, we saw the forward address set to 0.0.0.0, which meant to route toward the advertising router to reach the final destination. In this case, the forward address is non-zero, which causes the lookup to be performed toward 150.1.8.8. This is a subtle difference in the lookup process and there can, however, be certain designs where there is a shorter path to the forward address than the advertising router’s address.

Note that the lookup process for this translated Type-7 LSA is performed differently than a normal inter-area Type-5 external LSA lookup, because R1 computes its metric toward 150.1.8.8, and not a Type-4 LSA describing the ASBR. Furthermore, note that R5 does not generate a Type-4 ASBR Summary LSA describing R8.

Like the stub area, Type-5 external LSAs are blocked from entering the NSSA area on the ABR(s), note that R6's Loopback100 is known in area 0, but not in area 3.

The other key difference between stub and NSSA areas is how default routing works. The stub area removes external Type 3 LSAs and replaces them with a default route. The totally stubby area extends this by replacing external Type 3 LSAs and inter-area Type 2 LSAs with a default route. However, with the NSSA, a default route is not automatically originated by the ABR. This means that devices within the NSSA will have reachability to their own area and to other areas, but not to destinations outside of the OSPF domain.

Using default information-originate option onto the area [id] nssa statement, the default route is injected by the ABR as a regular Type-7 LSA with the type of N2 which uses the metric advertised by the ABR and the forwarding metric as the cost towards the ABR. 

The not-so-totally-stubby area is the combination of the totally-stubby area and the NSSA. Like the totally-stubby area, Type-3 Summary LSAs, Type-4 ASBR Summary LSAs, and Type-5 External LSAs are removed and replaced with a Type-3 Summary LSA default route. Like the NSSA, Type-7 NSSA External LSAs are allowed to be originated inside the area.

OSPF always prefers routes in the sequence intra-area> inter-area > external > nssa-external.

----------------------------------------------

With OSPF Not-So-Stubby Areas, Type-7 NSSA External LSAs are translated to Type-5 External LSAs by the ABR connecting the NSSA to area 0. When multiple ABRs connect the NSSA to area 0, the ABR with the highest router-id is elected as the Type-7 to 5 translator, and is responsible for re-originating the Type-5 LSA into area 0.

Only one ABR performs the Type-7 to 5 translation, but maintains the forward address field, essentially separating the relationship between the routing advertisement and the traffic flow.

Type-5 External route that was translated from a Type-7 NSSA External route does not use a Type-4 ASBR Summary LSA, because the forward address lookup replaces the need for the ASBR Summary lookup. Because the forward address is preserved, only one router needs to do the translation, while the calculation of the final forwarding path stays independent. The control plane advertisement of the route does not need to follow the traffic forwarding plane.

By adding the no-redistribution keyword onto the area 3 nssa statement of R5, Type-7 LSAs are not generated for locally redistributed routes. This does not, however, prevent other devices inside the NSSA from performing redistribution. 

OSPF Filtering

A very specific feature - OSPF Forwarding Address Suppression in Translated Type-5 LSAs can be configured by adding "translate type7 suppress-fa" argument to "area 3 nssa" statement to instruct the ABR to not preserve the value in the forward address field as a Type-7 NSSA External LSA is translated into a Type-5 External.

All routers within an OSPF area must agree on their view of the database and hence, 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 (filter list). 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. This type of design can result in traffic black holes if not implemented carefully.

After implementing distribute-list inbound, the prefix/route is not installed in the routing table but it’s in the OSPF database.

With a normal distribute-list filter referencing an access-list, there would be no way to distinguish between the same prefix from 2 neighbors because they are the same prefix, just two different paths in the network. Referencing a route-map with a distribute-list in OSPF extends the filtering capability with additional match criteria such as route-source, next hop ip, etc.

OSPF Default Routing

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. 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 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 on the ASBR for NSSA type 7 to type 5 translation.

A neighbor relationship cannot occur if two OSPF neighbors have different MTU values on their interfaces. If the MTU difference is by design, the interface-level command ip ospf mtu-ignore removes this requirement from the adjacency establishment.

OSPF - Labbing Notes 1

The common attributes that must match are the area number, timers, authentication, stub flags, MTU, and compatible network types. The attributes that must be unique are the interface IP addresses and the router-ids.

For DMVPN, there is no direct adjacency between spoke routers, because regardless of the DMVPN Phase being configured, IGP packets are not sent between spokes (although with certain configurations this can be achieved, there is no reason for doing it).

OSPF DR Selection

The device with the highest priority is elected the DR and if there is a tie in the priority value, the device with the higher router-id is elected the DR. DR/BDR election takes place only for OSPF network types of broadcast and non-broadcast. OSPF DR/BDR election does not support preemption like IS-IS does for its DIS election. A router starts sending HELLO packets on the segment, and if no other OSPF routers are detected on the segment to negotiate the DR/BDR roles within the WAIT timer, the router declares itself as the DR. The WAIT timer is not directly configurable but always equals in value with the DEADinterval.

Only the DR on an OSPF segment originates the Network LSA (LSA 2). The Network LSA is used to describe all the neighbors that the DR on the segment is adjacent with to the BDR and DROTHERs on that link.

OSPF Network Types

In Point-to-multipoint, 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):

In point-to-multipoint network, in Type 1 LSA, each router advertises its own IP address with a /32 mask and additionally it advertises its OSPF neighbors on the segment which is required for a complete OSPF database view.

 In point-to-multipoint network, since there is no DR, there is no network LSA.

From views outside of the connected segment, the point-to-multipoint network is only seen as a collection of endpoints, not a transit segment itself. R8 does not have an exact match for the prefix 155.1.0.0/24, which is the actual subnet assignment of the DMVPN Network. Instead, it knows that there are five endpoints on the network.

Broadcast network.type

In Broadcast network type, in Type 1 LSA, each router advertise the connected link as transit network

Type 2 LSA Network LSA is generated in Broadcast network.

With the broadcast network type, the DR does not update the next-hop. 

In Broadcast network, type 2 Network LSA is available since there is a DR. From outside, the whole subnet 155.1.0.0/24 is learnt.

Ospf Point-to-point network will work with point-to-multipoint if we change the hello, dead timers.

There is no DR selection and so there is no type 2 LSA, but the router is advertising connected subnet as LSA Type 1. 

155.1.0.5 is the DMVPN hub and it changed the next hop as itself in the OSPF routes.

From outside of the area 123, 155.1.0.0/24 is learnt as the same way in Broadcast network.

The Non-Broadcast network type means that there will no 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.

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>. In "show ip ospf int", it appears as point-tomultipoint, which can be both broadcast and non-broadcast; there is no clear differentiation in the outputs between the two. The difference between the two types can be seen in the debug ip packet output.

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 is point-to-point, these are correctly advertised with their subnet mask.

Verify how these Loopbacks appear in the OPSF database.

From outside of that area, the routes are learnt as below.