OSPF : "34 Things to remember"

Open Shortest Path First (OSPF) is a routing protocol for Internet Protocol (IP) networks. It uses a link state routing algorithm and falls into the group of interior routing protocols, operating within a single autonomous system (AS). It is defined as OSPF Version 2 in RFC 2328 (1998) for IPv4.[1] The updates for IPv6 are specified as OSPF Version 3 in RFC 5340 (2008).

OSPF is perhaps the most widely used interior gateway protocol (IGP) in large enterprise networks. IS-IS, another link-state dynamic routing protocol, is more common in large service provider networks. The most widely used exterior gateway protocol is the Border Gateway Protocol (BGP), the principal routing protocol between autonomous systems on the Internet.

OSPF is an internal entranceway protocol (IGP) for routing web Protocol (IP) packets alone among one routing domain, like associate autonomous system. It gathers link state info from on the market routers and constructs a topology map of the network. The topology is bestowed as a routing table to the net Layer that routes datagrams based mostly alone on the destination information science address found in information science packets. OSPF supports web Protocol Version four (IPv4) and web Protocol Version half-dozen (IPv6) networks and options variable-length subnet masking (VLSM) and egalitarian Inter-Domain Routing (CIDR) addressing models.

OSPF detects changes within the topology, like link failures, and converges on a brand new loop-free routing structure among seconds. It computes the shortest path tree for every route employing a methodology supported Dijkstra's formula, a shortest path initial formula.

The OSPF routing policies for constructing a route table square measure ruled by link value factors (external metrics) related to every routing interface. value factors is also the gap of a router (round-trip time), knowledge outturn of a link, or link convenience and dependableness, expressed as easy unit less numbers. This provides a dynamic method of traffic load equalization between routes of equal value.

An OSPF network is also structured, or divided, into routing areas to change administration and optimize traffic and resource utilization. Areas square measure known by 32-bit numbers, expressed either merely in decimal, or usually in octet-based dot-decimal notation, acquainted from IPv4 address notation.

The 34 Things which you should remember are as follows:-

1. The IP header of an OSPF packet specifies protocol number 89.

2. To establish OSPF neighbor adjacency, hello/dead timers, MTU (otherwise have to use "ip ospf mtu-ignore") must match. Unique router-id is also required.

3. Routers in stub area can only be adjacent with the routers in stubs or totally stubby area. Routers in NSSA can only be adjacent with the routers in NSSA or totally NSSA.

4. OSPF sees secondary networks as stub networks and cannot make adjacencies over secondary addresses. OSPF will advertise a secondary network or subnet only if it is also running on the primary network or subnet and OSPF routes of secondary addresses must be in same area as the primary address to be advertised. To learn routes from a neighbor connected to the secondary network, another routing protocol such as RIP should be running and redistributed into OSPF. Another solution to this kind of problem is to create dot1q sub interfaces.

5. The only time that OSPF will form adjacencies between neighbors that are not on the same subnet is when the neighbors are connected through point-to-point links using "ip unnumbered".

6. The primary interface and IP unnumbered interface will have OSPF enabled if a network statement matches the IP address of the primary interface.

7. An OSPF external route cannot use another OSPF external route as its next hop.

8. Inside an area, OSPF uses Link State logic, but between areas OSPF acts much like a Distance Vector (DV) protocol in some regard. For example, the advertisement of a Type 3 LSA from one area to another hides the topology in the original area from the second area, just listing a destination subnet, metric (cost), and the ABR through which the subnet can be reached—all DV concepts.

9. Only broadcast and non-broadcast network elect DR/BDR based on priority or router-id (in case of a tie in the priority).

10. In non-broadcast network, DR/BDR must have layer 2 connectivity to all other routers in the same area.

11. With OSPF network types broadcast and non-broadcast, next hop values are not modified when updates are transmitted across an NBMA media. Both point-to-multipoint and point-to-multipoint non-broadcast network type update the next-hop value of routes learned on partially meshed networks to the directly connected neighbor, and advertise the network as a set of endpoints instead of a transit network.

12. OSPF network point-to-point is the default option for point-to-point interfaces such as HDLC, PPP, or point-to-point NBMA subinterfaces.

13. As only broadcast and non-broadcast network type elects DR/BDR, they are compatible with each other, but they are not compatible with any other network types.

14. OSPF cost can be modified using (i) interface "bandwidth ..." command, (ii) interface "ip ospf cost ..." command, (iii) process "auto-cost reference-bandwidth ..." command, or (iv) "neighbor ... cost ..." command on point-to-multipoint non-broadcast network.

15. Only OSPF point-to-multipoint and point-to-multipoint non-broadcast network types support OSPF cost value on a per neighbor basis. On point-to-multipoint broadcast networks, if the "neighbor..." command is used, a cost to that neighbor must be specified.  But on point-to-multipoint non-broadcast networks, the "neighbor ..." command must be used to identify neighbors, assigning a cost to a neighbor is optional.

16. The internal OSPF routes can only be summarized on ABRs whereas the external (redistributed) routes can only be summarized on ASBRs.

17. "area default-cost ..." command is used to specify a cost for the default summary route (default cost 1) that is sent into a stub area or NSSA.

18. In NSSA, ABR with the highest router-id does the LSA 7 to 5 conversion.

