Ugrás a fő tartalomra

CCIE SP v5.x Lerning journey #xxxxx3 Deep Dive of IGPs: OSPF part 1

 Everything what you do not want know about the OSPF!

In a Service Provider network, one of the most important part is the IGP (Interior Gateway Protocol). Why? Because the network core convergence and routing strategy is depend on the IGP routing rules. If the IGP can not support some features what  are needed for the traffic engineering, it could be a  future operation or development problem.
So SPs select IGPs which are satisfy every operational and business needs, and it will be a future proof protocol.

Star Wars Yoda Meme - Imgflip

Many of service providers typically choose OSPF or ISIS for IGP, because:

- they are RFC and ITU-T conform, vendor independent protocols (in general)

- they support MPLS traffic engineering features (OSPF opaque LSA 10 11)

- link-state routing protocols, which means  that these can provide faster convergence than vector-path or distance vector protocols, and they are more scalable.

What is OSPF?

 OSPF (Open Shortest Path First) protocol is a dynamic link-state based routing protocol, which is responsible to select the shortest path from the OSPF database and inject it to the routing table. The SPF algorithm (Dijkstra's algorithm) is used by OSPF for the path cost calculation. Based on  path cost  (and other OSPF parameters) the router can select the shortest route and make forwarding decision to route the packet to the next-hop router or ip address.

History

OSPF (Open Shortest Path First) protocol is started to develop by the IETF in 1987. OSPFv1 was standardized by RFC 1131 and first implementation  was designed for UNIX workstation and routers. OSFPv1 did not support classless routing and VLSM. 

OSPFv2 released in RFC 1247 and it design for CIDR and VLSM.

OSPFv2 updated by RFC 2178 and the last RFC is 2328 at 1998.

Many newer RFC update the basics of OSPFv2 which means that the OSPFv3 does not obsolete the OSPFv2 and the the versions are not compatible with each other.

The following updates and expansions are available from the IETF:

https://datatracker.ietf.org/doc/html/rfc1587

https://datatracker.ietf.org/doc/html/rfc3101

https://www.rfc-editor.org/rfc/rfc6845

https://www.rfc-editor.org/rfc/rfc6860

https://www.rfc-editor.org/rfc/rfc7474

https://www.rfc-editor.org/rfc/rfc8042

https://www.rfc-editor.org/rfc/rfc9355

https://www.rfc-editor.org/rfc/rfc9454

https://www.rfc-editor.org/rfc/rfc6549

https://www.rfc-editor.org/rfc/rfc5709

They are really interesting reads about the protocol updates (not really), so if somebody interested in bit and byte fucking they can read more about that.

Classic early computer show | Bits and Bytes Episode 1: Getting Started  1983 - YouTube

Why is important to know these RFCs to CCIE exam?

Because there is huge difference in IOS-XE and IOS-XR OSPF implementation. Since XE based routers from IOS 15.7 release implemented by the RFC 3101 and IOS-XR platform still use the RFC1587. What does it mean it human language?

For the answer we know more about OSPF path selection.

OSPF path selection

OSPF basically select the lowest cost metric prefix. It is not really true, because the path selection method is gonna be the following:

- longest prefix match  (actually it is a basic router function not specific for OSPF)

-  type of OSPF route

- cost metric (lasr)

OSPF route types are the following:

O          - Intra-Area

O IA     - Inter-Area

E1        - External Type 1

N1        -NSSA Type 1

E2        -External Type 2

N2        -NSSA Type 2

In RFC 1587 the route preference is the following:
O>O IA>E1>N1>E2>N2

In RFC 3101 the NSSA routes are better than external routes:
O>O IA>N1>E1>N2>E2

Now you see how the stronger dog (OSPF type) validate the right for the love :)

Is it easy? Not sure! For understand the type of OSPFv2 routes you need to understand concept of areas and area types.

What is OSPF Area?

Areas can help to reduce the OSPF Link State DataBase (LSDB)  in a regular area. OSPF routers know details about their network topology which are connected in the same routing domain (area). The routers do not have detailed information from outside of the topology. The LSDB must be synchronized between the routers which are belong to the same area. Based on the topology there are 5 type of areas can be differentiated:

 - normal / general area

 - backbone area (0 or 0.0.0.0)
   It is an special area which responsible to connect the other areas each other.

 - stub area

 - totally stub area

 - not so stub area

 - totally not so stub area

