CCIE R&S Written : Infrastructure Security

AAA and Local Database

AAA and Local Database -additional methods of authentication are used only if the previous method returns an error, not if it fails. To specify that the authentication should succeed even if all methods return an error, specify none as the final method in the command line. -for ppp aaa authentication, ("double") authentication requires a password that is known to the user but not stored on the user's remote host. Therefore, the second authentication is specific to a user, not to a host. -AAA broadcast accounting allows accounting information to be sent to multiple AAA servers at the same time; that is, accounting information can be broadcast to one or more AAA servers simultaneously. For more accounting, you can include the start-stop keyword, so that RADIUS or TACACS+ sends a "start" accounting notice at the beginning of the requested process and a "stop" accounting notice at the end of the process. Accounting is stored only on the RADIUS or TACACS+ server. The none keyword disables accounting services for the specified line or interface. -The "aaa authorization network" command runs authorization for all network-related service requests such as PPP, SLIP and ARAP. -To allow users to have access to the functions they request as long as they have been authenticated, use the "aaa authorization" command with the "if-authenticated" method keyword. If you select this method, all requested functions are automatically granted to authenticated users. i.e. The "aaa authorization exec default group radius if-authenticated" command configures the network access server to contact the RADIUS server to determine if users are permitted to start an EXEC shell when they log in. If an error occurs when the network access server contacts the RADIUS server, the fallback method is to permit the CLI to start, provided the user has been properly authenticated.

Access Lists

ACL -Standard ACLs only filter based on source IP addresses -can log both permitted and denied access list entries -both named and numbered modes are available for standard and extended access-lists -If you want to filter on anything other than source address, you need to create an extended access list. -Extended ACLs with "established" keyword - The "established" keyword is used to indicate an established connection for TCP protocol. An established connection can be considered as the TCP protocol traffic originating inside your network, not from an external network. This can be recognized with the ACK or RST bit set on the data packet. Dynamic ACL -Lock and key configuration starts with the application of an extended ACL to block traffic through the router. Users that want to traverse the router are blocked by the extended ACL until they Telnet to the router and are authenticated. The Telnet connection then drops and a single-entry dynamic ACL is added to the extended ACL that exists. This permits traffic for a particular time period; idle and absolute timeouts are possible. Dynamic ACLs are used for controlling Telnet traffic Reflexive ACL -Reflexive ACL are like ACLs with "established" keyword in terms of restricting packet forwarding. Reflexive access lists, however, provide a truer form of session filtering, which is much harder to spoof because more filter criteria must be matched before a packet is permitted through. Also, session filtering uses temporary filters which are removed when a session is over. -Reflexive access lists contain only temporary entries; these entries are automatically created when a new IP session begins (for example, with an outbound packet), and the entries are removed when the session ends. Reflexive access lists are not themselves applied directly to an interface, but are "nested" within an extended named IP access list that is applied to the interface. -reflexive access lists do not have the usual implicit "deny all traffic" statement at the end of the list, because of the nesting. -A reflexive access list is triggered when a new IP upper-layer session (such as TCP or UDP) is initiated from inside your network, with a packet traveling to the external network. When triggered, the reflexive access list generates a new, temporary entry. This entry will permit traffic to enter your network if the traffic is part of the session, but will not permit traffic to enter your network if the traffic is not part of the session. -For example, if an inbound TCP packet is forwarded to outside of your network, and this packet is the first packet of a TCP session, then a new, temporary reflexive access list entry will be created. This entry is added to the reflexive access list, which applies to inbound traffic. Time-Based ACLs -A time range is created that defines specific times of the day and week in order to implement time-based ACLs. The time range is identified by a name and then referenced by a function. -

CoPP