19. In NSSA, “default-information originate” command cannot be used, since it generates Type-5 LSA, which is prohibited in NSSA area.

20. NSSA ASBR can generate a default only when it has a default route in its routing table whereas NSSA ABR can generate a default route with or without a default route in its own routing table.

21. Virtual links are not allowed in the stubby area or NSSA. In this case OSPF can be tunneled over a stub area using GRE tunnel (tunnel must be connected to area 0).

22. If the authentication is wrong on the virtual-link, the virtual-link interface will not go down immediately. As the virtual-link does not support periodic hellos, “clear ip ospf process” command should be issued if the authentication is enabled on the virtual link.

23. The virtual link will not come up if the only interface to reach the other end of the virtual link has a cost that is maximized (65535).

24. For BGP to redistribute routes into OSPF, the router-id must be identical, in OSPF and in BGP.

25. OSPF filtering using "distribute-list ...", "route-map ..." (match route-type, match ip route-source, match ip next-hop), and "distance ..." commands can only block route from entering into local RIB, but cannot stop LSAs propagation into the OSPF database.

26. OSPF filtering using "area ... filter-list prefix ...", "area ... range ... not-adv", “summary-address … not-adv”, “ip ospf database-filter all out”, or “neighbor … database-filter all out”  commands can filter LSAs from OSPF database.

27. If the “area … range …” and "area ... filter-list prefix ... out" both commands are configured for an area, then type 3 LSAs that correspond to the area range are sent to all other areas, only if at least one prefix in the area range matches an entry in the prefix list.

28. OSPF defaults to cost 20 when redistributing from an IGP, and 1 when redistributing from BGP.

29. “neighbor … database-filter all out” only works on point-to-multipoint network types.

30. If “distribute-list out” command is configured on an ASBR, then the ASBR generates Type 5 external LSAs only for those networks that are explicitly permitted in the distribute list.

31. OSPF demand circuit sets “do not age” flag on all LSAs learned and will only send updates when there is a change in the OSPF topology. The command must be configured in a point-to-point link and is needed only on one side. If the router is part of a point-to-multipoint topology, only the multipoint end must be configured with this command.

32. The main difference between flooding reduction ("ip ospf flood-reduction") and demand circuits ("ip ospf demand-circuit") is that former suppresses only periodic LSA refreshes; it does not suppress periodic hello packets. Thus, the flooding reduction feature does not impair the detection of a neighbor router going down.

33. OSPF stub router (“max-metric router-lsa”) advertises all non self-originated routes/LSAs with maximum metric.

34. When "redistribute maximum-prefix ..." command is configured, the redistribution limit does not apply to default routes or prefixes that are generated as a result of Type-7 to Type-5 translation.

Administrative Distance

 

OSPF Neighbor States

When OSPF adjacency is formed, a router goes through several state changes before it becomes fully adjacent with its neighbor. Those states are defined in the OSPF RFC 2328 leavingcisco.com, section 10.1. The states are Down > Attempt > Init > 2-Way > Exstart > Exchange > Loading > Full.

 

Down

This is the first OSPF neighbor state. It means that no information (hellos) has been received from this neighbor, but hello packets can still be sent to the neighbor in this state.

During the fully adjacent neighbor state, if a router doesn't receive hello packet from a neighbor within the RouterDeadInterval time (RouterDeadInterval = 4*HelloInterval by default) or if the manually configured neighbor is being removed from the configuration, then the neighbor state changes from Full to Down.

 

Attempt

This state is only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor, from which hellos have not been received within the dead interval.

 

Init

This state specifies that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet. When a router receives a hello packet from a neighbor, it should list the sender's router ID in its hello packet as an acknowledgment that it received a valid hello packet.

 

2-Way

This state designates that bi-directional communication has been established between two routers. Bi-directional means that each router has seen the other's hello packet. This state is attained when the router receiving the hello packet sees its own Router ID within the received hello packet's neighbor field. At this state, a router decides whether to become adjacent with this neighbor. On broadcast media and non-broadcast multiaccess networks, a router becomes full only with the designated router (DR) and the backup designated router (BDR); it stays in the 2-way state with all other neighbors. On Point-to-point and Point-to-multipoint networks, a router becomes full with all connected routers.

At the end of this stage, the DR and BDR for broadcast and non-broadcast multiacess networks are elected. For more information on the DR election process, refer to DR Election.

Note: Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also a cause a transition to 2-way state.

 

Exstart

Once the DR and BDR are elected, the actual process of exchanging link state information can start between the routers and their DR and BDR.

In this state, the routers and their DR and BDR establish a master-slave relationship and choose the initial sequence number for adjacency formation. The router with the higher router ID becomes the master and starts the exchange, and as such, is the only router that can increment the sequence number. Note that one would logically conclude that the DR/BDR with the highest router ID will become the master during this process of master-slave relation. Remember that the DR/BDR election might be purely by virtue of a higher priority configured on the router instead of highest router ID. Thus, it is possible that a DR plays the role of slave. And also note that master/slave election is on a per-neighbor basis.

 

Exchange