Based on the router position in the area topology the routers can be:

- regular routers

- DRs       - Designated Routers

- BDRs     - Backup Designated Routers

Routers in a topology are typically connected to the same ospf area on point-to-point links, if the network type is not configured, the automatic type is going to be broadcast in a case of Ethernet interface, which means that OSPF DR/BDR election can be happened during the adjacency process.

Adjacency process should be the following:

DOWN

INIT

EXTSTART

EXCHANGE

2WAY

LOADING

FULL

In a case of broadcast network type the OSPF neighbor adjacency state could be FULL/DR or FULL/BDR. OSPF adjacency state can be checked by show ip ospf neighbor (ios-xe) show ospf neighbor (ios-xr).  DR election is based on the OSPF router-id, the highest id will be the DR, the second highest will be the BDR. In an real broadcast segment only the with DR and BDR router could be in FULL state with other routers. Other adjacency is going to be 2WAY/DROTHER or EXCHANGE/DROTHER, because only the DR will (in case network failure BDR) is going to flood the LSAs in the OSPF area with LSU packet, so the FULL adjacency is need for these two boss.


- ABRs     - Area Border Routers

-ASBRs    - Autonomus System Boundary Routers


Based on the OSPF connection (adjacency) topology the network type can be:

- broadcast

- non broadcast

- point-to-point

- point-to-multi-point

- point-to-multi-point non broadcast

And finally the LSDB contain the prefix information from the areas which is advertised by the routers with LSA packet (Link-State Advertisement) 

The following OSPFv2 LSA are:

- Type 1  - Router LSA

Its deliver detailed information the 

- Type 2 - Network LSA

- Type 3 - Summary LSA

- Type 4 - Summary ASBR

- Type 5 - AS external LSA 

- Type 6 - Multicast OSPF LSA

- Type 7 - NSSA LSA

- Type 8 - External attribute

Opaque

- Type 9 - Link Scope / Intra Area LSA

- Type 10 - Area Scope

- Type 11 - AS Scope

Ok! How the OSPF areas are work, what these stuffs mean?

First we need to understand which LSA responsible for which data. Start with LSA1

LSA1  the router LSA is update from detailed information about the OSPF router connected interfaces. In case of OSPF routers which are belongs to the same regular / normal area LSA1 is going to flooded to all router. LSA1 contain the router own interfaces and the carries information about the neighbors to adjacent router in the same area. LSA1 is not leave the area.


LSA2 Network LSAs generated by the DR to describe all routers to its segment directly. LSA2 packet will be  flooded between the neighbors in the same area of origin and remain with that area.


 LSA3 is a summary LSA which is generated by ABRs and advertise an inter-area router information to the other areas. ABR generate a summary prefix from the area routes. LSA3 is flooded through the areas.

LSA4 ASBR Summary LSA is generated an AS Boundary Router which connected an external routing domain and redistribute the prefixes to OSPF, the Type LSA is represent the sense of ASBR Router connected networks.

 

 LSA5 ASBR external LSA is responsible for the prefixes which are redistributed from an external routing protocol.

 

LSA6 Multicast LSA is not implemented on Cisco Routers, it is deprecated.

LSA7 is special nssa area LSA which is exactly has the same function that LSA5 but in this case the ASBR router is in the nssa area.

 

LSA8 is External Attribute LSA which can be used to carrying BGP attribute information, actually it is not supported most of the routers. BGP destinations actually converted to Type 5.

LSA9 Links Scope Opaque in OSPFv3 carries a special stub information.

LSA10 can extend OSPF function like traffic-engineering information

LSA11 is the function as 10 but it can be flooded in stub areas.

Oh my gosh! Is it still not the end? No! But actually I am tired so... see you in the next post...


Érdekesebb bejegyzések

Hálózat-virtualizáció a gyakorlatban - ACI fabric E01

