Thursday 18 August 2016

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. 




No comments:

Post a Comment