In the exchange state, OSPF routers exchange database descriptor (DBD) packets. Database descriptors contain link-state advertisement (LSA) headers only and describe the contents of the entire link-state database. Each DBD packet has a sequence number which can be incremented only by master which is explicitly acknowledged by slave. Routers also send link-state request packets and link-state update packets (which contain the entire LSA) in this state. The contents of the DBD received are compared to the information contained in the routers link-state database to check if new or more current link-state information is available with the neighbor.

 

Loading

In this state, the actual exchange of link state information occurs. Based on the information provided by the DBDs, routers send link-state request packets. The neighbor then provides the requested link-state information in link-state update packets. During the adjacency, if a router receives an outdated or missing LSA, it requests that LSA by sending a link-state request packet. All link-state update packets are acknowledged.

 

Full

In this state, routers are fully adjacent with each other. All the router and network LSAs are exchanged and the routers' databases are fully synchronized.

Full is the normal state for an OSPF router. If a router is stuck in another state, it is an indication that there are problems in forming adjacencies. The only exception to this is the 2-way state, which is normal in a broadcast network. Routers achieve the FULL state with their DR and BDR in NBMA/broadcast media and FULL state with every neighbor in the remaining media such as point-to-point and point-to-multipoint.

Note: The DR and BDR that achieve FULL state with every router on the segment will display FULL/DROTHER when you enter the show ip ospf neighbor command on either a DR or BDR. This simply means that the neighbor is not a DR or BDR, but since the router on which the command was entered is either a DR or BDR, this shows the neighbor as FULL/DROTHER.

Converting from IPv4 to IPv6

is so easy, yet everyone seem to convert a IPv4 address to binary, then to IPv6. Why? Why waste time and do things the long way? Not cool.

When would you need to do this? One specific use is IPv6 6-to-4 tunnels, which always concatenates 2002::/16 with the IPv4 address embedded.

With Automatic 6-to-4-tunnels, your address format is as follow:

2002:<32 bit IPv4 site address in Hex>:<16 bit network number in Hex>::/64

The question is how to do the conversion.

Firstly before starting I will assume everyone knows the following:

• Binary is a Base-2 numbering system, as it has only 0,1
• Decimal is a Base-10 numbering system, as it has 0,1,2,3,4,5,6,7,8,9
• Hexadecimal is a Base-16 numbering system, as it has 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F

I also assume you know the hex values in decimal:

A	=	10
B	=	11
C	=	12
D	=	13
E	=	14
F	=	15

Two more things I would like to mention before explaining the conversion.
An IPv4 address : example 192.168.99.1

• Each Octet (8 bits) “between the dot-thingys” denote 1 byte

An IPv6 address : example 2001:0db8:85a3:0000:0000:8a2e:0370:7334

• Two Tuples (1 Tuple = 4 bits = 1 Hex character) denotes 1 byte

Then converting is easy. Lets take the following IPv4 address : 192.168.99.1 and convert it to Hex.

Step1 >

Divide the first octet (192) by 16 (since Hex is a Base-16)
IE : 192/16 = 12 times exactly with 0 left over
– 12 in Hex is represented as C
– 0 (zero) in Hex is, you guessed it, 0
Thus 192 in HEX is C0

Step2 >

Repeat step 1 with the second octet (168),
IE : 168/16 = 10 times with 8 left over because 10*6 = 160,
– 10 in HEX is A
– 8 in HEX is 8
Thus 168 in HEX is A8

Step3 >

Repetition rules!!! Third octet (99)
IE : 99/16 = 6 times with 3 left over
– 6 in HEX is 6
– 3 in HEX is 3
Thus 99 in HEX is 63

Step4 >

Last octet
IE : 1/16 = 0 times with 1 left over
– 0 in HEX is, yeah it is 0
– 1 in HEX is 1
Thus 1 in HEX is 01

So the IPv4 address of 192.168.99.1, represented in the IPv6 address portion would be C0A8:6301.
So when using IPv6 6-to-4 Tunnels, on the one endpoint of the tunnel, with the IPv4 address of 192.168.99.1, the complete IPv6 address would be 2002:C0A8:6301::1/64
See, not all that difficult, if you know your 16 multiplication table, you can do this in your head, no problems.

========================================================================

Converting back from IPv6 to IPv4

Now to convert the same portion of the IPv6address 2002:C0A8:6301::1/64 back to IPv4, the reverse method would apply.

Let me point one more thing about Base-16 out to understand why I’m doing what I am below:

16⁰ = 1

16¹ = 16

Taking the  portion C0A8:6301, first divide the address into 2 Tuple-groupings (2 Hex Characters) = C0 A8 63 01

Step1 >

Take C0 and multiply the first character ‘C’ by 16 and the second character ‘0’ by 1.
Add the two decimal values together to get the IPv4 decimal value
IE: ((C=12)*16) + (0*1) = 192

Step2 >

Repeat the same process with A8,
IE: ((A=10)*16) + (8*1) = 168

Step3 >

Repeat the same process with 63,
IE: (6*16) + (3*1) = 99

Step4 >

Repeat the same process with 01,
IE: (0*16) + (1*1) = 1

This will give you an IPv4 address of 192.168.99.1

Easy, easy!

OSPF Area and LSAs Propagation

