NSO considers non in sync a service that configures static routes because of a different order. The order on the configuration is not relevant (non in this specific case, nor in general) since the router behaviour is specified by the ip routing IP rule(prefix-length, metric, ...), so I would expect NSO would not considere oroute ordering.
Am I wrong? How can I avoid to generate an out-of sync for such a service?
user152@ncs-2> request l3pe internet Jpe-54:gr-9/3/0:1138 check-sync outformat cli
cli {
local-node {
data devices {
device Jpe-54 {
config {
configuration {
routing-options {
static {
- route 7.98.67.238/31 {
- next-hop [ 10.200.107.155 ];
- tag {
- metric-value 1200;
- }
- preference {
- metric-value 171;
- }
- }
+ # after route 123.75.18.160/28
+ route 7.98.67.238/31 {
+ next-hop [ 10.200.107.155 ];
+ tag {
+ metric-value 1200;
+ }
+ preference {
+ metric-value 171;
+ }
+ }
}
}
}
}
}
}
}
}
[ok][2024-09-03 17:52:26]
user152@ncs-2> request l3pe internet Jpe-54:gr-9/3/0:1138 check-sync outformat ?
Possible completions:
boolean
cli NCS CLI curly bracket format.
cli-c CLI format (Cisco style).
native The actual data in native format that would be sent to the device
xml NETCONF XML edit-config format, i.e., the edit-config that would be applied locally (at NCS) to get a config that is
equal to that of the managed device.
user152@ncs-2> request l3pe internet Jpe-54:gr-9/3/0:1138 check-sync outformat xml
result-xml {
local-node {
data <devices xmlns="http://tail-f.com/ns/ncs">
<device>
<name>Jpe-54</name>
<config>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm">
<routing-options>
<static>
<route xmlns:yang="urn:ietf:params:xml:ns:yang:1"
xmlns:junos="http://xml.juniper.net/xnm/1.1/xnm"
yang:insert="after"
yang:key="[junos:name='123.75.18.160/28']">
<name>7.98.67.238/31</name>
</route>
</static>
</routing-options>
</configuration>
</config>
</device>
</devices>
}
}
