This topic is to discuss the following lesson:
Hi Rene,
“Links, not networks” what do mean at this point, can you please explain in detail ? and can you give me an example about multiple instance ID in the same link ?
Hello Hussein
This is essentially a change in semantics. In OSPFv2 we speak about networks. The destination network, the networks that are advertised. A network is expressed as, for example, 10.56.3.0/24. This is a destination or advertise network as far as OSPFv2 is concerned.
IN OSPFv3, the term that is used is link. This means that 2001:AB::0/64 found in the routing table for example is called a link in the context of OSPFv3.
The command to implement OSPFv3 on an interface is the following:
ipv6 ospf process-id area area-id [instance instance-id]
You can input this command several times with a different instance-id in each case and have the same interface (and subsequently its link) participate in multiple instances of OSPFv3.
I hope this has been helpful!
Laz
1 Like
Thanks Laz
That was very helpful indeed.
1 Like
Hi all,
The flooding scope 0x2 says in the lesson that “is used for LSAs that are flooded throughout a single area”. LSA Type 3 and 4 are flooded throughout all ospf areas like the LSA Type5. Shouldn’t they also have the flooding scope 0x4?
Thanks in advance.
Hello Marios
Actually, if you take a closer look at Type 3 and Type 4 LSAs, you will find that they are not flooded throughout the whole AS scope. Looking at the related lesson about OSPFv2 LSAs, you can see that both are generated by an ABR that receives a Type 1 LSA. They are flooded to the rest of the network, but not in the OSPF area from which the Type 1 LSA is received.
The only LSA that truly exists throughout the whole AS in all OSPF areas is a Type 5 LSA, and it is the only one that begins with 0x4.
I hope this has been helpful!
Laz
1 Like
Hi,
Regarding the statement:
By separating the SPF tree and prefixes, OSPFv3 is more efficient. When the link-local address on an interface changes, the router only has to flood an updated link LSA and intra-area-prefix LSA. Since there are no changes to the topology, we don’t have to flood type 1 and 2 LSA(s). Other routers won’t have to run SPF in this case.
Is it also correct to say that is more efficient because prefix information is not being repeated, as Type-1 and Type-2 LSAs can contain the same network information. e.g. if router 1 and router 2 are connected network. Both their Type-1 LSAs contain the same prefixes for the same link.
Thanks
Sam
Hello Samir
Yes, what you say makes sense because you are not duplicating information that has already been sent.
Laz
1 Like
Hi dear,
I have a question? How can loops occur in OSPF? and how to differentiate L2 loops and L3 loops?
Hello Zahid
Concerning loops in OSPF, take a look at this post:
Concerning L2 and L3 loops, a layer 2 loop also known as a switching loop, or a bridging loop, is one where there is more than one layer 2 paths between two endpoints. A layer 2 loop will take place when
- there are multiple connections between two network switches on the same VLAN
- two ports on the same switch on the same VLAN are directly connected
- three or more switches are connected in a physical loop using ports on the same VLAN
Unlike Layer 3 loops, which employ a time to live (TTL) function, switching loop packets will circulate the network until they are dropped, e.g. due to resource exhaustion.
Layer 2 loops are dealt with using features such as STP, Etherchannel, or the creation of VLANs within the topology
A layer 3 loop also known as a routing loop takes place when routing is configured in such a way to send an IP packet continuously around the same path. This differs from a switching loop in that the loop is created due to routing decisions. This means that a looped IP packet will be routed from one subnet to another (or from one VLAN to another) resulting in a continuously looped packet.
This is primarily due to misconfiguration or a routing algorithm error. Unlike Layer 2 loops, IP packets have a TTL value that is decremented every hop, and when it reaches zero, it is dropped. Layer 3 loops are mitigated against using TTL as well as using correct routing configurations.
I hope this has been helpful!
Laz
1 Like
Hi
In ospfv3 is possible to configure different instances in a single interface.
<64-95> for ipv4
<0-31> for ipv6
Where these range come from?
Hello Giovanni
I’m not sure what configuration parameters you are referring to. HOwever, I went into the lab and attempted to take a look at the process IDs that I was allowed to add for both IPv4 and IPv6 OSPF instances.
For IPv4:
R1(config)#inter gig 0/0
R1(config-if)#ip ospf ?
<1-65535> Process ID
adjacency Adjacency staggering
authentication Enable authentication
Similarly for IPv6:
R1(config-if)#ipv6 ospf ?
<1-65535> Process ID
adjacency Adjacency staggering
authentication Enable authentication
I was able to create two instances, one with a process ID of 100 for IPv6 and one with a process ID of 99 for IPv4 on the interface itself.
Under what configurations do you get these ranges of values for each protocol version? Let us know so that we can help you further.
I hope this has been helpful!
Laz
Hi
I’m referring to an ospfv3 instances on a single interface.
Here an example.
R1-Hub(config)#interface lo0
R1-Hub(config-if)#ipv6 enable
R1-Hub(config-if)#ospfv3 1 ipv6 are
R1-Hub(config-if)#ospfv3 1 ipv6 area 0 instance ?
<0-31> Instance ID
R1-Hub(config-if)#ospfv3 1 ipv4 area 0 instance ?
<64-95> Instance ID
R1-Hub(config-if)#ospfv3 1 ipv4 area 0 instance 1
^
% Invalid input detected at '^' marker.
Also, can you tell me when it is useful to configure more than one instance with the same interface and the same area?
R1-Hub(config-if)#ospfv3 1 ipv4 area 0 instance 65
R1-Hub(config-if)#ospfv3 1 ipv4 area 0 instance 66
R1-Hub(config-if)#ospfv3 1 ipv4 area 0 instance 67
R1-Hub(config-if)#
Hello Giovanni
Ah, I see, thanks for the clarification. One of the advancements of OSPFv3 over OSPFv2 is the use of the instance ID. This instance ID is an 8 bit field within the OSPFv3 header.
The original intent for the instance ID was to support multiple instances of OSPFv3 to run on the same interface. In this way, you can manipulate which routers on a particular segment are allowed to form adjacencies. You could use an instance number of 0 through 255 to distinguish between the different OSPFv3 instances.
However, within RFC 5838, the instance ID was re-purposed to be used to support address families (AFs) with OSPFv3. The default instance of 0 is used if no other instance is defined. However, specific ranges of the instance ID map to specific AFs. According to the RFC, these ranges are:
Instance ID # 0 - # 31 IPv6 unicast AF
Instance ID # 32 - # 63 IPv6 multicast AF
Instance ID # 64 - # 95 IPv4 unicast AF
Instance ID # 96 - # 127 IPv4 multicast AF
Instance ID # 128 - # 255 Unassigned
As you can see, 0-31 matches with the available values for the command using IPv6 unicast, while the same is true for IPv4 unicast. Note here that OSPFv3 runs on top of IPv6 and uses IPv6 link-local addresses to form OSPFv3 adjacencies. However, OSPFv3, using these instance IDs can now advertise IPv4 routes too. Note also that Cisco routers do not support multicast OSPF, so you don’t see those instance ID values at all in any of the Cisco configuration options.
Using instances within the same process simply allows you to create a more hierarchical routing environment. Within the same segment, you can choose which routers create adjacencies and which do not. You can essentially create a more granularly configurable routing protocol. The truth is that such configurations are highly specialized and generally rare. Because of this, the instance ID was leveraged for use with multiple AFs.
I hope this has been helpful!
Laz
1 Like