The link-state advertisement (LSA) is a basic communication means of the OSPF routing protocol for the Internet Protocol (IP). It communicates the router's local routing topology to all other local routers in the same OSPF area. OSPF is designed for scalability, so some LSAs are not flooded out on all interfaces, but only on those that belong to the appropriate area. In this way detailed information can be kept localized, while summary information is flooded to the rest of the network. The original IPv4-only OSPFv2 and the newer IPv6-compatible OSPFv3 have broadly similar LSA types.

The LSA types defined in OSPF are as follows:

• Type 1 - Router LSA - the router announces its presence and lists the links to other routers or networks in the same area, together with the metrics to them. Type 1 LSAs are flooded across their own area only. The link-state ID of the type 1 LSA is the originating router ID.

• Type 2 - Network LSA - the designated router (DR) on a broadcast segment (e.g. Ethernet) lists which routers are joined together by the segment. Type 2 LSAs are flooded across their own area only. The link-state ID of the type 2 LSA is the IP interface address of the DR.

• Type 3 - Summary LSA - an Area Border Router (ABR) takes information it has learned on one of its attached areas and summarizes it before sending it out on other areas it is connected to. This summarization helps provide scalability by removing detailed topology information for other areas, because their routing information is summarized into just an address prefix and metric. The summarization process can also be configured to remove a lot of detailed address prefixes and replace them with a single summary prefix, helping scalability. The link-state ID is the destination network number for type 3 LSAs.

• Type 4 - ASBR-Summary LSA - this is needed because Type 5 External LSAs are flooded to all areas and the detailed next-hop information may not be available in those other areas because it may be using a different routing protocol. This is solved by an Area Border Router flooding the information for the router (i.e. the Autonomous System Boundary Router) where the type 5 originated. The link-state ID is the router ID of the described ASBR for type 4 LSAs.

• Type 5 - External LSA - these LSAs contain information imported into OSPF from other routing processes. They are flooded to all areas unchanged (except stub and NSSA areas). For "External Metric Type 1" LSAs routing decisions are made using the Type 1 metric cost sent, as the total cost to get to the external destination and includes the cost to the ASBR; while for "External Type 2" LSAs the metric sent is the cost from the ASBR to the External destination network and must be added to the OSPF cost to the ASBR advertising the Type 5. The link-state ID of the type 5 LSA is the external network number.

• Type 6 - Group Membership LSA (Only supported on a few routers) - this was defined for Multicast extensions to OSPF (MOSPF), a multicast OSPF routing protocol which was not in general use. MOSPF has been deprecated since OSPFv3 and is not currently used. It may be reassigned in the future.

• Type 7 - Routers in a Not-so-stubby-area (NSSA) do not receive external LSAs from Area Border Routers, but are allowed to send external routing information for redistribution. They use type 7 LSAs to tell the ABRs about these external routes, which the Area Border Router then translates to type 5 external LSAs and floods as normal to the rest of the OSPF network.

• Type 8 - A link-local only LSA for OSPFv3. A Type 8 LSA is used to give information about link-local addresses and a list of IPv6 addresses on the link. In OSPFv2, however, the Type 8 was originally intended to be used as a so-called External-Attributes-LSA for transit autonomous systems where OSPFv2 could replace the internal Border Gateway Protocol (iBGP). In these networks, the BGP destinations would be carried in LSA Type 5 while their BGP attributes would be inserted into LSA Type 8. Most OSPFv2 implementations never supported this feature.

• Type 9 - a link-local "opaque" LSA (defined by RFC2370) in OSPFv2 and the Intra-Area-Prefix LSA in OSPFv3. It is the OSPFv3 LSA that contains prefixes for stub and transit networks in the link-state ID.

• Type 10 - an area-local "opaque" LSA as defined by RFC2370. Opaque LSAs contain information which should be flooded by other routers even if the router is not able to understand the extended information itself. Typically type 10 LSAs are used for traffic engineering extensions to OSPF, flooding extra information about links beyond just their metric, such as link bandwidth and color.
• Type 11 - an AS "opaque" LSA defined by RFC 5250, which is flooded everywhere except stub areas. This is the opaque equivalent of the type 5 external LSA

BGP Path Selection Process

 1. Largest Weight

- Cisco proprietary. Only valid on the router it is configured on. It is not passed to other routers.

2. Highest Local Preference

- Highest Local Pref is preferred. Local Pref does not get passed between different ASs
- Due to the above reason, customers are sending/using BGP community string with their announcements
- Local Pref does get passed between confederations (sub-ASs).

3. Locally Originated

- Prefer the path that was locally originated via a network or aggregate BGP subcommand, or through redistribution from an IGP. Local paths sourced by network or redistribute commands are preferred over local aggregates sourced by the aggregate-address command.

4. Shortest AS Path

- An AS_SET counts as 1, no matter how many ASs are in the set
- The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_PATH length.
- (**Confederation hops ARE NOT counted as hops)

5. Lowest Origin Type

- Prefer the path with the lowest origin type: IGP is lower than EGP, and EGP is lower than INCOMPLETE. (IGP < EGP < Incomplete)
- IGP origin is created when there is a network statement
-EGP origin is created via ‘redistribute
-Incomplete origin is created via redistribute

6. Lowest MED(multi-exit discriminator)