CoPP -"Punt" is often used to describe the action of moving a packet from the fast path to the route processor for handling. -packets processed by CPU, These include control plane and management plane packets that are destined to the network device itself. -unlike rACLs (receive ACL) that only apply to receive destination IP packets, CoPP applies to all packets that punt to the route processor for handling. CoPP therefore covers not only receive destination IP packets, it also exceptions IP packets and non-IP packets -rACLs only provide permit and deny actions and only apply to IP packets with receive destination addresses. - receive ACLs filter traffic destined to the route processor of a network device. -Control Plane Policing" is something of a misnomer because CoPP generally protects the punt path to the route processor and not solely the control plane. It also inspect traffic from management plane and serivice plane (QoS, etc.) -CoPP is implemented using the Cisco IOS Modular QoS CLI (MQC), a highly flexible framework that allows users to create and attach traffic polices to interfaces -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. - policy-map for output CoPP is constructed the same way as it is for input CoPP, however, the only types of traffic to be considered are those generated by or forwarded by the route processor. -ARP traffic is not covered by CoPP, but CPPr can do it -configure ACL, class-map, policy map, and use service-policy under "control-plane" CPPr -Control Plane Protection Cisco Control Plane Protection (CPPr), introduced in Cisco IOS Software Release 12.4(4)T, extends the CoPP feature set by enabling finer granularity classification of punted traffic based on packet destination and information provided by the forwarding plane, allowing appropriate throttling for each category of packet. CPPr creates three virtual control plane categories, known as subinterfaces, under the aggregate control plane interface for this purpose -Host subinterface: All control plane and management plane traffic directly destined for one of the routers physical or logical interfaces must be handled by the route processor. This also includes tunnel termination packets. Transit subinterface: Certain data plane traffic traversing the router and that a configured router feature requires additional processing to be completed by the route processor before it can be forwarded. CEF-exception subinterface: Certain traffic related to router or network operations (such as Layer 2 keepalives), and packets having certain attributes that require further processing by the route processor, such as TTL 0 or 1 (expires). -Access control lists (ACLs) cannot be applied directly to the control plane subinterfaces. Instead, ACLs are used within the MQC policies (that is, class maps) and the service policy is then applied to the individual control plane subinterfaces -CPPr includes the following additional control plane protection features: The port-filtering feature provides for policing/dropping of packets going to closed or nonlistening TCP/UDP ports Queue thresholding limits the number of packets for a specified protocol that will be allowed in the control plane IP input queue -Non-IP-based Layer 2 protocol packets such as ARP or CDP do not fall within the control plane host subinterface. These packets are currently classified in the control plane CEF-exception subinterface traffic. -Control Plane Protection is restricted to the IPv4 input path only. -requires CEF to be enabled -configure ACL, class-map, policy map, and use service-policy under "control-plane host" -

DHCP Snooping

DHCP Snooping -The DHCP snooping binding table contains the MAC address, IP address, lease time, binding type, VLAN number, and interface information that corresponds to the local untrusted interfaces of a switch; it does not contain information regarding hosts interconnected with a trusted interface -The default trust state of all interfaces is untrusted. For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces, as untrusted DHCP messages will be forwarded only to trusted interfaces. -switches that have DHCP Snooping enabled will drop received DHCP packets that have Option 82 with giaddr of 0.0.0.0. (SW2). But by default a switch that has Snooping enabled and acting as a DHCP relay agent will insert option 82 with giaddr 0.0.0.0 onto incoming DHCP messages before relaying it to the next switch. (SW1). Therefore when SW1 relays the DHCP message to SW2, the SW2 will drop the message. Several methods to fix this, on SW2 configure "ip dhcp snooping information option allow-untrusted" so that SW2 will not add option 82 when relaying DHCP packets. Global configuration on client switch and relay switch "no ip dhcp snooping information option" works as well, this disables option 82 on the switches.

Dynamic ARP Inspection

Dynamic ARP Inspection - It is important to note that static ARP ACLs have precedence over entries in the DHCP snooping database. ARP Packets are first compared to user-configured ARP ACLs. If the ARP ACL denies the ARP packet, then the packet will be denied even if a valid binding exists in the database populated by DHCP snooping. -On untrusted interfaces, the switch intercepts all ARP requests and responses. -DAI performs validation checks in the CPU, so the number of incoming ARP packets is rate-limited to prevent a denial of service attack. -By default, the rate for untrusted interfaces is set to 15 packets per second, whereas trusted interfaces have no rate limit. -does not inspect IP packets, only inspects ARP packets! -"ip arp inspection filter arp-acl-name vlan vlan-range [ static ]" - By default, if static ACL is configured to use for DAI, it is first inspected and if denied, the ARP packet is dropped. If it is permitted by the static ACL, the packet is then inspected in the DHCP Snooping database. Also, by default, the ACL does not use the implicit deny at the end of the ACL when inspecting traffic i.e. traffic that doesn't match any of the ACL entries will not be automatically dropped. However, if the the optional addition of the "static" keyword is used with the ACL, the implicit deny rule at the end of the ACL will be made an explicit rule i.e. traffic not matching any of the ACL entries will hit the explicit deny rule and be dropped! Also, traffic now will only be inspected by the ARP ACL and no longer checked on by the DHCP Snooping database. -"ip arp inspection validate {[dst-mac] [ip] [src-mac]} " - DAI intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings. You can also enable additional validation on the destination MAC address, the sender and target IP addresses, and the source MAC address. -"ip arp inspection log-buffer entries [number]" - configures the number of log entries to retain for DAI

