[j-nsp] OSPFv3 interop/tuning recommendations?

[Jonathan Lassoff]

On Fri, Jun 10, 2011 at 8:07 AM, Justin M. Streiner
<streiner at cluebyfour.org> wrote:
> All:
>
> I have a fairly extensive IPv6 test bed set up in my lab, using OSPFv3 as my
> IGP, and one thing I noticed is that the OSPFv3 adjacencies on links between
> Cisco (6509-Es, Sup720/3BXLs, 12.2SXH code) and Juniper (M7is, JUNOS
> 10.3R1.9) devices seem to take about 3x longer to come up, than between two
> Cisco devices.  OSPFv3 timers are at their default settings on all devices.
>  The topology is point-to-point links, and all of the relevant devices are
> in the same area.  OSPFv3 adjacencies between two Juniper devices also seem
> to come up pretty quickly.
>
> It's been a while since I've had to look at IGP interoperability between the
> vendors, so I still need to re-familiarize myself with timer differences
> between vendors and things like that, to understand why the Cisco<->Juniper
> adjacencies come up more slowly.
>
> It's not a major headache at this point (~30 secs to bring up a
> Cisco<->Juniper OSPFv3 adjacency vs ~10 secs to bring up a Cisco<->Cisco
> adjacency, and ~2 secs to bring up a Juniper<->Juniper adjacency), but
> something I'd like to understand fully and address before I start rolling
> things out in production down the road.
>
> Does anyone have any recommendations for tuning OSPFv3 in multi-vendor
> setups like this?

Perhaps look at the neighbor state through the 10 and 30 second
windows and see if you can see what state is taking the most amount of
time.
Are you exchanging a lot of routes? Maybe the back and forth of many
DBD packets are faster to be acknowledged on one host, but not the
other?

If you have the hardware, or are willing to do SVIs on the Cisco, try
and get a tap of the OSPF traffic and analyze protocol timings in
tshark or wireshark.

My two cents.

--j