We have been slowly implementing our PNP solution into our environment and now that we have a few deployments in production, I started to notice how chatty the switches that I have provisioned with PNP are after provisioning. I have failed broadcast tftp attempts that just fill up logs and make it really difficult to actually see what the log is saying on the switch. Most of the time, I end up going and pulling the historical logs from our syslog server because these messages just exceed the logging buffer.
Jan 2 2017 07:39:37.830 EST: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/network-confg) failed (TEST-3650-SW-STACK-2)
Jan 2 2017 07:40:15.832 EST: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/cisconet.cfg) failed (TEST-3650-SW-STACK-2)
Jan 2 2017 07:40:51.770 EST: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/test-3650-sw-stack-confg) failed (TEST-3650-SW-STACK-2)
Jan 2 2017 07:41:29.781 EST: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/test-365.cfg) failed (TEST-3650-SW-STACK-2)
Jan 2 2017 07:47:20.405 EST: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/network-confg) failed
Jan 2 2017 07:47:58.407 EST: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/cisconet.cfg) failed
Jan 2 2017 07:48:34.448 EST: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/test-3650-sw-stack-confg) failed
We are using DHCP to facilitate PNP, but we are also using Microsoft's DHCP. We have global rules in place for DNS and TFTP. Because I ran into issues during testing, I made local rules in the scope I was using for PNP to point DNS and TFTP at my APIC-EM IP.
Anyone else seeing similar results?
