junoser
junoser copied to clipboard
Hitting line width limit when parsing config into set commands
Hey!
I'm attempting to parse a configuration and hitting a limit when attempting to parse vlan members.
On some interfaces we have A LOT of VLANs being tagged. We do on an trunked interface using VLAN members.
example:
family ethernet-switching {
interface-mode trunk;
vlan {
members [ vlan666 vlan1103 vlan1105 vlan1112 vlan1116 vlan1127 vlan1128 vlan1132 vlan1134 vlan1138 vlan1139 vlan1140 vlan1147 vlan1148 vlan1150 vlan1152 vlan1153 vlan1154 vlan1157 vlan1159 vlan1160 vlan1162 vlan1164 vlan1165 vlan1166 vlan1168 vlan1169 vlan1170 vlan1171 vlan1172 vlan1173 vlan1175 vlan1176 vlan1177 vlan1188 vlan1190 vlan1192 vlan1196 vlan1197 vlan1198 vlan1200 vlan1201 vlan1202 vlan1203 vlan1204 vlan1205 vlan1206 vlan1210 vlan1211 vlan1212 vlan1216 vlan1217 vlan1218 vlan1219 vlan1226 vlan1227
vlan1228 vlan1232 vlan1233 vlan1253 vlan1261 vlan1262 vlan1263 vlan1265 vlan1272 vlan1273 vlan2140 vlan2190 ];
}
}
As you can see from the output above junos seems to drop the configuration onto a new like when configuration lines hit a certain length in characters. The members line is around 532 characters long and at that point it continues the vlan members list on new line. The example above is taken from the juniper archive feature and this seems to be something that the junos OS is doing itself.
When we run this through junoser, because the line ends in a new-line rather than semi-colon, it throws an error in this case.
/usr/local/bundle/gems/junoser-0.5.5/lib/junoser/display/set.rb:52:in `block in process': ERROR: unknown statement: members [ vlan666 vlan1103 vlan1105 vlan1112 vlan1116 vlan1127 vlan1128 vlan1132 vlan1134 vlan1138 vlan1139 vlan1140 vlan1147 vlan1148 vlan1150 vlan1152 vlan1153 vlan1154 vlan1157 vlan1159 vlan1160 vlan1162 vlan1164 vlan1165 vlan1166 vlan1168 vlan1169 vlan1170 vlan1171 vlan1172 vlan1173 vlan1175 vlan1176 vlan1177 vlan1188 vlan1190 vlan1192 vlan1196 vlan1197 vlan1198 vlan1200 vlan1201 vlan1202 vlan1203 vlan1204 vlan1205 vlan1206 vlan1210 vlan1211 vlan1212 vlan1216 vlan1217 vlan1218 vlan1219 vlan1226 vlan1227 (RuntimeError)
from /usr/local/bundle/gems/junoser-0.5.5/lib/junoser/display/set.rb:39:in `each'
from /usr/local/bundle/gems/junoser-0.5.5/lib/junoser/display/set.rb:39:in `process'
from /usr/local/bundle/gems/junoser-0.5.5/lib/junoser/display/set.rb:14:in `transform'
from /usr/local/bundle/gems/junoser-0.5.5/lib/junoser/cli.rb:26:in `display_set'
from /usr/local/bundle/gems/junoser-0.5.5/exe/junoser:46:in `<top (required)>'
from /usr/local/bundle/bin/junoser:25:in `load'
from /usr/local/bundle/bin/junoser:25:in `<main>'
If I manually edit the problematic config file and remove the new line it seems to work.
Is there any way to account for a new line potentially being within VLAN members?
Sorry for my late response. I'm looking into this.
Thanks Shintaro, for what it's worth we ended up getting around this issue using some awk commands on the config to concat large lines correctly before we parse it with Junoser. No immediate rush to resolve this as it's probably a rare occurrence.
Thank you @Jypear, I've published v0.5.6 with the fix. Hoping it works for you.
$ junoser -v
0.5.6
$ cat config
interfaces xe-0/0/0 {
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members [ vlan666 vlan1103 vlan1105 vlan1112 vlan1116 vlan1127 vlan1128 vlan1132 vlan1134 vlan1138 vlan1139 vlan1140 vlan1147 vlan1148 vlan1150 vlan1152 vlan1153 vlan1154 vlan1157 vlan1159 vlan1160 vlan1162 vlan1164 vlan1165 vlan1166 vlan1168 vlan1169 vlan1170 vlan1171 vlan1172 vlan1173 vlan1175 vlan1176 vlan1177 vlan1188 vlan1190 vlan1192 vlan1196 vlan1197 vlan1198 vlan1200 vlan1201 vlan1202 vlan1203 vlan1204 vlan1205 vlan1206 vlan1210 vlan1211 vlan1212 vlan1216 vlan1217 vlan1218 vlan1219 vlan1226 vlan1227
vlan1228 vlan1232 vlan1233 vlan1253 vlan1261 vlan1262 vlan1263 vlan1265 vlan1272 vlan1273 vlan2140 vlan2190 ];
}
}
}
}
$ junoser -c config
$
Thanks @codeout I'll look to test this asap and let you know.
@codeout Sorry for the delay. v0.5.6 confirmed to have fixed this issue for us.