Okay a lame joke : )
OSPFv3 supports either Authentication or Encryption for OSPFv3. OSPFv3 supports both unicast address families for ipv4 and ipv6. If you recall theses earlier posts of mine where I discuss a simple OSPFv3 configuration.
In this blog I will show you just how easy it is to craft a SPI and ipsec for IOS-XR using authentication. Here's a basic OSPFv3 configuration with no authentication.
1st you will need to define a SPI values. Here's I'm using a SPI #256 with the password defined.
trick: use the unix md5 hasher to build a string if you don't want to count out the characters. This can save a lot of time and you can easily define a value if you define not enough character the command will failed when you try to commit.
Now the show command will net the details for the interface and you can see the SPI# and that authentication is enabled.
A tip; the ospfv3 protocol requires a defined ipv4 "router-id" value. So that means it will select a ipv4 address and if a loopback access, it will use that address. But what if you have a ipv6 only network, and no ipv4 interface? You can "define" any ipv4 address regardless if it's a real in-use address on the router.
Now by using tshark and by displaying a packet.capture, here's how your ospf header looks like now. Notice the value are not encrypted because we have authentication-header enabled.
And here's a ospf header with no authentication-header attached;
note: the use of authentication header #51 will increase the packet size by 24bytes.
If you want to use SHA1, the cfg is similar just the hash needs to be 40 characters. You can use a sha1 generator if it helps with crafting the hash value.
Just like with ipv4 and OSPF you will need to ensure the following;
- OSPF timer match hello/dead
- router-id are set and unique for all ospfv3-speakers
- SPI# number match ( for Authentication ipsec )
- AH authentication type matches ( all devices need to be the same algo md5 or sha1)
- AH hash ( aka password value is the same across all OSPFv3 speakers )
- and finally the same OSPF area type ( stub , backbone, NSSA, etc.......)
keep in mind if you use encryption you can't see these issues since the packets are encrypted. With IPSEC-AH you can easily diagnose most OSPFv3 issues with ease & without access to the router/firewall.
With in cisco IOS/IOS-XR all OSPFv3 log messages are listed with the ipv4 router-id. So IMHO if you don't run ipv4 natively you want to ensure your router-id matches the ipv6 address to same degree
ipv6 == 2001:db8:199::1 ipv4 == x.x.x.1
ipv6 == 2001:db8:199::2 ipv4 == x.x.x.2
ipv6 == 2001:db8:199::3 ipv4 == x.x.x.3
It's hard enough trying to match devices to what router went down/up by the log messages when you have a ipv4 address that's not carried or known readily .
A sample show neighborship command ASR9001;
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
=( @ @ )=