- Only compared when the AS path entering our network is the same. EX. 777 2 33 and 777 2 44 - metrics compared¦.777 2 44 and 777 3 44
- metrics NOT compared. NOTE  MED is different than IGP metric. MED is assigned by the end-user, the IGP metric is determined via the ISIS settings on our backbone.

7. eBGP over iBGP

- Routes are preferred over iBGP routes. eBGP routes are those learned via eBGP sessions (ie different ASs). iBGP routes are learned via iBGP sessions (same AS).

8. Lowest IGP metric

- IGP metrics are the internal routing protocols that BGP uses to reach the next-hop ip address(MCI backbone uses ISIS and MPLS).
- Prefer the path with the lowest IGP metric to the BGP next hop. Continue, even if bestpath is already selected.

9. Maximum paths

- Check if multiple paths need to be installed in the routing table for BGP Multipath. Continue, if bestpath is not selected yet

10. Oldest one(External)

- When both paths are external, prefer the path that was received first (the oldest one). This step minimizes route-flap, since a newer path will not displace an older one, even if it would be the preferred route based on the next decision criteria

11. Lowest Router ID

- Prefer the route coming from the BGP router with the lowest router ID
-If a path contains route-reflector (RR) attributes, the originator ID is substituted for the router ID in the path selection process
- The router ID is the highest IP address on the router, with preference given to loopback addresses. It can also be set manually using the bgp router-id command.

12. Minimum Cluster ID/list length

- This will only be present in BGP route-reflector environments

13. Lowest IP

- Prefer the path coming from the lowest neighbor address. This is the IP address used in the BGP neighbor configuration, and corresponds to the remote peer used in the TCP connection with the local router.

BGP

• BPG Attributes
• BGP Path Selection
• BGP ASN
  
• BGP ASN - AS-PLAIN to AS-DOT (and AS-COLON) calculator and back
  
• 
  

DMVPN

 TOPOLOGY:                                        Click image to zoom in

CONFIGURATIONS (for IOS): Without IPsec

###HUB###

interface Tunnel0
 ip address 10.50.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 no ip split-horizon eigrp 123
 ip tcp adjust-mss 1360
 tunnel source Serial0/0
 tunnel mode gre multipoint
!
router eigrp 123
 network 10.50.0.0 0.0.0.255
 network 192.168.10.0
 no auto-summary

------------------------------
###SPOKE1###

interface Tunnel0
 ip address 10.50.0.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp map 10.50.0.1 200.0.101.2
 ip nhrp map multicast 200.0.101.2
 ip nhrp network-id 1
 ip tcp adjust-mss 1360
 ip nhrp nhs 10.50.0.1
 ip nhrp shortcut
 tunnel source Serial0/0
 tunnel mode gre multipoint
!
router eigrp 123
 network 10.50.0.0 0.0.0.255
 network 192.168.20.0
 no auto-summary
------------------------------
###SPOKE2###

interface Tunnel0
 ip address 10.50.0.3 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp map 10.50.0.1 200.0.101.2
 ip nhrp map multicast 200.0.101.2
 ip nhrp network-id 1
 ip tcp adjust-mss 1360
 ip nhrp nhs 10.50.0.1
 ip nhrp shortcut
 tunnel source Serial0/0
 tunnel mode gre multipoint
!
router eigrp 123
 network 10.50.0.0 0.0.0.255
 network 192.168.30.0
 no auto-summary

==============================================================

CONFIGURATIONS (for IOS): With IPsec

###HUB###

crypto isakmp policy 10
 hash md5
 authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set DMVPN esp-aes esp-sha-hmac
!
crypto ipsec profile DMVPN-PROFILE
 set security-association lifetime seconds 86400
 set transform-set DMVPN

interface Tunnel0
 ip address 10.50.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 no ip split-horizon eigrp 123
 ip tcp adjust-mss 1360
 tunnel source Serial0/0
 tunnel mode gre multipoint
 tunnel key 0
 tunnel protection ipsec profile DMVPN-PROFILE
!
router eigrp 123
 network 10.50.0.0 0.0.0.255
 network 192.168.10.0
 no auto-summary

------------------------------
###SPOKE1###

crypto isakmp policy 10
 hash md5
 authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set DMVPN esp-aes esp-sha-hmac
!
crypto ipsec profile DMVPN-PROFILE
 set security-association lifetime seconds 86400
 set transform-set DMVPN

interface Tunnel0
 ip address 10.50.0.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp map 10.50.0.1 200.0.101.2
 ip nhrp map multicast 200.0.101.2
 ip nhrp network-id 1
 ip tcp adjust-mss 1360
 ip nhrp nhs 10.50.0.1
 ip nhrp shortcut
 tunnel source Serial0/0
 tunnel mode gre multipoint
 tunnel key 0
 tunnel protection ipsec profile DMVPN-PROFILE
!
router eigrp 123
 network 10.50.0.0 0.0.0.255
 network 192.168.20.0
 no auto-summary
------------------------------
###SPOKE2###

crypto isakmp policy 10
 hash md5
 authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set DMVPN esp-aes esp-sha-hmac
!
crypto ipsec profile DMVPN-PROFILE
 set security-association lifetime seconds 86400
 set transform-set DMVPN

