Note that the default ospf network type for the loopback interface is "loopback", which causes this behavior. In most cases, you do not need more than a host addresz on the loopback interface. The fact that a /32 is used on a loopback interface is only common sense. But it does not seem to agree with Jeff Doyle's book, bottom of page 524.Ĭould anyone comment on these observations? If I think it through, I guess I am not surprised you don't want the RIDs changing too often. Even if I clear ip ospf 30 process, the adjacencies get reset, but it still keeps the old RID. If the RID is based on a loopback, say lo96 with address 192.168.96.1, then I destroy the lo96 interface and create a different one with a different address, the OSPF process does not even blink - it carries on being 192.168.96.1. Without the ip ospf network point-to-point in place, the route shows up on the adjacent router with no OSPF details: Route metric is 65, traffic share count is 1 Known via "ospf 20", distance 110, metric 65, type intra area With the ip ospf network point-to-point, the route shows up on an adjacent router, complete with its OSPF details: I don't understand why the choice of that command the words command does not seem to reflect what it actually does.Īlso, I am puzzled by the way show ip route n.n.n.n behaves on an adjacent router for such a loopback. To change this behavior, the command is ip ospf network point-to-point, then it gets advertised as /24.
I can sort of see the logic to this: you might want to give all your routers host addresses in the same subnet.
If you include a loopback interface in an OSPF process, it gets advertised as a stub host. Can someone explain to me the logic behind the way OSPF handles loopback interfaces? BTW, this is using 12.2(17a).
0 kommentar(er)