RADIUS

EAP -Inside the framework provided by 802.1X and EAP, the endpoint and/or user must authenticate to the authentication server using a secure and reliable EAP method. The EAP method determines the type of credential that is used and how that credential is submitted. -many EAP methods, two of which are EAP-TLS and PEAP-MSCHAPv2 -EAP-TLS addresses a number of weaknesses in other EAP protocols by using X.509 certificates for secure authentication. In addressing these weaknesses, however, EAP-TLS increases the complexity of deployment. -EAP-TLS requires client-side and server-side certificates for mutual authentication. -PEAP is an EAP type that addresses security issues by first creating a secure channel that is both encrypted and integrity-protected with TLS. This tunnel is created using a valid server certificate that the authentication server sends to the supplicant at the beginning of the PEAP negotiation. Inside this secure channel, a new EAP negotiation takes place to authenticate the client. This second EAP negotiation can be virtually any EAP type. -MSCHAPv2 is commonly used as the second EAP type inside a PEAP tunnel. MS-CHAPv2 is a password-based, challenge-response, mutual authentication protocol that uses Message-Digest Algorithm (MD4) and Data Encryption Standard (DES) to encrypt responses. The authenticator challenges a supplicant and the supplicant can challenge the authentication server. If either challenge is not correctly answered, the connection can be rejected.

IP Source Guard

IP Source Guard -dhcp snooping must be enabled! -ip verify source vlan dhcp-snooping [ port-security ] - Enables IP source guard, source IP address filtering on the port. The following are the command parameters: "vlan" applies the feature to only specific VLANs on the interface. The "dhcp-snooping" option applies the feature to all VLANs on the interface that have DHCP snooping enabled. "port-security" enables MAC address filtering I.e. the MAC must match the recorded entry in the snooping database CAVEAT: in order to use Mac filtering, we must first enable port-security on the interface! -

IPv6 First Hop Security