interface Tunnel0
 ip address 10.50.0.3 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp map 10.50.0.1 200.0.101.2
 ip nhrp map multicast 200.0.101.2
 ip nhrp network-id 1
 ip tcp adjust-mss 1360
 ip nhrp nhs 10.50.0.1
 ip nhrp shortcut
 tunnel source Serial0/0
 tunnel mode gre multipoint
 tunnel key 0
 tunnel protection ipsec profile DMVPN-PROFILE
!
router eigrp 123
 network 10.50.0.0 0.0.0.255
 network 192.168.30.0

 no auto-summary

==========================================================

TSHOOT/SHOW COMMANDS:

HUB#show dmvpn 

Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

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

     1     200.0.102.2       10.50.0.2    UP    never D    

     1     200.0.103.2       10.50.0.3    UP    never D    

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

HUB#show dmvpn detail 

Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

 -------------- Interface Tunnel0 info: -------------- 

Intf. is up, Line Protocol is up, Addr. is 10.50.0.1

   Source addr: 200.0.101.2, Dest addr: MGRE

  Protocol/Transport: "multi-GRE/IP", Protect "",

Tunnel VRF "", ip vrf forwarding ""

NHRP Details: 

Type:Hub, NBMA Peers:2

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network

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

    1     200.0.102.2       10.50.0.2    UP 00:01:14 D          10.50.0.2/32

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network

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

    1     200.0.103.2       10.50.0.3    UP 00:01:16 D          10.50.0.3/32

Pending DMVPN Sessions:

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

HUB#show crypto session detail 

Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection     

K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication

F - IKE Fragmentation

Interface: Tunnel0

Uptime: 00:01:18

Session status: UP-ACTIVE     

Peer: 200.0.102.2 port 500 fvrf: (none) ivrf: (none)

      Phase1_id: 200.0.102.2

      Desc: (none)

  IKE SA: local 200.0.101.2/500 remote 200.0.102.2/500 Active 

          Capabilities:(none) connid:1002 lifetime:23:58:40

  IPSEC FLOW: permit 47 host 200.0.101.2 host 200.0.102.2 

        Active SAs: 2, origin: crypto map

        Inbound:  #pkts dec'ed 43 drop 0 life (KB/Sec) 4488782/86321

        Outbound: #pkts enc'ed 24 drop 0 life (KB/Sec) 4488785/86321

Interface: Tunnel0

Uptime: 00:01:20

Session status: UP-ACTIVE     

Peer: 200.0.103.2 port 500 fvrf: (none) ivrf: (none)

      Phase1_id: 200.0.103.2

      Desc: (none)

  IKE SA: local 200.0.101.2/500 remote 200.0.103.2/500 Active 

          Capabilities:(none) connid:1001 lifetime:23:58:39

  IPSEC FLOW: permit 47 host 200.0.101.2 host 200.0.103.2 

        Active SAs: 2, origin: crypto map

        Inbound:  #pkts dec'ed 27 drop 0 life (KB/Sec) 4605932/86319

        Outbound: #pkts enc'ed 28 drop 0 life (KB/Sec) 4605932/86319

HUB#show crypto isakmp sa      

IPv4 Crypto ISAKMP SA

dst             src             state          conn-id slot status

200.0.101.2     200.0.103.2     QM_IDLE           1001    0 ACTIVE

200.0.101.2     200.0.102.2     QM_IDLE           1002    0 ACTIVE

IPv6 Crypto ISAKMP SA

HUB#show crypto isakmp key     

Keyring      Hostname/Address                            Preshared Key

default      0.0.0.0        [0.0.0.0        ]            cisco123

HUB#show ip eigrp neighbors 

IP-EIGRP neighbors for process 123

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   10.50.0.2               Tu0               13 00:03:00  162  5000  0  3

0   10.50.0.3               Tu0               12 00:03:01  155  5000  0  3

OSPF

 OSPF

• OSPF Cheat Sheet

• OSPF Neighbor States

• OSPF Area and LSAs Propagation

• OSPF Special Area Types (video)

• Configuring OSPF Special Area Types (video)

• OSPF Design Guide

• OSPF Area Types

• OSPF LSAs

TCP and UDP

The Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are the two most popular protocols in the transport layer. They ensures that messages are delivered error-free, in sequence, and with no losses or duplication. The key difference between TCP and UDP is that TCP provides a wide variety of services to applications, whereas UDP does not. At the result of this, TCP is much more complex than UDP so this tutorial is dedicated to explore TCP in detail but we still compare them.

Both TCP and UDP are protocols at the Transport layer (of both OSI and TCP/IP model) but why we need both of them? The answer is:

+ TCP is slower but reliable
+ UDP is faster but unreliable

In most cases we will want to be reliable in web accessing, email communicating, file uploading… as we don’t expect a few corrupted packets would destroy our whole work. With TCP, these corrupted packets will be resent or repaired to make sure everything is correct. Yes, TCP is really nice to ensure your work is accurate!

But with a price…

To guarantee the sending segments is free of error, TCP adds some bits for tracking and checking purpose so that the other end can verify and ask for missing pieces of segments. As a result of this, the segments become larger, consume more bandwidth and CPU resources to proceed.

Although UDP cannot guarantee everything is accurate like TCP but UDP is faster than TCP because it does not require additional bits for tracking and checking purpose. So which tasks need speed? Video (streaming) and audio are ideal for this task because they are considered real-time applications. Suppose you are talking to your friend, surely you want your voice to reach your friend without any delay. It would be very weird if your friend can only hear your voice after a few seconds.

