Related to T5398, any statically configured route to a container network (pod-<network name>) will fail to persist after reboot and present the user with a Configuration Error on System Boot.
Missing configuration after reboot:
jvoss@test-R1# load
jvoss@test-R1# compare
[vrf name TEST protocols]
+ static {
+ route 192.0.2.0/25 {
+ interface pod-TEST {
+ vrf "default"
+ }
+ }
+ route 192.0.2.128/25 {
+ interface eth1 {
+ vrf "default"
+ }
+ }
+ }This is due to the configuration priority of containers as compared to protocol static:
# /opt/vyatta/sbin/priority.pl [...] 480 protocols/static [...] 1280 container
When the static route is validated on startup, the container network does not exist yet, fails validation, and the entire static route stanza is rejected.
Updating the priority of containers from 1280 to 450 corrects this issue. 450 is just after common system configuration and before protocol/static:
400 protocols/pim 400 system/config-management 400 system/domain-search 400 system/login 400 system/name-server 400 system/static-host-mapping 400 system/syslog 450 container <--- updated placement 460 interfaces/geneve 460 interfaces/openvpn 460 interfaces/sstpc 460 interfaces/vxlan 461 interfaces/macsec 480 protocols/static 481 vrf/name/node.tag/protocols/static
After reboot the configuration persists and the routes are installed correctly:
jvoss@test-R1:~$ show ip route vrf TEST static
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF DN42:
S>* 192.0.2.0/25 [1/0] is directly connected, pod-TEST (vrf default), weight 1, 00:14:53
S 192.0.2.128/25 [1/0] is directly connected, eth1 (vrf default), weight 1, 00:15:04