So yes - I know I’ve done this to myself to some extent by running a “testing” OS. But hear me out… I’m cloning these boxes in vmware and configuring with ansible. So they are very consistent. FRR is 5.0.1. On one configuration - FRR starts as expected. On another box - FRR will not start automatically. There’s nothing in logs - it doesn’t even seem like it tries. But if I log in and manually “sudo systemctl restart frr” it comes right up. I don’t claim to be a systemd expert - but I did play around a bit in the unit file trying to add an ExecStartPre with a sleep - no dice. I also thought it might similar to: https://github.com/FRRouting/frr/issues/1340 However, I see that watchfrr gets ran anyway (I don’t have this in the daemons file). That’s fine, but it doesn’t jive with the issue 1340 above. So I don’t think that’s my issue at play here. I can tell you the main difference in the two boxes (working vs. not) is the frr config itself (daemons are the same) and IP addresses/interfaces. On the working box I have about 30 lines of frr.conf. I have maybe ~10 total ips, split between ipv4/6. frr.conf is ospf and ospfv6. On the boxes where it won’t start at boot - I have about 60 lines of FRR conf. I have about 20 total ips, split between ip4/6. About 20 BGP peers (again split between ipv4/ipv6 - so 10 each). Anyone have any idea what I can look at next ? I can put some ansible in to log back into the problem boxes and manually start frr - but that’s a hacky and cheap method. I’d rather understand what’s going on and fix it properly. Thanks. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."