Tired of Windows 10 upgrade Nags? Here i

Tired of Windows 10 upgrade Nags? Here is a great little program to get rid of it. Download to your desktop and then right click – run as Administrator. Wait for it…. Ta Dah! The little Windows 10 icon is gone and it won’t keep bugging you.

Wish I had wrote it, but it is from:
http://www.tweaking.com/articles/pages/remove_windows_nag_icon_to_upgrade_to_windows_10,1.html http://ow.ly/XZugq

CCNA SECURITY CoPP ACL’S

I sent this to Pearson feedback on Testing Engine for CCNA Security 210 – 260 as well – am I correct?

In the following CoPP access control list example, which traffic is being prevented from reaching the control plane?

NOTE: This question contains an exhibit. Press the Exhibits Button to see the exhibit.

A. Telnet traffic from the 192.168.1.0/24
B. Telnet & DNS traffic from the 192.168.1.0/24 subnet – THIS IS MARKED AS CORRECT BASED ON EXHIBIT.
C. DNS traffic from the 192.168.1.0/24 subnet
D. Telnet and DNS traffic from outside the 192.168.1.0./24 subnet – THIS IS CORRECT ANSWER – partially, depends on policy statement

Explanation: When constructing Access Control Lists (ACLs) to be used for CoPP you have to remember that traffic which is “permitted” translates to traffic that will be inspected by CoPP and traffic which is “denied” translates to traffic that is bypassed by CoPP. Please reference this White Paper on CoPP:http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html, specifically this section on Access List Construction:
There are several caveats and key points to keep in mind when constructing your access lists.

The log or log-input keywords must never be used in access-lists that are used within MQC policies for CoPP. The use of these keywords may cause unexpected result in the functionality of CoPP.
The use of the deny rule in access lists used in MQC is somewhat different to regular interface ACLs. Packets that match a deny rule are excluded from that class and cascade to the next class (if one exists) for classification. This is in contrast to packets matching a permit rule, which are then included in that class and no further comparisons are performed. “

The exhibit is not complete enough – the statements in the policy-map determine what action is taken. The acl determines whether or not the traffic is included in the class.

EXHIBIT

Extended IP access list 123
10 deny tcp 192.168.1.0 0.0.0.255 any eq telnet Packets that match a deny rule are excluded from that class TELNET FROM 192.168.1.0 IS IGNORED.
20 deny udp 192.168.1.0 0.0.0.255 any eq domain Packets that match a deny rule are excluded from that class DNS FROM 192.168.1.0 IS IGNORED.
30 permit tcp any any eq telnet packets matching a permit rule, which are then included in that class ALL OTHER TELNET – POLICY MAP POLICE STATEMENT APPLIED
40 permit udp any any eq domain packets matching a permit rule, which are then included in that class ALL OTHER DNS – POLICY MAP POLICE STATEMENT APPLIED
50 deny ip any any
———————————————————————————————————————————————————————

To be effective the question needs to include the policy and police statements – you cannot infer from just the ACL what is going to happen to the packets. Deny means ignore as far as policy and Permit means apply the policy to the packets, so:

class-map match-all PEARSON
match access-group 123

policy-map Pearson_Example
class PEARSON

police 10000 5000 5000 conform-action DROP exceed-action drop – in this case your “correct” answer would be WRONG. THIS WOULD BLOCK Telnet and DNS traffic from OUTSIDE the 192.168.1.0./24 subnet

police 10000 5000 5000 conform-action TRANSMIT exceed-action drop – in this case your “correct” answer would be: ALLOW Telnet & DNS traffic from OUTSIDE the 192.168.1.0/24 subnet.

Packets that match a deny rule are EXCLUDED from that class and cascade to the next class (if one exists) for classification. This is in contrast to packets matching a permit rule, which are then INCLUDED in that class and no further comparisons are performed.

The class class-default is automatically placed at the end of the policy map. Similar to implicity deny on acls. So all the traffic from 198.162.1.0 /24 is actually unaffected by the acl in the context of the policy map.