Cisco ACI Kellett már nekünk mint egy falat kenyér, hogy végre történjen ebben VLAN-okba költözött posványos DC rendszerekkel valami... valami új. Mit tegyünk, ha hálózati infrastruktúrát az határozza meg, hogy adott VLAN-ok, hol vagy hol nem szerepelhetnek az infrastruktúrában, ha egy létesítést 8 különböző IT vezetőnek kell jóváhagyni, ha a felelősség tolása másra fontosabb, mint a projekt végrehajtása. Cisco ACI-ról írni nehéz dolog egy olyan alternatív IT valóságban, ami ma Magyarországon van... Mert amíg azzal küzdünk bizonyos helyeken, hogy az ultrafontos IT app egy 486-os gépen fut, ami csak 10M half-ot tud, addig nem tudjuk a 20 éve EoS demarkációs switch-et lecserélni, a lassan szintén EoS státuszba kerülő "legújabb" Nexus switch-re. Addig felesleges bárminek is a infrastruktúrában alkalmazás centrikusnak lenni, amíg az alkalmazásunkat támogató csapat az eniac-os lyukkártyás időszakon mereng, és még mindig nem fogadja el 21 századot. Mint azt egy korábbi be

SD-WAN vagy SD-NINCS II. epizód Cisco (Viptela) 1

Cisco SD-WAN első rész Bevezető Élek az alkotói szabadság jogával, és ellentétben az eddigiekkel kicsit rövídítek a post címén. Eredetileg ez a sorozat Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS II.rész Cisco (Viptela) 1 címet kapta volna, csak hát: Kib@#&0tul hosszú lenne. Az SD-WAN témakör önmagában megér egy post sorozatot. A Cisco SD-WAN-ról sok mindent lehet írni, így ez is megér egy önálló post sorozatot. Cisco SD-WAN-nak nem kis történelmi háttere van már, hiszen a megoldást szakmai berkekben leánykori néven viptelának is hívják. A Cisco 2017 májusában fejezte be a Viptela akvizícióját, és termékeit saját megoldásként, immáron 3 éve Cisco SD-WAN megoldás részeként kínálja az ügyfelei felé. Azért hivatkozunk a szakzsargonban Viptela néven a megoldásra, mert a Cisco-nak további SD-WAN megoldásai léteznek, illetve léteztek: SD-BRANCH (ENCS platform) Meraki SD-WAN IWAN (performance routing alapú, APIC-EM vezérelt kezdeményezés, ami sajnos kihalt )

Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS I. epizód Fortigate

SD-WAN vagy SD-NINCS I. rész Ez a bejegyzés sorozat ötlete, akkor merült fel bennem, amikor különböző gyártók SD-WAN-nak titulált megoldásait próbáltam összegezni magamban... Figyelemebe véve az alap elképzelést és a technikai megvalósíthatóságot, három kategóriát állítottam fel ezekre megoldásokra: SD-WAN megoldások - melyek biztosítják a transzport agnosztikus átvitelt, lehetőséget adnak a szolgáltatótól független topológia kialakítására központi orkesztráció és kontroll segítségével, továbbá az üzleti alkalmazások számára északi irányú API integrációra adnak lehetőséget. SD-NINCS megoldások - melyek marketing anyagokban szerepeltetik az SD-WAN-t, viszont technikai oldalról csak egy jól komponált policy based routing, ami  maximum megvalósítható. SD-LESZ megoldás - valahol a kettő között... Fortigate SD-WAN Március 13-ka óta HOME-OFFICE-ban dolgozom. Nem volt egyszerű az átállás, legalábbis mentálisan mindenképpen megterhelő a napi feladatok elvégzése úgy, hogy közbe

IPAR 4.0 - Okos megoldások, hülyén megvalósítva

IPAR 4.0 Telekommunikációs és informatikai berkekben, az IPAR 4.0 eszközöket valahogy úgy definiáljuk, hogy ipari cuccok amik IP hálózaton is kommunikálnak... Természetesen ez egy durva egyszerűsítés, de ebből a szögből nézve a gyártásban betöltött szerepe nem annyira fontos, mint a hálózatban elfoglalt helye. Ezek olyan tipikusan beágyazott-rendszer alapú megoldások, melyek saját operációs rendszerrel rendelkezhetnek, és IP kommunikációra, egy már korábban lefejlesztett általában valamilyen linux alapú kernel modult használnak. Az ilyen eszközök mondhatni semmilyen tűzfal vagy végpontvédelmi megoldással nem rendelkeznek, kommunikációjuk az adatgyűjtő berendezésekkel általában nem titkosított, így potenciális veszélyforrást jelentenek a hálózatunkban. Nos eddigi tapasztalataim alapján az IoT és/vagy SMART termékek terén az, hogy minél olcsóbban, minél több szolgáltatást legyenek képesek nyújtani a végfelhasználó felé. A ipari plc-k vezérlő szoftvere - amin keresztül menedzs