IPv6 RA Guard -creates policy and applies on interface -only trusted ports can be allowed to accept incoming ND RAs -In host mode, all RA and router redirect messages are disallowed on the port. -In router mode, all messages (router solicitation [RS], router advertisement [RA], or redirect) are allowed on this port. -You can also match ipv6 access-list or Prefix-list command enables verification of the sender's IPv6 address in inspected messages from the configured authorized router source access list. -The router-preference maximum command limit is high, medium, or low. If, for example, this value is set to medium and the advertised default router preference is set to high in the received packet, then the packet is dropped. -The RA guard feature compares configuration information on the Layer 2 (L2) device with the information found in the received RA frame. Once the L2 device has validated the content of the RA frame and router redirect frame against the configuration, it forwards the RA to its unicast or multicast destination. If the RA frame content is not validated, the RA is dropped. DHCP—DHCPv6 Guard -This feature blocks DHCP reply and advertisement messages that originate from unauthorized DHCP servers and relay agents that forward DHCP packets from servers to clients. Client messages or messages sent by relay agents from clients to servers are not blocked. -The filtering decision is determined by the device role assigned to the receiving switch port, trunk, or VLAN. In addition, to provide a finer level of filter granularity, messages can be filtered based on the address of the sending server or relay agent, or by the prefixes and addresses ranges listed in the reply message. -Packets are classified into one of the three DHCP type messages. All client messages are always switched regardless of device role. DHCP server messages are only processed further if the device role is set to server. IPv6 Snooping/Inspection -IPv6 Snooping learns and secures bindings for stateless autoconfiguration addresses in Layer 2 neighbor tables and analyzes ND messages in order to build a trusted binding table. IPv6 ND messages that do not have valid bindings are dropped. An ND message is considered trustworthy if its IPv6-to-MAC mapping is verifiable. -inspection vs snooping: inspection uses the ND binding table only to validate but snooping uses both ND and DHCP gleaned blinding tables to verify addresses! Binding Table -A database table of IPv6 neighbors connected to the device is created from information sources such as ND snooping. This database, or binding, table is used by various IPv6 guard features to validate the link-layer address (LLA), the IPv4 or IPv6 address, and prefix binding of the neighbors to prevent spoofing and redirect attacks. -This mechanism enables the binding table to recover in the event of a device reboot. The recovery mechanism will block any data traffic sourced from an unknown source; that is, a source not already specified in the binding table and previously learned through ND or DHCP gleaning Device Tracking -IPv6 device tracking provides IPv6 host liveness tracking so that a neighbor table can be immediately updated when an IPv6 host disappears. -Perform this task to provide fine tuning for the life cycle of an entry in the binding table for the IPv6 Device Tracking feature. For IPv6 device tracking to work, the binding table needs to be populated. -If you enable tracking, as shown above, hosts get probed with an "are you still there?" if no ND packets are heard periodically. Source Guard -If the data-plane traffic - any traffic other than IPv6 ND/RA and DHCP - doesn't match the source address present in the prebuilt binding table, drop the traffic. Destination Guard -The IPv6 Destination Guard feature works with IPv6 neighbor discovery to ensure that the device performs address resolution only for those addresses that are known to be active on the link. It relies on the address glean functionality to populate all destinations active on the link into the binding table and then blocks resolutions before they happen when the destination is not found in the binding table. -the device will drop NS that have destinations not already recorded in the established binding table Address Glean -IPv6 address glean is the foundation for many other IPv6 features that depend on an accurate binding table. It inspects ND and DHCP messages on a link to glean addresses, and then populates the binding table with these addresses. This feature also enforces address ownership and limits the number of addresses any given node is allowed to claim.

IPv6 Traffic Filter

IPv6 Traffic Filter -IPv4 access-lists can be standard or extended, numbered or named. IPv6 only has named extended access-lists. -IPv4 access-lists have an invisible implicit deny any at the bottom of every access-list. IPv6 access-lists have three invisible statements at the bottom: permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any -IPv6 supports only named, extended access lists. -IPv6 ACLs are applied to interfaces using the command ipv6 traffic-filter. -IPv6 ACLs are applied to lines using the command ipv6 access-class.

Terminal Services

Line vty -"no line vty 5" would mean deleting line 5 and above -rotary would add other ports (3000) besides 23 for telnet, e.g. rotary 5 means port 3005

Management Plane Protection

Management Plane Protection -The Management Plane Protection (MPP) feature in Cisco IOS XR software provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. The MPP feature allows a network operator to designate one or more router interfaces as management interfaces and can permit certain mgmt protocols only -Examples of protocols processed in the management plane are Simple Network Management Protocol (SNMP), Telnet, HTTP, Secure HTTP (HTTPS), and SSH, tftp, beep -the management plane performs management functions for a network and coordinates functions among all the planes (management, control, and data)

PACL

