First we can start with changing it on R4:
R4(config)#router ospf 1
R4(config-router)#router-id 44.44.44.44
Reload or use “clear ip ospf process” command, for this to take effect
So we have to clear the OSPF process in order for this to take effect.
R4(config-router)#^Z
R4#clear ip ospf process
Reset ALL OSPF processes? [no]: y
R4#
Ok, we should now have a Router-ID of 44.44.44.44.
R4#sh ip ospf | inc ID
Routing Process “ospf 1” with ID 44.44.44.44
Good. Time to recheck connectivity.
R4#ping 3.3.3.3 so lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R4#
Good, we can still ping R3 from R4. Now, let’s do the same thing on J2.
But first we will turn on some trace options (debugs) on the Juniper router to see what happens.
First we will tell it what log file to use/create, for this example ospf-log is my choice
[edit]
jfry@J1# set protocols ospf traceoptions file ospf-log
And then we tell it what to log, here restart-signaling.
[edit]
jfry@J1# set protocols ospf traceoptions flag restart-signaling
And what we will do is now show the log file and have it refresh for us every 30 seconds
jfry@J1> show log ospf-log | refresh 30
—(refreshed at 2012-08-13 18:41:29 UTC)—
Aug 13 18:40:10 J1 clear-log[1513]: logfile cleared
Aug 13 18:40:56 trace_on: Tracing to “/var/log/ospf-log” started
—(*more 100%)—
Ok, time to change the router-id on J2 to 22.22.22.22
[edit]
jfry@J2# set routing-options router-id 22.22.22.22
[edit]
jfry@J2# commit and-quit
commit complete
Ok, that is it. No need to reset the process as Junos will do that.
Now, let’s see what happened on J1:
Aug 13 18:57:18.901347 RPD_OSPF_NBRDOWN: OSPF neighbor 192.168.12.2 (realm ospf-v2 ge-0/0/0.0 area 0.0.0.0) state changed from Full to Init due to 1WayRcvd (event reason: neighbor is in one-way mode)
Aug 13 18:57:18.959459 RPD_OSPF_NBRUP: OSPF neighbor 192.168.12.2 (realm ospf-v2 ge-0/0/0.0 area 0.0.0.0) state changed from Init to ExStart due to 2WayRcvd (event reason: neighbor detected this router)
Aug 13 18:57:18.976382 OSPF restart signaling: Received DBD with LR bit on from nbr ip=192.168.12.2 id=22.22.22.22. Save its oob-resync capability 1
Aug 13 18:57:22.878433 RPD_OSPF_NBRUP: OSPF neighbor 192.168.12.2 (realm ospf-v2 ge-0/0/0.0 area 0.0.0.0) state changed from Exchange to Full due to ExchangeDone (event reason: DBD exchange of slave completed)
—(*more 100%)—[abort]
Yup, we can see we had a neighbor state change.
We can confirm the change by looking at the OSPF neighbors detail information on the J1:
jfry@J1> show ospf neighbor detail
Address Interface State ID Pri Dead
192.168.13.3 fe-0/0/2.0 Full 3.3.3.3 128 38
Area 0.0.0.0, opt 0x52, DR 192.168.13.3, BDR 192.168.13.1
Up 05:10:27, adjacent 05:09:47
192.168.14.4 fe-0/0/7.0 Full 44.44.44.44 1 31
Area 0.0.0.0, opt 0x52, DR 192.168.14.1, BDR 192.168.14.4
Up 00:13:29, adjacent 00:13:29
192.168.12.2 ge-0/0/0.0 Full 22.22.22.22 128 34
Area 0.0.0.0, opt 0x52, DR 192.168.12.1, BDR 192.168.12.2
Up 00:05:26, adjacent 00:05:26
jfry@J1>
As you can see, the neighbor has only been up for about 5 minutes compared to R4 at 13 minutes (that is when we reset the router-id), and J3 is up for over 5 hours.
Ok, time to check the neighbors again ( I stepped away for work, so timers will be different) and we can change J3 to 33.33.33.33.
jfry@J1> show ospf neighbor detail
Address Interface State ID Pri Dead
192.168.13.3 fe-0/0/2.0 Full 3.3.3.3 128 38
Area 0.0.0.0, opt 0x52, DR 192.168.13.3, BDR 192.168.13.1
Up 07:06:20, adjacent 07:05:40
192.168.14.4 fe-0/0/7.0 Full 44.44.44.44 1 39
Area 0.0.0.0, opt 0x52, DR 192.168.14.1, BDR 192.168.14.4
Up 02:09:22, adjacent 02:09:22
192.168.12.2 ge-0/0/0.0 Full 22.22.22.22 128 36
Area 0.0.0.0, opt 0x52, DR 192.168.12.1, BDR 192.168.12.2
Up 02:01:19, adjacent 02:01:19
Ok, we have our uptime times now. Time to clear the log on J1
jfry@J1> clear log ospf-log
Instead of monitoring the log, we will just do a show after we make our change.
We will also setup a repetitive ping from R4 to J3 loopback to see what happens to connectivity.
R4#ping 3.3.3.3 so l0 repeat 1000000
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (continues)
Ok, time to make the change!
[edit]
jfry@J3# set routing-options router-id 33.33.33.33
[edit]
jfry@J3# commit and-quit
And back to R4 – as you can see, we do lose connectivity to J3 loopback during this change – so be aware that this change will impact the network.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!.UUUUUUUUUUUU…….!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
And let’s look at the log on J1
jfry@J1> show log ospf-log
Aug 13 20:58:49 J1 clear-log[1873]: logfile cleared
Aug 13 21:01:17.947876 RPD_OSPF_NBRDOWN: OSPF neighbor 192.168.13.3 (realm ospf-v2 fe-0/0/2.0 area 0.0.0.0) state changed from Full to Init due to 1WayRcvd (event reason: neighbor is in one-way mode)
Aug 13 21:01:17.992586 RPD_OSPF_NBRUP: OSPF neighbor 192.168.13.3 (realm ospf-v2 fe-0/0/2.0 area 0.0.0.0) state changed from Init to ExStart due to 2WayRcvd (event reason: neighbor detected this router)
Aug 13 21:01:18.016898 OSPF restart signaling: Received DBD with LR bit on from nbr ip=192.168.13.3 id=33.33.33.33. Save its oob-resync capability 1
Aug 13 21:01:18.107276 RPD_OSPF_NBRUP: OSPF neighbor 192.168.13.3 (realm ospf-v2 fe-0/0/2.0 area 0.0.0.0) state changed from Loading to Full due to LoadDone (event reason: OSPF loading completed)
And check our neighbor states:
jfry@J1> show ospf neighbor detail
Address Interface State ID Pri Dead
192.168.13.3 fe-0/0/2.0 Full 33.33.33.33 128 35
Area 0.0.0.0, opt 0x52, DR 192.168.13.1, BDR 192.168.13.3
Up 00:04:33, adjacent 00:04:33
192.168.14.4 fe-0/0/7.0 Full 44.44.44.44 1 35
Area 0.0.0.0, opt 0x52, DR 192.168.14.1, BDR 192.168.14.4
Up 02:16:35, adjacent 02:16:35
192.168.12.2 ge-0/0/0.0 Full 22.22.22.22 128 36
Area 0.0.0.0, opt 0x52, DR 192.168.12.1, BDR 192.168.12.2
Up 02:08:32, adjacent 02:08:32
Now to remove the traceoptions, you just need to delete the section!
[edit]
jfry@J1# delete protocols ospf traceoptions
[edit]
jfry@J1# commit and-quit
And we can then delete the log
jfry@J1> clear log ospf-log
…and that is Router-ID and traceoptions!
I haven’t played with Junos a lot (it’s on my to-do list) other than the SRX100, so my views are still developing. Some things I find positive, some negative. Just in your example here, however, the positive I see right away is not the obvious one–less commands since you don’t have to reset manually–but the logs. I’ve gotten so used to the Cisco logs that I know what’s going on, but just the same I like that the Juniper logs seem more intuitive. They actually tell you why something happened (Hey! We found another router! Oh boy you betcha!) in a way that makes the logs easier to decode.
I haven’t played with Junos a lot (it’s on my to-do list) other than the SRX100, so my views are still developing. Some things I find positive, some negative. Just in your example here, however, the positive I see right away is not the obvious one–less commands since you don’t have to reset manually–but the logs. I’ve gotten so used to the Cisco logs that I know what’s going on, but just the same I like that the Juniper logs seem more intuitive. They actually tell you why something happened (Hey! We found another router! Oh boy you betcha!) in a way that makes the logs easier to decode.
Pingback: Junos – OSPF Authentication | Fryguy's Blog