Note: Segment is the name of the data packet at Transport layer

TCP can also slow down the transmission if it sees the path to the destination is too crowded. You don’t want TCP to slow down your voice in traffic-jam hours either. For example when you say “Hello, how are you?”, your friend at the other end may hear “Hellooooo,…… hooooooooow arrrrrrrre yyyyyoou”. What is an awful conversation!

Losing a few packets for voice or video is acceptable. For example if you say the word “Hello” in one second, an IP phone generates about 25 to 100 packets (just an estimation, it depends on the codec and sampling frequency) so your friend can still understand what you say even if a few packets are missing. Moreover, re-transmission the missing packets is not useful as voice and video are real-time applications and the receiving end cannot wait for the missing segments to be resent.

So now we have some basic understanding of TCP and UDP. In the next part we will learn more about TCP. Let’s start with how TCP set up and terminate a connection.

TCP three-way handshake (to start the communication)

Suppose host A wants to start communicating with host B using TCP. Before they can send real data, a three-way handshake must be established first. Let’s see how this process takes place:

1. First host A will send a SYN message (a TCP segment with SYN flag set to 1, SYN is short for SYNchronize) to indicate it wants to setup a connection with host B. This message includes a sequence (SEQ) number for tracking purpose. This sequence number can be any 32-bit number (range from 0 to 2³²) so we use “x” to represent it.

2. After receiving SYN message from host A, host B replies with SYN-ACK message (some books may call it “SYN/ACK” or “SYN, ACK” message. ACK is short for ACKnowledge). This message includes a SYN sequence number and an ACK number:
+ SYN sequence number (let’s called it “y”) is a random number and does not have any relationship with Host A’s SYN SEQ number.
+ ACK number is the next number of Host A’s SYN sequence number it received, so we represent it with “x+1”. It means “I received your part. Now send me the next part (x + 1)”.

The SYN-ACK message indicates host B accepts to talk to host A (via ACK part). And ask if host A still wants to talk to it as well (via SYN part).

3. After Host A received the SYN-ACK message from host B, it sends an ACK message with ACK number “y+1” to host B. This confirms host A still wants to talk to host B.

If you are still unclear about this process, let’s assign: x = 1 and y = 50:

In this process, three messages need to be sent so we often call it “three-way handshake”.

Nice, now you really understand TCP three-way handshake, right? Host A can start sending real traffic to host B after the three-way handshake process.

TCP also does nearly the same thing when one end wants to terminate the connection with TCP four-way termination process.

TCP four-way termination (to end the communication)

Suppose Host A wants to end the connection to host B, Host A will send a FIN message (a TCP segment with FIN flag set to 1), FIN is short for FINISH. The purpose of FIN message is to enable TCP to gracefully terminate an established connection. Host A then enters a state called the FIN-WAIT state. In FIN-WAIT state, Host A continues to receive TCP segments from Host B and proceed the segments already in the queue, but Host A will not send any additional data.

Device B will confirm it has received the FIN message with an ACK (with sequence x+1). From this point, Host B will no longer accept data from Host A. Host B can continue sending data to Host A. If Host B does not have any more data to send, it will also terminate the connection by sending a FIN message. Host A will then ACK that segment and terminate the connection.

TCP requires to establish and terminate the connection before and after exchanging real traffic so it is called connection-oriented protocol. UDP does not support these features so it is called connectionless protocol.

More formally, these terms can be defined as follows:
+ Connection-oriented protocol: requires a logical connection to be established between the two processes before data is exchanged
+ Connectionless protocol: allow data to be exchanged without setting up a link between processes

In conclusion, TCP requires the establishment (via three-way handshake) and termination (via four-way termination) of a connection. In the next part we will learn about popular TCP features.

TCP Features

Some popular TCP features we will learn here are: Multiplexing using port numbers, Flow control using windowing and Reliability (Error Detection and Error recovery)

Multiplexing using port numbers

Suppose you are using a laptop for web browsing, email communicating and FTP uploading at the same time. All of them require using TCP while your laptop only has one IP address (with one network card) so how your laptop knows which packets received from the Internet are dedicated for which application?

Above question is solved with port numbers. Each application will use a different and available port number to communicate with outside world. For example your laptop can choose port 50000 for web browsing, port 50001 for email communicating and port 50002 for FTP uploading.

Notice that your laptop can choose any available source port but it must use pre-defined destination ports for well-known services. Port numbers are defined in three ranges:
+ Well-known port numbers (0 through 1023): assigned to key or core services that systems offer
+ Registered port numbers (1024 through 49151): assigned to industry applications and processes. For example: 1433 is assigned for Microsoft SQL Server process)
+ Dynamic port numbers (49152 through 65535): used as temporary ports for specific communications. Our laptop can use these ports for communication

The table below lists TCP ports for well-known services:

TCP Service	Description	Port
FTP	File Transfer Protocol	20, 21
SSH	Secure shell	22
Telnet	Terminal network	23
SMTP	Simple Mail Transfer Protocol	25
DNS	Domain Name Server	53
HTTP	Hyper Text Transfer Protocol	80
HTTPS	Hyper Text Transfer Protocol Secure	443