PACL -PACLs filter incoming traffic on Layer 2 interfaces, using Layer 3 information, Layer 4 header information, or non-IP Layer 2 information. -Port ACLs are applied only on the ingress traffic of a layer 2 interface -PACLs use the following modes: • Prefer port mode—If a PACL is configured on a Layer 2 interface, the PACL takes effect and overwrites the effect of other ACLs (Cisco IOS ACL and VACL). If no PACL feature is configured on the Layer 2 interface, other features applicable to the interface are merged and are applied on the interface. • Merge mode—In this mode, the PACL, VACL, and Cisco IOS ACLs are merged in the ingress direction following the logical serial model. This is the default access group mode. -PACL can be configured on a trunk port only after prefer port mode has been selected. Trunk ports do not support merge mode. -illustrate access group mode, assume a physical port belongs to VLAN100, and the following ACLs are configured: • Cisco IOS ACL R1 is applied on routed interface VLAN100. • VACL (VLAN filter) V1 is applied on VLAN100. • PACL P1 is applied on the physical port. In this situation, the following ACL interactions occur: • In prefer port mode, Cisco IOS ACL R1 and VACL V1 are ignored. • In merge mode, Cisco IOS ACL R1, VACL V1 and PACL P1 are merged and applied on the port. -PACL feature supports MAC ACLs, IPv4, and IPv6 ACLs. The PACL feature does not support ACLs for ARP or Multiprotocol Label Switching (MPLS) traffic. -PACLs are supported on the main Layer 2 etherchannel interface but not on the port members -For an incoming packet on a physical port, the PACL is applied first. If the packet is permitted by the PACL, the VACL on the ingress VLAN is applied next. If the packet is Layer 3 forwarded and is permitted by the VACL, lastly it is filtered by the Cisco IOS ACL on the same VLAN. The same process happens in reverse in the egress direction. However, there is currently no hardware support for output PACLs. -

Password Encryption

Password Encryption -Enable secrets are hashed using the MD5 algorithm. -To determine which scheme has been used to encrypt a specific password, check the digit preceding the encrypted string in the configuration file. If that digit is a 7, the password has been encrypted using the weak algorithm. If the digit is a 5, the password has been hashed using the stronger MD5 algorithm. For example, in the configuration command: enable secret 5 $1$iUjJ$cDZ03KKGh7mHfX2RSbDqP. The enable secret has been hashed with MD5, whereas in the command: username jdoe password 7 07362E590E1B1C041B1E124C0A2F2E206832752E1A01134D The password has been encrypted using the weak reversible algorithm. -Service password encryption only affects plain text passwords such as the line passwords or the enable password. This feature uses a simple substitution method to create a "secure" non-text password displayed in the configuration -The enable secret password command, which was added in version 11.0 of the IOS is encrypted with the MD5 hashing algorithm and is ALWAYS encrypted. Note the command was added after service-password encryption command and it is NOT affected by the service-password encryption command

Port Security

Port Security -When you assign secure MAC addresses to a secure port, the port does not forward ingress traffic packets with source addresses outside the group of defined addresses -After a secure MAC address is configured or learned on one secure port, the sequence of events that occurs when port security detects that secure MAC address on a different port in the same VLAN is known as a MAC move violation and will result in traffic being dropped. -Port security with sticky MAC addresses retains dynamically learned MAC addresses during a link-down condition. Without sticky Mac, dynamically learned addresses will not be retained after link flap or reboot -Secure MAC addresses dynamically learned in a voice VLAN are not converted to sticky MAC addresses. -Port security can be configured to take one of three actions upon detecting a violation: Shutdown Mode (default) ; The interface is placed into the error-disabled state, blocking all traffic and SNMP logs are generated. Protect Mode; Frames from MAC addresses other than the allowed addresses are dropped; traffic from allowed addresses is permitted to pass normally. Restrict Mode; Like protect mode, but generates a Syslog message and increases the violation counter.

Private VLAN

Private VLAN -Primary VLAN—A private VLAN has only one primary VLAN. Every port in a private VLAN is a member of the primary VLAN. The primary VLAN carries unidirectional traffic downstream from the promiscuous ports to the (isolated and community) host ports and to other promiscuous ports. •Isolated VLAN —A private VLAN has only one isolated VLAN. An isolated VLAN is a secondary VLAN that carries unidirectional traffic upstream from the hosts toward the promiscuous ports and the gateway. •Community VLAN—A community VLAN is a secondary VLAN that carries upstream traffic from the community ports to the promiscuous port gateways and to other host ports in the same community. You can configure multiple community VLANs in a private VLAN. -promiscuous port can serve only one primary VLAN, one isolated VLAN, and multiple community VLANs -Configure Layer 3 VLAN interfaces only for primary VLANs. You cannot configure Layer 3 VLAN interfaces for secondary VLANs. SVIs for secondary VLANs are inactive while the VLAN is configured as a secondary VLAN. -Extended VLANs (VLAN IDs 1006 to 4094) can belong to private VLANs -A primary VLAN can have one isolated VLAN and multiple community VLANs associated with it. An isolated or community VLAN can have only one primary VLAN associated with it. -•Although a private VLAN contains more than one VLAN, only one Spanning Tree Protocol (STP) instance runs for the entire private VLAN. -Although private VLANs provide host isolation at Layer 2, hosts can communicate with each other at Layer 3.

