A quick story for everyone today. A year or two ago a unit was coming through here on rotation. One of their CPNs was setup very close to the Brigade Main so the Net Tech made the decision to give himself some redundancy in his network and ran a piece of fiber between the two nodes. In this particular case, he ran the connection between the two NIPR routers on a new VLAN. It was a quick down and dirty connection. I have included a copy of the configuration below.
! interface GigabitEthernet0/0.20 description Vlan to CPN ##### encapsulation dot1Q 30 ip address 192.168.5.1 255.255.255.252 no ip directed-broadcast no ip mask-reply no ip proxy-arp no shutdown !
Life was good and for several days, SIPR was flying for that CPN. Then one day the unit had to stow their STTs for what turned out to be nearly 48 hours due to severe winds. While the Net Tech planned to lose a good chunk of his network when the dishes went down, he fully expected for this particular link to stay up because of the fiber.
Shortly after the dishes stowed though for some reason SIPR between the JNN and CPN dropped. We jumped on NIPR and ensured that the connection was still up (it was) but despite our best efforts, SIPR would not come up. So, what was the problem?
It took me (and everyone else) a while to notice it but we were missing one critical command “ip pim sparse-dense-mode”. We are all probably familiar with that command but do we actually know what it does? I will tell you the truth, I am by no means an expert when it comes to the area of multicasts but the short answer is that this command allows multicast traffic to go across this particular link.
I think everyone understands why multicast traffic is important on SIPR but what’s so important about it on NIPR and what does this have to do with why SIPR stopped working when the STTs were stowed? If you happen to remember, your TACLANE operates off of two keys, a firefly and a PPK. While the firefly key is responsible for actually encrypting the traffic coming out of the TACLANE, the PPK allows for the various TACLANES on the network to discover each other through the use of a periodic multicast that advertises their presence. If the multicast doesn’t get through (because say for example the link doesn’t allow them) then eventually the TACLANES forget about each other and the link drops.
So back to the original problem, the link had been working fine when the STT was up because the STT had been configured correctly to allow multicast traffic to pass through. This allowed the JNN to learn about the CPN’s TACLANE but the encrypted traffic itself which is just normal IP traffic would travel across the fiber. When the STT came down, the multicasts got blocked from going across the fiber and the TACLANES eventually forgot about each other.
Why can’t a photonically secure optical fiber that can not be physically tapped be used either in place of or in concert with TACLANES!?
Nothing stopping your from using them with a TACLANE but a TACLANE will always be required to provide the encryption.
fiber isn’t secure from taps…haven’t been for 20 years.
Which side of the TL needs multicast enabled, CT or PT or both? Was this example Sipr over Nipr or black core? Just trying to get the full picture and understanding.