NTP Control – Effect of Using ‘ntp allow mode control 0’

ciscocisco-iosntp

I am attempting to mitigate the issues surrounding bug report CSCum44673. According to the software release notes found here, I need to ensure that all of my routers are on IOS version 15.2(2) or newer. I also believe I need to include the statement "NTP allow mode control 3" on each of them.

So far I've verified that all of my routers are on newer software versions than that. What I am confused about is that many of them include the statement, "NTP allow mode control 0". I was under the impression per the above-linked software release that the only allowed values were from 3 – 15. I am also under the impression that a value of 3 is the default value.

What is the effect of using a 0 for the value?

Does this effectively mean that rate-limiting of NTP queries is turned off and that the router is still vulnerable to the potential DoS attack described in that bug report?

Is this command only useful if the router is set up as an NTP master ("NTP master 3" for example in the config)?

If it is only configured to synchronize with an NTP server located elsewhere ("NTP server x.x.x.x" in the config) does this command have any use?

Thanks for any clarification.

Best Answer

I was able to receive a response to this question in the Cisco community forums. See here: https://community.cisco.com/t5/network-management/effect-of-using-quot-ntp-allow-mode-control-0-quot/m-p/4032680#M132875

Related Solutions

Cisco – the effect of SVI MTU on Catalyst 6509

Regarding jumbo frame support on the Cat6k, IIRC the default system MTU size is 9216, but there are some modules where a maximum ingress frame size of only 8092 bytes is supported vs 9216 bytes (they'll drop frames larger than 8092 bytes at ingress). Double check the documentation to find out which modules exactly have this limitation.

Regarding the port-channels, if both ports in the port-channel are already set to the same MTU of 9216, it shouldn't make a difference if you configure the port-channel interface to have a 9216 MTU, but it wouldn't hurt for completeness'/clarity's sake in your configuration. You actually can't have two ports in an EtherChannel that have different MTU sizes.

Regarding the SVI's, there's really not much of a difference between routing jumbo frames across a routed L3 interface or an SVI (they're essentially the same thing) - just realize that if fragmentation is required across an L3 interface (ie a jumbo frame is routed from one L3 interface to another with a smaller MTU), the frame is punted to the CPU for fragmentation in software, and this can lead to problems. The rule of thumb here is to keep your jumbo frame traffic localized to other destinations/networks that also support jumbo frames.

While changing the MTU on the VLANs themselves shouldn't really be necessary, make sure that the interface MTU is the same across all the interfaces in the VLAN before setting the VLAN MTU to that same value. And similar to the port-channels, if you already have 9216 as the interface MTU's and the VLAN MTU for those interfaces, it shouldn't actually cause problems to set the MTU of the SVI for those VLANs to 9216.

Benefits of Using CBWFQ with Fair-Queue Statement in Cisco IOS

To summarize my comments:

The benefit of using CBWFQ (class based weighted fair queuing) with the fair-queue statement in the class-default queue (your second example):

...
 class class-default
  fair-queue
  queue-limit 1024 packets
...

Packets use WFQ (weighted fair queuing) for scheduling and are de-queued based on their calculated weight.

When using CBWFQ without the fair-queue statement in the class-default queue (your first example):

...
 class class-default
  bandwidth remaining percent 20
  random-detect dscp-based      
...

Packets are de-queued using the FIFO (first in first out) method.

Related Topic