SNMP

SNMP -Unsolicited (asynchronous) notifications can be generated as traps or inform requests (informs). Traps are messages alerting the SNMP manager to a condition on the network. Informs are traps that include a request for confirmation of receipt from the SNMP manager. -traps sent without request from SNMP Client -Both SNMPv1 and SNMPv2c use a community-based form of security. The community of SNMP managers able to access the agent MIB is defined by an IP address access control list (ACL) and password. -SNMPv2c support includes a bulk retrieval mechanism and detailed error message reporting to management stations. The bulk retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round trips required. The SNMPv2c improved error handling support includes expanded error codes that distinguish different types of errors; these conditions are reported through a single error code in SNMPv1. -You can configure the Cisco IOS software to support communications with one management station using the SNMPv1 protocol, one using the SNMPv2c protocol, and another using SMNPv3. -The ifIndex object (ifEntry 1) is called the Interface Index. The Interface Index is a unique value greater than zero that identifies each interface or subinterface on the managed device. This value becomes the interface index identification number. IfIndex is a unique identifying number associated with a physical or logical interface; as far as most software is concerned, the ifIndex is the name of the interface. -IfIndex persistence means that the mapping between the ifDescr object values and the ifIndex object values (generated from the IF-MIB) will be retained across reboots. I.e. ifIndex values remain the same after reboot "snmp ifindex persist" -The ifAlias object (ifXEntry 18) is called the Interface Alias. The Interface Alias is a user-specified description of an interface used for SNMP network management. -The SNMP Support for VPNs feature allows SNMP traps and informs to be sent and received using VPN routing and forwarding (VRF) tables. -The MIB Persistence features allow the SNMP data of a MIB to be persistent across reloads I.e. "snmp mib persist event " -The Event MIB provides the ability to monitor MIB objects on a local or remote system using SNMP and initiate simple actions whenever a trigger condition is met; for example, an SNMP trap can be generated when an object is modified. -The Event MIB allows the user to have the device monitoring its own MIB objects and to generate actions (notification or SNMP SET commands) based on a defined event. The Event MIB operates based on event, object lists configured for the event, event action, trigger, and trigger test. The event table defines the activities to be performed when an event is triggered. These activities include sending a notification and setting a MIB object. The object table lists objects that can be added to notifications based on trigger, trigger test type, or the event that sends a notification. The trigger table defines conditions to trigger events. The trigger table lists the objects to be monitored and associates each trigger with an event. The trigger table has supplementary tables for additional objects that are configured based on the type of test performed for a trigger. In summary, Event MIB allows configuration of when, what, and how notifications are sente.g. The event, object, and trigger. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. -The Expression MIB allows you to create expressions based on a combination of objects. the Expression MIB is a way to create new, customized MIB objects for monitoring. I.e. create your own MIB by combing existing MIB values. The expressions are evaluated according to the sampling method. The Expression MIB allows the user to create his own MIB object based on a combination of other objects. The Expression MIB supports the following types of object sampling: Absolute Delta Changed -If you do not enter a snmp-server host command, no notifications are sent. To configure the router to send SNMP notifications, you must enter at least one snmp-server host command. If you enter the command without keywords, all trap types are enabled for the host. When multiple snmp-server host commands are given for the same host and type of notification, each succeeding command overwrites the previous command. Only the last snmp-server host command will be in effect. Use the snmp-server enable command to specify which SNMP notifications are sent globally -before you configure remote users for a particular agent, configure the SNMP engine ID using the snmp-server engineID command with the remote option. The remote agent's SNMP engine ID is required when computing the authentication and privacy digests from the password. If the remote engine ID is not configured first, the configuration command will fail. You cannot configure a remote user for an address without first configuring the engine ID for that remote host. -SNMP requests typically are sent to UDP port 161. SNMP responses are typically sent from UDP port 161. SNMP notifications are typically sent to UDP port 162.

Storm Control

