Ugrás a fő tartalomra

CCIE SP v5.x Lerning journey #xxxxx4 What is the newness in OSPFv3?

 OSPF again

 Why OSPF is such important? Why do I care for this topic so much time?
 
Interesting questions, I do not really know. When I start to process a topic for my exam preparation I do not know how much time I have to learn it. But when I learn it, I feel the importance of the subject area.
 

 
If you would like to read more detailed information about OSPF I suggest that link:
 
So let me explain to you that what are the differences between OSPFv2 and OSPFv3?
In a high level view the two protocols are only different in the Internet Protocol version support. OSPFv2 is only support IPv4. OSPFv3 support both AFs (address family), but If you wanna know some detail about the other differences you need research better this topic.

1. Network types

In OSPFv2 there is 5 network type which is the same in OSPFv3
  • broadcast
  • non broadcast
  • point-to-point
  • point-to-multipoint
  • point-to-multipoint non broadcast
 Ok these types works same as ospfv2 the hello and dead timers are also the same and the DR/BR election rules too. In this section the OSPFv3 has a new network type called MANET (Mobile ad-hoc NETworks). Maybe later I am going to care about it. Actually it is not important (I think).

network type hello dead DR/BDR election
broadcast 10 40 yes
non broadcast 30 120 yes
point-to-point 10 40 no
point-to-multipoint 30 120 no
point-to-multipoint non broadcast 30 120 no














2. What about the area types?

   









Yes, the areas are the same 




  • backbone
  • regular
  •  stub
  • totally stub
  • not so stubby
  • totally nssa

At this point, this post look like an unnecessarily character mass about OSPFv3, but...

3. Differences

The 1st main difference between the two protocol is the transport: 

OSPFv3 use IPv6 to make adjacency metween the routers in: ff02::5 (ff02::6 DR/BDR) ipv6 multicast address, in case of non-broadcast scenarios you need to configure the link-local ipv6 address as with the neighbor statement.

The 2nd main difference is the LSAs:

Is there any new LSA type?

Yes in case of OSPFv3 the following LSA types exist:

Type 

0x0008 Link-local summary
0x2009 Intra-Area Prefix


Here is a table from the differences of OSPFv2 and v3 and the RFCs:

OSPFv3 LSA Type  OSPFv3 LSA Name (RFC 5340)  OSPFv3 TLVs (RFC 8362) OSPFv2  LSA Type  OSPFv2 LSA Name differences
0x2001 Router Router-Link TLV (RFC2328) 1 Router contain only adjacency topology information
0x2002 Network Attached-Routers TLV (RFC2328) 2 Network contain only adjacency topology information
0x2003 Inter-Area Prefix Inter-Area-Prefix TLV (RFC2328) 3 Network Summary
0x2004 Inter-Area Router Inter-Area-Router TLV (RFC2328) 4 ASBR Summary
0x4005 AS-External External-Prefix TLV (RFC2328) 5 AS-External
0x2006 Group Membership Intra-Area-Prefix TLV (RFC2328) 6 Group Membership unused / deprecated
0x2007 Type-7 LSA IPv6 Link-Local Address TLV (RFC2328) 7 NSSA External
0x0008 Link-local summary IPv4 Link-Local Address TLV

used for advertise link-local address
0x2009 Intra-Area Prefix
(RFC5250) opaque 9
used for advertise prefix



(RFC5250) opaque 10




(RFC5250) opaque 11

If you do not understand the basics of IPv6, please google it. 

Why so IPv6 is important to SPs? Why an other version of OSPF may configured in the a SP network?
In short:
because it need for the capability of dual-stack.
In a longer answer:
The public IPv4 is sold out. (Mostly, but there some institute who find /23 prefixes which are not used yet), so the SPs has to be ready for IPv6 routing on BGP and IGP too. (It is really a long story for this soo leave this question in open).

OSPFv2 and OSPFv3 are not compatible with each other, because:

  • They use different IP version for transport
  • The headers are different
  • LSAs and LSDBs, also LSUs are contain different information

What about the IOS-XE and IOS-XR configurations?

The main difference between the two platform is that IOS-XE support both IPv4 and IPv6 AFs (address family) opposite the in the IOS-XR only the IPv6 is supported.

In a case of IOS-XE the configuration method can be the following:

!!!!!!!ipv6 unicast-routing !!!!!!!! #Yes you need configure that router support the IPv6 routing capabilities. 
In global configuration mode:
ipv6 router ospf $process_id
 router-id $Lo0_ip_address
!
interface Gi$x
 ipv6 enable
 ipv6 ospf 1 area $area_id
!

or  if you would like to use the IPv4 AFs

router ospfv3 $process_id
 router-id $Lo0_ip_address
 address-family ipv4 unicast
 address-family ipv6 unicast

interface Gi$x
 ospfv3 $process_id area $area_id ipv4
 ospfv3 $process_id area $area_id ipv6 

 On IOS-XR only the router statement is available:

router ospfv3
 router-id $router_id
!
 area 0
  !
   interface Gi0/0/0/$x
  !
!

Do not forget in IOS-XR to commit your configuration.

I think I finished with the OSPF topic... Oh wait what about the authentication? Oh J.sus f.ck cr.st!
Ok, let us talk about that in the next post!


See yo!


É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