Note: There are some other well-known ports that are not listed here. The well-known ports are assigned by the Internet Assigned Numbers Authority (IANA) in the range of 0 to 1023.

Multiplexing relies on a concept called a socket. A socket consists of three things:

+ An IP address
+ A transport protocol
+ A port number

So suppose the IP address on our laptop is 123.1.1.1 and use TCP to access web server with port 50000, we may write the socket (123.1.1.1, TCP, 50000). For web server application running on the Web Server with IP 200.1.1.1 the socket should be (200.1.1.1, TCP, 80) as the web server uses the well-known port 80 for HTTP.

The socket on each computer is unique so the connection between two sockets on two computers identify a unique connection between them. Therefore you can use multiple applications on the same computer at the same time. Each application will use a unique source port so they cannot interfere with each other.

We only mentioned about source ports but notice TCP header requires both source port and destination port. That means if our laptop wants to connect to a Web Server it must include the destination port in TCP header as well. The destination port for Web Server in this case is 80. When the Web Server replies to our laptop, it uses the laptop’s source port as its destination port (50000 in this case).

Note: Both TCP and UDP use multiplexing with port numbers for their services.

Flow-control using windowing

In the TCP header there is a field called “Window” which plays an important role in the TCP transmission. A “Window” specifies the number of segments the sender can forward without receiving an acknowledgment. It is the key to transfer data and flow control efficiently. Let’s see how it works!

After the TCP connection has been established, both the client and server use this Window field to tell the other how many bytes of data it is willing to receive at one time before sending an acknowledgement to the sender. The larger the window size number (in bytes), the greater the amount of data that the host can transmit. For example, with a Window size of 1 (byte), every one byte must be acknowledged before sending the next one.

But waiting for ACK after each segment would be very inefficient. So TCP tries to increase the Window size to 3 (bytes), which means every three bytes can be received before sending the acknowledgement.

As you can see, the bigger the Window size, the fewer ACKs needed to be sent and the more efficient the transmission is. So the receiver will try to increase the Window size after each successful transmission so that the sender can send more. But the Window size cannot increase forever, TCP stops increasing the Window size when the receiver does not send an ACK (within a specific time period) or when the Window size reaches its maximum value. If a congestion occurs on the link then TCP may decrease the Window size.

The window size is variable during the lifetime of a connection so we often refer it as a “sliding window”.

If the sender does not receive the ACK in time, it knows that the segments should be resent, and that the transmission rate should be slowed down. Suppose Host A did not receive the expecting ACK 7 then it knows segments 4, 5, 6 should be resent.

Reliability (Error Detection and Error recovery)

This is the most important feature of TCP. TCP must recover from data that is damaged, lost, duplicated during the transmission. But please grasp the difference between error detection and error recovery first:
+ Error detection: the detection of errors during the transmission. Error detection does not repair corrupted data, it just detects it
+ Error recovery: the detection of errors and repair them

To achieve error detection, TCP adds some extra bits to the data, called checksum. A TCP sender computes the checksum value based on the contents of the TCP header and data fields. This 16-bit value will be compared with the value the receiver generates using the same computation. If the values match, the receiver can believe that segment arrived intact. If the values do not match, the receiver indicates an error occurred and the segment is discarded and a notification will be sent to the receiver depending on how the TCP stack is implemented on the receiver’s operating system.

To achieve error recovery, TCP uses the Sequence number (at the sender’s side) and Acknowledgement fields (at the receiver’s side) in the TCP header. These two fields are also used to find out lost, duplicated segments. Let’s see an example.

In the transmission below, host A sends three segments 1, 2, 3 to host B. Segment 2 was lost while segment 3 arrived to Host B. Then Host B replied with an ACK 2, implying that it is expecting segment 2 next. Host A can re-send another segment 2 to recover the lost segment. If Host B receive that segment it will ask for the segment 4 (because it already has segment 3).

Error recovery

You may ask “what will happen if the ACK 2 sent from Host B is also lost?” In fact, after sending each segment Host A sets a retransmission timer, just in case the ACK is lost (or all the sending segments are lost; Host B would not send ACK in this case because it did not receive anything). If this timer expires, Host A will send all the segments again.

Note: UDP does support error detection (via checksum) but it does not support error recovery. If UDP finds a corrupted segment, it just simply drop it.

Let’s sum up all things we learned about TCP and UDP so far.

Same:

+ Both TCP and UDP operate at Transport Layer
+ Both TCP and UDP use Multiplexing via port numbers

Difference:

TCP	UDP
Reliable	Unreliable
Connection-oriented	Connectionless
Segment retransmission and flow control through windowing	No retransmission or windowing
Segment sequence	No sequencing
Acknowledge segment	No acknowledgement
Start and end the communication by three-way handshake and four-way termination	No action is required before and after sending real data

Finally we show the TCP and UDP header in detail for your reference. There are some fields which are out of scope of this tutorial.

TCP Header (20 bytes)

Notice about the FLAG fields (between the “Reserved” and “Window Size” fields). If SYN bit is turned on, it is a SYN message. If ACK bit is turned on, it is an ACK message. If both SYN and ACK bits are turned on, it is a SYN-ACK message.

And this is the UDP header:

UDP Header (8 bytes)