Just like any other routing protocol that we redistribute into OSPF domain. The reason is that these two addresses is not actually included int the OSPF process yet we only redistribute it into OSPF process. If we try to see whether these interfaces are in the OSPF process, that’s just not possible. The second example to make these addresses available throughout the OSPF domain is to redistribute these addresses into OSPF process. OSPF network type loopback will be advertised as stub (/32), and Rack1R5(config-router)#do sh ip route | i _9. We can actually make 99.99.99.99/24 advertised as /24 by changing the OSPF network type as belowĪlso, from the above result, we can see that the area type is Inter Area, which mean it is advertised as OSPF Inter Area Route metric is 67, traffic share count is 1 Known via "ospf 1", distance 110, metric 67, type inter area Rack1R5(config-router)#do sh ip route 9.9.9.9 More interestingly, as we know that those addresses are advertised as stub, therefore we should see those addresses were advertised as /32 subnet. Loopback interface is treated as a stub Host Process ID 1, Router ID 150.1.9.9, Network Type LOOPBACK, Cost: 1Įnabled by interface config, including secondary ip addresses Interestingly, we’re seeing a network type as LOOPBACK and it is treated as a stub host. Or you can use the good-old network command
The first one is to include this to the OSPF process as below
There are two ways to make these addresses available throughout the OSPF domain. What is so special about a loopback interface in OSPF? For example that we create a loopback9 – 9.9.9.9/32 and lo99 – 99.99.99.99/24 and make these addresses available throughout the OSPF domain.
0 kommentar(er)