Storm Control -Traffic storm control (also called traffic suppression) monitors incoming traffic levels over a 1-second traffic storm control interval and, during the interval, compares the traffic level with the traffic storm control level that you configure. The traffic storm control level is a percentage of the total available bandwidth of the port. Each port has a single traffic storm control level that is used for all types of traffic (broadcast, multicast, and unicast). -Traffic storm control does not suppress spanning tree packets. Except for spanning tree packets, traffic storm control does not differentiate between control traffic and data traffic. -Traffic storm control monitors the level of each traffic type for which you enable traffic storm control in 1-second traffic storm control intervals. Within an interval, by default when the ingress traffic for which traffic storm control is enabled reaches the traffic storm control level that is configured on the port, traffic storm control drops the traffic until the traffic storm control interval ends. -Be careful when configuring both broadcast+multicast, unicast or any combination. Crossing over of configured level of anyone (broadcast, multicast, unicast) or combined will stop all of them. i.e. If you enable broadcast and multicast traffic storm control, and broadcast traffic exceeds the level within a 1-second traffic storm control interval, traffic storm control drops all broadcast and multicast traffic until the end of the traffic storm -"storm-control broadcast level 30 15 " means that broadcast traffic can use up to 30 percent of the configured interface bandwidth. But once it reaches the high threshold, traffic will be default drop. Traffic will drop until it falls below the low threshold of 15 percent of interface bandwidth.

URPF

URPF -When administrators use Unicast RPF in strict mode, the packet must be received on the interface that the router would use to forward the return packet. -When administrators use Unicast RPF in loose mode but incoming interface doesn't have to match, the source address must appear in the routing table. Administrators can change this behavior using the allow-default option, which allows the use of the default route in the source verification process. -Unicast RPF loose mode is a scalable option for networks that contain asymmetric routing paths because it does not require source ip to come in interface that matches destination -"ip verify unicast source reachable-via {rx | any} [allow-default]" rx for strict mode and any for loose mode -With Unicast RPF, all equal-cost "best" return paths are considered valid. -If an ACL is specified in the command, when (and only when) a packet fails the Unicast RPF check, the ACL is checked to see if the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). For both modes, access list permit statements allow traffic to be forwarded even if they fail the Unicast RPF check, access list deny statements will drop traffic matched that fail the Unicast RPF check. Thus, by including an ACL with uRPF, the ACL will kind of override the uRPF check. -strict mode checks if both interface and route to source is in table. Loose mode only checks if route to source is in table. -

VACL

VACL -If you apply a VACL to the VLAN and an ACL to a routed interface in the VLAN, a packet coming in to the VLAN is first checked against the VACL and, if permitted, is then checked against the input ACL before it is handled by the routed interface. When the packet is routed to another VLAN, it is first checked against the output ACL applied to the routed interface and, if permitted, the VACL configured for the destination VLAN is applied -IMPORTANT! When a flow matches a permit ACL entry that is matched in the VACL sequence, the associated action is taken and the flow is not checked against the remaining sequences. When a flow matches a deny ACL entry, it will be checked against the next ACL in the same sequence or the next sequence. If a flow does not match any ACL entry and at least one ACL is configured for that packet type, the packet is denied. The sequence is referring to the ACL numbers, not the ACL entries i.e. VACL seq 10 is checked first and if in that there is an ACL that has deny statement for traffic 10.0.0.1, then the traffic will move to the next VACL seq 20 and be checked on there! If you use and ACL with a deny statement and regardless of the route-map is Deny/Permit, the packet will go pass the first route-map sequence and into the next route-map sequence to be evaluated again. -VACLs have an implicit deny at the end of the map; a packet is denied if it does not match any ACL entry, and at least one ACL is configured for the packet type. -If an empty or undefined ACL (no "match" statement) is specified in a VACL, any packets will match the ACL and the associated configured action will be taken. -VACLs cannot be applied to IGMP, MLD, or PIM traffic. -You can specify only one match clause and one action clause per map sequence. -one match clause can match multiple ACLs -VACLs applied to VLANs are active only for VLANs with a Layer 3 VLAN interface configured. Applying a VLAN access map to a VLAN without a Layer 3 VLAN interface creates an administratively down Layer 3 VLAN interface to support the VLAN access map. -You cannot apply a VACL to a secondary private VLAN. VACLs applied to primary private VLANs also apply to secondary private VLANs.