g'day,<br><br>I was off the list for a while (change of email address) but just saw this now & thought i could add some clarity on the rationale now that i'm resubscribed.<br><br>by way of background, I had a thing or two to do with NX-OS and Nexus.<br>
<br><br>Ben Byer wrote:<br> > I've been picking through the
reference docs, and the useful comparison notes on the Cisco wiki,<br> > but - I
just don't understand the thinking behind the following:<br> > "When you change a route map, Cisco NX-OS hold all the changes until you
exit<br> > from the route- map configuration submode. Cisco NX-OS then sends all
the <br> > changes to the protocol clients to take effect."<br><br>It is predominantly because the code is modular, not monolithic and because we figured that if you were making changes to a series of route-maps that you would want them to be atomic either the 'before' or 'after' stage, not an indeterminite stage somewhere inbetween.<br>
<br> > ....but wait!  I have multiple protocol clients using the same route-map -
and maybe <br> > I *don't* want the change to be propagated to all of them at once
as soon as I<br> >  type "exit".  The way IOS allows you to change a route-map,
then cause it to<br> >  take effect on a per-peer basis via a soft clear, is
operationally *useful*.<br><br>You can still use soft reconfiguration inbound if you still with. its still there and NX-OS is (intentionally) no different to IOS in this regard.<br><br>Note that soft reconfiguration inbound is disabled by default, because it basically means you must keep a shadow copy of every route/prefix received from a peer just so you can iterate over them again (re)applying route policies.<br>
For some people with large numbers of peers and prefixes thats a ton of RAM, even on systems with 8GB RAM on the Supervisor.<br><br> > To make it worse, the reference docs for the 7k series say:

"If you make changes to<br> >  a route map that is used by a client, you must exit
the route-map configuration<br> > submode before the changes take effect in the
client. The route-map changes<br> > are not propagated to its clients until you
exit from the route-map configuration<br> > submode or 60 seconds expires since
entering the submode."<br> > <a href="http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/unicast/command/reference/l3_cmds_r.html#wp1542709">http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/unicast/command/reference/l3_cmds_r.html#wp1542709</a>
<br> > ...great - so now whether or not I type "exit", 60 seconds after I typed a
command<br> > it will take effect...?<br><br>Its sort of as above - we (historically) had people whinging about changing route-maps and having some prefixes leak through in the timeframe while they were making changes, so a determination was made to exhibit either the 'before' or 'after' and make the operation appear atomic.<br>
What we also saw was some people then still sat the 'switch(config-route-map)#' prompt and wondered why their policy wasn't being applied - so did the 60 second timer thing.<br><br>We made sure it was documented.<br>
Just goes to show you can't please all people.<br><br> > And this behaviour is documented only for
the 7k, not the 5k?<br><br>N5K behaves the same. Its the same NX-OS code.<br><br><br>Glen Turner wrote:<br> > Does that behaviour still occur if you say "configure session ..."? In any sane world nothing would change until the "commit".<br>
<br>Alas, 'config session' still only applies to ACLs and QoS. Intent is that it will apply to more over time, but AFAIK hasn't happened yet.<br><br><br>cheers,<br><br>lincoln.<br><br><br>