Showing posts with label OSPF. Show all posts
Showing posts with label OSPF. Show all posts

Thursday, August 2, 2018

Everything You Need to Know About OSPF

"Everything you'll ever need to know about OSPF" is a bold statement but is goes back to "Mastering the Foundations" something I've been saying for the past 25 days. If you can master these OSPF foundations the rest is icing on the cake.

PRO-TIP: Don't treat this as a long list of items to memorize but rather a checklist of topics to lab up.

Default Behavior

  • Won't start unless OSPF can determine a router-id
  • Router-id determined:
    1. Configured router-id
    2. Highest loopback IP address
    3. Highest interface IP address
  • Every router within an area must have the same OSPF database
  • Filtering/Summaries happen at the ABR
  • Default Priority = 1, highest priority becomes the DR (where applicable)
    • A Priority of "0" means router will NOT participate in DR/BDR elections.

OSPF Network Types

Broadcast

  • Default for Ethernet interfaces
  • Elects DR/BDR
  • Uses Multicast
  • Allows more than 2 routers on a link
  • Timers: Hello - 10, Dead  - 40

Non-Broadcast

  • Elects a DR/BDR
  • Uses Unicast (neighbor statements)
  • Allows more the 2 routers on a link
  • Timers: Hello - 30, Dead - 120

Point-to-Point

  • Default for Serial and Tunnel interfaces
  • Does NOT elect DR/BDR
  • Uses Multicast
  • Only 2 routers allowed on a link
  • Timers: Hello - 10, Dead - 40

Point-to-MultiPoint

  • Does NOT elect DR/BDR
  • Uses Multicast
  • Allows more than 2 routers on a link
  • Installs /32 host routes per neighbor
  • Timers: Hello - 30, Dead - 120

Point-to-MultiPoint Non-Broadcast

  • Does NOT elect DR/BDR
  • Uses Unicast (neighbor statements)
  • Allows more than 2 routers on a link
  • Installs /32 host routes per neighbor
  • Timers: Hello - 30, Dead - 120

Loopback

  • Default for Loopback interfaces
  • When included in OSPF, uses a /32
    • To advertise with mask other-than /32, manually set network type to "point-to-point"


LSA Types

LSA Type-1: Router LSA's

  • Originated from each router
  • Flooded within an area
  • Tells the area about all the links participating in OSPF and are associated with that area

LSA Type-2: Network LSA's

  • Originated by the DR
  • Only DR can originate Type-2 LSA's (If there is no DR their aren't any Type-2's)
  • This LSA tells all the routers in an area about all the routers on a shared medium like Ethernet

LSA Type-3: Summary LSA's

  • Originated by an ABR
  • Carry the destination network prefixes from one area into another
From nonbackbone > backbone
  • Connected Routes
  • Intra-Area Routes
From backbone > nonbackbone
  • Connected Routes
  • Intra-Area Routes
  • Inter-Area Routes

LSA Type-4: ASBR-Summary LSA's

  • Originated by an ABR
  • Tells all the other areas about the ASBR
  • Tells all the other areas "to get to this Router-ID(ASBR) go through Me(ABR)!"

LSA Type-5: External LSA's

  • Originated by an ASBR
  • Flooded through out the OSPF domain, except into stubby areas
  • Contains the Network prefix and subnet-mask for the external network

LSA Type-7: NSSA External LSA's

  • Originated by ASBR
  • Exist only in a Not-So-Stubby Area (NSSA)
  • Are NOT flooded outside the area they were originated

Area Types

Backbone Area

  • Area 0
  • Act's as the HUB for all other areas
  • Accepts all LSA Types

Normal Area

  • All non-stub areas
  • Allows LSA's Type: 1, 2, 3, 4, 5 & External Default

