Two questions. In a previous post, someone stated the following:
"OnePK is not [yet] an API to do configuration deployments. Something like changing the hostname is a configuration change. All of onePK changes are designed to be transient. That is, they only last as long as the application is connected to the network element. There are some exceptions (i.e., ACLs can be made persistent by setting their lifetime), but in general, nothing from onePK will be placed in the running configuration."
Can someone comment further on this? I've been able to do basic things such as configuring interface MTU and have it be persistent just fine. This is also the first I've heard of onePK not being an API for config deployments. This seems interesting.
In trying to set the VRF on an interface, I am getting an error. Can you clarify this is a onePK error a user error?
#sets MTU fine on this interface, i
#trying to set VRF
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/eem-5/shr_scratch/build/nightly/sdk_1.1-nightly/latest/infra/onep/presentation/python/pkg_rel/onep/interfaces/NetworkInterface.py", line 955, in set_vrf_forwarding
NameError: global name 'Vrf' is not defined
OnePK is not a configuration protocol or API. Most changes made by onePK will require the app to remain connected to the Network Element to have the changes remain in effect since they are not written to the running configuration. One notable exception is the ACL API. You can choose to have ACLs remain in the running config (though this is not the default). Additionally, the VTY service set provides direct access to the CLI, and thus changes made through it will show up in the running config.
Where have you heard that onePK was a configuration API?
The MTU value persisting in the running config is a bug. This should be transient.
The VRF API is not yet fully complete. It looks like 1.2 will have this complete API.
Not viewing onePK as a config protocol or API is pretty important. I’ve never heard this distinction. Whenever I’ve asked about automated provisioning, it’s been said “wait for onePK.”
If onePK isn’t a configuration API, I have to ask, what is Cisco going to offer in this space?
When is 1.2 due out?
Jason Edelman | Core Principal Architect-SDN
Presidio | www.presidio.com<http://www.presidio.com>
111 Wood Avenue South 1st Floor, Iselin, NJ 08830
D: 212.324.4367 | C: 201.747.4227 | firstname.lastname@example.org<mailto:email@example.com>
OnePK plays well when it comes to specialized traffic steering and event-driven programming. It was not designed to be an all-purpose configuration protocol or API. We are looking at using NETCONF with YANG data models for that.
OnePK API 1.2.0 is due out later this month.
Okay, thank you very much for the clarification. While I can't say that sits well with me, why even use onePK for anything more than the listener APIs it offers in the future (to get the event driven benefits)? Netconf/yang is a standard and more portable across a wider variety of network devices - this may be why I'm hearing hosted onePK apps off-box is going away.
OnePK's DPSS offers a very powerful way to inspect, manipulate and inject traffic traversing the network. This gives you some very flexible traffic steering capabilities as well as the ability to easily transition legacy protocols to IP. On top of that, if you look at the on-box model, you get very feature-like capabilities by being able to install transient policies.
Maybe, but I heard APIC Enterprise will only support CLI/SNMP/SSH for legacy devices initially. As long as real time state information isn't needed, that will work.
Yes, APIC-EM will use CLI southbound initially. This means there will be persistent state in that the config is being manipulated. The initial apps for APIC-EM will be ACL and QoS-based. But it has a northbound REST API, so you could bring your own app logic to the party.
Many of the interface operations in onePK are persistent. Things like setting the MTU, interface state, etc. will be reflected in the running configuration. I have a request in to clarify the documentation along these lines.
What would be really nice is to have some form of option to make changes persistent, particularly RIB changes. It should be up to the application developer to make the changes persistent, even after the application disconnects, or to have everything go back to normal forwarding (fall back to the routing protocols, etc) once the application disconnects.
Kind of how PfR works...while its up the BRs make forwarding decisions based on what the MC pushes down to them. However, if the session between the BR and MC goes down (the OnePK application disconnects) then forwarding falls back to whatever machanisms were in place before PfR made its changes.
Yes, ACLs have this already. You can set the lifetime of an ACL to make it persistent. RIB entries do not yet. However, configuration is something the onePK team knows people want.
In the meantime, the VTY Service Set can be used if you must configure something statically on the device.
Programmatically added RIB entries (using onePK) do not show up in nvgen output (sh run) of the router and cannot be deleted via CLI.
These routes show up in RIB (sh ip route) as application route and designed to be transient.
If we need persistent RIB entries, I think this is more of a request to program static routes which are created today via CLI.
Can you clarify if the ask here is to make the programmed route show up in the router as static route which can be deleted by application or CLI?