Stub Area

  • Allows LSA Types: 1, 2, 3 & Summary Default Route ( No External Type-5's )

Totally Stubby Area

  • Allows LSA Types: 1, 2 & Summary Default Route

Not-So-Stubby Area (NSSA)

  • Allows LSA Types: 1, 2, 3, 7 ( No External Type-5's )
  • NSSA's allow redistributing into an area but still maintain it's 'stub area' properties (not allowing External Type-5's)
  • Redistributed routes are converted to Type-7 LSA's and advertised throughout the area by the ASBR
  • The ABR converts Type-7 LSA's into Type-5's before advertising them into the backbone area.
  • LSA Type-7's are only flooded within the area they originate

Totally Not-So-Stubby Area (NSSA)

  • Allows LSA Types: 1, 2, 7 & Summary Default Route ( No External Type-5's )
  • NO LSA Type-3's


Route Types

  • O = Intra-area Route
  • O IA = Inter-area Route (Generated by Type-3 LSA's)
  • E1 = External Metric Type-1 (Generated by Type-5 LSA's)
  • E2 = External Metric Type-2 (Generated by Type-5 LSA's)
  • N1 = NSSA Metric Type-1
  • N2 = NSSA Metric Type-2


Sunday, November 19, 2017

Future = Application Layer Networking

I was having a conversation with a peer about the future of networking. The foundation of the conversation revolved around SDN and the changes that SDN brings to network operators and engineers. The point was raised to me that 'engineers and operators of future networks won't need to have the granular low level understanding of bits, bytes and protocols.' As control of the network becomes more and more software driven the engineer/operator needs only high level understanding. My response to that is: Nothing could be further from the truth! My prediction for the future is: true application layer networking. Have a predictable and deterministic path through the network based on application only.

I think in the future, of application layer routing, we will need to incorporate some level of routing intelligence on each host/end device. I'm not sure exactly what that will look like yet but, I know it is not along the lines of OSPF or EIGRP.

In our current model, for most networks (home networks and small business networks) there is a single egress point where all traffic leaves your LAN to destinations on the internet.

In mid-sized business/enterprise you'll have redundant links a backups. You may have site-to-site tunnels with IPSEC connected remote sites but anything not on your LAN or part of your remote sites still egresses a single point to destinations on the internet.

Large businesses/Enterprises may have multiple egress points to the internet, all managed by lead engineers and operators with oversight from the senior engineers, involving multiple AS's and public IPv4 subnets that span the globe. This is expensive and the bottom line is, even with all the sophistication, the workstations and end devices are still taking the shortest path out of the network based on destination IP address and not on application specific characteristics.

Routers are doing destination based forwarding all over the globe. They are not making routing decisions based on the the type of traffic in the payload of the packet.

One thing I foresee SDN doing for us is bringing dynamic intelligence into routing. Having your controller understand the link requirements of protocols and identify those protocols as they are passing through the routers and forward them based on the application traffic they are carrying not just their destination IP address.

Another thing I believe the future holds for us is true multi-path routing, where end devices, even a common smart phone, can have multiple gateways and not just redundant default gateways, instead they would be application specific gateways. For example I could be connected to my cellular network, wifi and maybe a bunch of ad-hoc networks all at the same time. Perhaps those ad-hoc networks have gateways of their own and we can use them to egress to the internet essentially giving a device like our phone, multiple egress points. Letting our devices participate in the decision making process for routing and forwarding and how to best utilize the links available to it on a per-application basis.

Sorry I went off on a minor futuristic sci-fi routing tangent for a moment.

To bring this full circle, I feel like the engineers and operators of the future will actually need to know more about the inter-workings of each protocol more than just Layer 4. If the future is anything close to application layer networking, we will actually need to be closer to the bits and bytes to understand the protocol of the applications themselves in-order to programmatically and deterministically route them to their destinations.

P.S. - I'm not talking about getting rid of IP addresses but instead introduce more to forwarding than just the destination. I'm sure all the "every packet should be treated equal" people out there are going to have a fit with this.

Comments are welcomed.