Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Review the switch configuration to verify that ACLs are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. For example, the configuration below will allow only printer traffic into subnet 10.1.12.0/24 and SQL traffic into subnet 10.1.13.0/24. ICMP is allowed for troubleshooting and OSPF is the routing protocol used within the network. interface GigabitEthernet0/1 no switchport ip address 10.2.1.1 255.255.255.252 ip access-group FILTER_SERVER_TRAFFIC in … … … ip access-list extended FILTER_SERVER_TRAFFIC permit tcp any 10.1.12.0 0.0.0.255 eq lpd 631 9100 permit tcp any 10.1.13.0 0.0.0.255 eq 1433 1434 4022 permit icmp any any permit ospf any any deny ip any any Alternate: Inter-VLAN routing interface Vlan12 ip address 10.1.12.1 255.255.255.0 ip access-group FILTER_PRINTER_VLAN out ! interface Vlan13 ip address 10.1.13.1 255.255.255.0 ip access-group FILTER_SQL_VLAN out … … … ip access-list extended FILTER_PRINTER_VLAN permit tcp any any eq lpd 631 9100 permit icmp any any deny ip any any ip access-list extended FILTER_SQL_VLAN permit tcp any any eq 1433 1434 4022 permit icmp any any deny ip any any If the switch is not configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding.
Configure ACLs to allow or deny traffic for specific source and destination addresses as well as ports and protocols between various subnets as required. The commands used below were used to create the configuration as shown in the check content. SW1(config)#ip access-list extended FILTER_SERVER_TRAFFIC SW1(config-ext-nacl)#permit tcp any 10.1.12.0 0.0.0.255 eq 515 631 9100 SW1(config-ext-nacl)#permit tcp any 10.1.13.0 0.0.0.255 eq 1433 1434 4022 SW1(config-ext-nacl)#permit icmp any any SW1(config-ext-nacl)#permit ospf any any SW1(config-ext-nacl)#deny ip any any SW1(config-ext-nacl)#exit SW1(config)#interface g0/1 SW1(config-if)#ip access-group FILTER_SERVER_TRAFFIC in SW1(config-if)#end Alternate: Inter-VLAN routing SW1(config)#ip access-list extended FILTER_PRINTER_VLAN SW1(config-ext-nacl)#permit tcp any any eq lpd 631 9100 SW1(config-ext-nacl)#permit icmp any any SW1(config-ext-nacl)#deny ip any any SW1(config-ext-nacl)#exit SW1(config)#ip access-list extended FILTER_SQL_VLAN SW1(config-ext-nacl)#permit tcp any any eq 1433 1434 4022 SW1(config-ext-nacl)#permit icmp any any SW1(config-ext-nacl)#deny ip any any SW1(config-ext-nacl)#exit SW1(config)#interface vlan 12 SW1(config-if)#ip access-group FILTER_PRINTER_VLAN out SW1(config-if)#exit SW1(config)#interface vlan 13 SW1(config-if)#ip access-group FILTER_SQL_VLAN out SW1(config-if)#end
Review the switch configuration. Verify that authentication is enabled for all routing protocols. The configuration examples below depicts OSPF, EIGRP, IS-IS and BGP authentication. BGP Example: router bgp nn no synchronization bgp log-neighbor-changes neighbor x.x.x.x remote-as nn neighbor x.x.x.x password xxxxxxx EIGRP Example: key chain EIGRP_KEY key 1 key-string xxxxxxx … … … interface GigabitEthernet0/0 no switchport ip address x.x.x.x 255.255.255.0 ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 EIGRP_KEY IS-IS Example: interface GigabitEthernet0/0 no switchport ip address x.x.x.x 255.255.255.0 ip router isis isis password xxxxxxx OSPF Example: interface GigabitEthernet0/0 no switchport ip address x.x.x.x 255.255.255.0 ip ospf authentication-key xxxxx If authentication is not enabled on all routing protocols, this is a finding.
Configure authentication to be enabled for every protocol that affects the routing or forwarding tables. The example configuration commands below enables OSPF, EIGRP, IS-IS, and BGP authentication. BGP Example: SW1(config)#router bgp nn SW1(config-switch)#neighbor x.x.x.x password xxxxxx EIGRP Example: SW1(config)#key chain EIGRP_KEY SW1(config-keychain)#key 1 SW1(config-keychain-key)#key-string xxxxx SW1(config-keychain-key)#exit SW1(config-keychain)#exit SW1(config)#int g0/0 SW1(config-if)#ip authentication mode eigrp 1 md5 SW1(config-if)#ip authentication key-chain eigrp 1 EIGRP_KEY SW1(config-if)#end IS-IS Example: SW1(config)#int g0/0 SW1(config-if)#isis password xxxxxx OSPF Example: SW1(config)#int g0/0 SW1(config-if)#ip ospf authentication-key xxxxx SW1(config-if)#end
Review the start times for each key within the configured key chains used for routing protocol authentication as shown in the example below: key chain OSPF_KEY_CHAIN key 1 key-string xxxxxxx send-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018 accept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018 key 2 key-string yyyyyyy send-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018 accept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018 Note: Key chains must be configured to authenticate routing protocol messages, as it is the only way to set an expiration. If any key has a lifetime of more than 180 days, this is a finding.
Configure each key used for routing protocol authentication to have a lifetime of no more than 180 days as shown in the example below: SW1(config)#key chain OSPF_KEY_CHAIN SW1(config-keychain)#key 1 SW1(config-keychain-key)#key-string xxxxxx SW1(config-keychain-key)#send-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018 SW1(config-keychain-key)#accept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018 SW1(config-keychain-key)#exit SW1(config-keychain)#key 2 SW1(config-keychain-key)#key-string yyyyyyy SW1(config-keychain-key)#send-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018 SW1(config-keychain-key)#accept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018 SW1(config-keychain-key)#end
Review the switch configuration. For every routing protocol that affects the routing or forwarding tables, verify that the switch is encrypting the authentication key as shown in the examples below: BGP Example: router bgp nn no synchronization bgp log-neighbor-changes neighbor x.x.x.x remote-as nn neighbor x.x.x.x password xxxxxxx Note: BGP authentication uses MD5. EIGRP Example: interface GigabitEthernet1/0 no switchport ip address x.x.x.x 255.255.255.0 ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 EIGRP_KEY_CHAIN IS-IS Example: interface GigabitEthernet1/0 no switchport ip address x.x.x.x 255.255.255.0 ip router isis isis authentication mode md5 isis authentication key-chain ISIS_KEY_CHAIN OSPF Example: interface GigabitEthernet1/0 no switchport ip address x.x.x.x 255.255.255.0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 xxxxxx RIP Example: interface GigabitEthernet1/0 no switchport ip rip authentication mode md5 ip rip authentication key-chain RIP_KEY_CHAIN If the routing protocol is not encrypting the authentication key, this is a finding.
Configure all routing protocol authentications to encrypt the authentication key. BGP Example: SW1(config)#router bgp nn SW1(config-switch)#neighbor x.x.x.x password xxxxxx EIGRP Example: SW2(config)#int g0/1 SW2(config-if)#ip authentication mode eigrp 1 md5 SW2(config-if)#ip authentication key-chain eigrp 1 EIGRP_KEY_CHAIN IS-IS Example: SW1(config)#int g0/1 SW1(config-if)#isis authentication mode md5 SW1(config-if)#isis authentication key-chain ISIS_KEY_CHAIN OSPF Example: SW1(config)#int g1/0 SW1(config-if)#ip ospf authentication message-digest SW1(config-if)#ip ospf message-digest-key 1 md5 xxxxxx RIP Example: SW2(config)#int g1/0 SW2(config-if)#ip rip authentication mode md5 SW2(config-if)#ip rip authentication key-chain RIP_KEY_CHAIN
Review the switch configuration to verify it is using a NIST-validated FIPS 198-1 message authentication code algorithm to authenticate routing protocol messages. OSPF Example: key chain OSPF_KEY_CHAIN key 1 key-string xxxxxxx send-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018 accept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018 cryptographic-algorithm hmac-sha-256 key 2 key-string yyyyyyy send-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018 accept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018 cryptographic-algorithm hmac-sha-256 … … … interface GigabitEthernet0/1 no switchport ip address x.x.x.x 255.255.255.0 ip ospf authentication key-chain OSPF_KEY_CHAIN If a NIST-validated FIPS 198-1 message authentication code algorithm is not being used to authenticate routing protocol messages, this is a finding.
Configure routing protocol authentication to use a NIST-validated FIPS 198-1 message authentication code algorithm as shown in the example. SW1(config)#key chain OSPF_KEY_CHAIN SW1(config-keychain)#key 1 SW1(config-keychain-key)#key-string xxxxxx SW1(config-keychain-key)#send-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018 SW1(config-keychain-key)#accept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018 SW1(config-keychain-key)#cryptographic-algorithm hmac-sha-256 SW1(config-keychain-key)#exit SW1(config-keychain)#key 2 SW1(config-keychain-key)#key-string yyyyyyy SW1(config-keychain-key)#send-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018 SW1(config-keychain-key)#accept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018 SW1(config-keychain-key)#cryptographic-algorithm hmac-sha-256 SW1(config-keychain-key)#end SW1(config)#interface GigabitEthernet0/2 SW1(config-if)#ip ospf authentication key-chain OSPF_KEY_CHAIN
Review the switch configuration and verify that inactive interfaces have been disabled as shown below: interface GigabitEthernet3 no switchport shutdown ! interface GigabitEthernet4 no switchport shutdown If an interface is not being used but is configured or enabled, this is a finding.
Disable all inactive interfaces as shown below: SW1(config)#interface GigabitEthernet3 SW1(config-if)#shutdown SW1(config)#interface GigabitEthernet4 SW1(config-if)#shutdown
Review the switch configuration to determine if the call home service is enabled as shown in the example below: call-home contact-email-addr username@example.com phone-number "+1-800-555-4567" customer-id "Customer1234" contract-id "Company1234" If the call home feature is configured to call home to the vendor, this is a finding.
Disable the call home feature as shown below: SW1(config)#no call-home
Review the device configuration to determine if auto-configuration or zero-touch deployment via Cisco Networking Services (CNS) is enabled. Auto-Configuration Example: version 15.0 service config … … … boot-start-marker boot network tftp://x.x.x.x/R5-config boot-end-marker CNS Zero-Touch Example: cns trusted-server config x.x.x.x cns trusted-server image x.x.x.x cns config initial x.x.x.x 80 cns exec 80 cns image If a configuration auto-loading feature or zero-touch deployment feature is enabled, this is a finding. Note: Auto-configuration or zero-touch deployment features can be enabled when the switch is offline for the purpose of image loading or building out the configuration. In addition, this would not be applicable to the provisioning of virtual switches via a software-defined network (SDN) orchestration system.
Disable configuration auto-loading if enabled using the following commands: SW1(config)#no boot network SW1(config)#no service config Disable CNS zero-touch deployment if enabled as shown in the example below: SW2(config)#no cns config initial SW2(config)#no cns exec SW2(config)#no cns image SW2(config)#no cns trusted-server config x.x.x.x SW2(config)#no cns trusted-server image x.x.x.x
Review the Cisco switch configuration to verify that it is compliant with this requirement. Step 1: Verify traffic types have been classified based on importance levels. The following is an example configuration: class-map match-all CoPP_CRITICAL match access-group name CoPP_CRITICAL class-map match-any CoPP_IMPORTANT match access-group name CoPP_IMPORTANT match protocol arp class-map match-all CoPP_NORMAL match access-group name CoPP_NORMAL class-map match-any CoPP_UNDESIRABLE match access-group name CoPP_UNDESIRABLE class-map match-all CoPP_DEFAULT match access-group name CoPP_DEFAULT Step 2: Review the ACLs referenced by the class maps to determine if the traffic is being classified appropriately. The following is an example configuration: ip access-list extended CoPP_CRITICAL remark our control plane adjacencies are critical permit ospf host [OSPF neighbor A] any permit ospf host [OSPF neighbor B] any permit pim host [PIM neighbor A] any permit pim host [PIM neighbor B] any permit pim host [RP addr] any permit igmp any 224.0.0.0 15.255.255.255 permit tcp host [BGP neighbor] eq bgp host [local BGP addr] permit tcp host [BGP neighbor] host [local BGP addr] eq bgp deny ip any any ip access-list extended CoPP_IMPORTANT permit tcp host [TACACS server] eq tacacs any permit tcp [management subnet] 0.0.0.255 any eq 22 permit udp host [SNMP manager] any eq snmp permit udp host [NTP server] eq ntp any deny ip any any ip access-list extended CoPP_NORMAL remark we will want to rate limit ICMP traffic permit icmp any any echo permit icmp any any echo-reply permit icmp any any time-exceeded permit icmp any any unreachable deny ip any any ip access-list extended CoPP_UNDESIRABLE remark other management plane traffic that should not be received permit udp any any eq ntp permit udp any any eq snmp permit tcp any any eq 22 permit tcp any any eq 23 remark other control plane traffic not configured on switch permit eigrp any any permit udp any any eq rip deny ip any any ip access-list extended CoPP_DEFAULT permit ip any any Note: Explicitly defining undesirable traffic with ACL entries enables the network operator to collect statistics. Excessive ARP packets can potentially monopolize Route Processor resources, starving other important processes. Currently, ARP is the only Layer 2 protocol that can be specifically classified using the match protocol command. Step 3: Review the policy-map to determine if the traffic is being policed appropriately for each classification. The following is an example configuration: policy-map CONTROL_PLANE_POLICY class CoPP_CRITICAL police 512000 8000 conform-action transmit exceed-action transmit class CoPP_IMPORTANT police 256000 4000 conform-action transmit exceed-action drop class CoPP_NORMAL police 128000 2000 conform-action transmit exceed-action drop class CoPP_UNDESIRABLE police 8000 1000 conform-action drop exceed-action drop class CoPP_DEFAULT police 64000 1000 conform-action transmit exceed-action drop Step 4: Verify that the CoPP policy is enabled. The following is an example configuration: control-plane service-policy input CONTROL_PLANE_POLICY Note: Control Plane Protection (CPPr) can be used to filter as well as police control plane traffic destined to the RP. CPPr is very similar to CoPP and has the ability to filter and police traffic using finer granularity by dividing the aggregate control plane into three separate categories: (1) host, (2) transit, and (3) CEF-exception. Hence, a separate policy-map could be configured for each traffic category. If the Cisco switch is not configured to protect against known types of DoS attacks by employing organization-defined security safeguards, this is a finding.
Configure the Cisco switch protect against known types of DoS attacks on the route processor. Implementing a CoPP policy as shown in the example below is a best practice method. Step 1: Configure ACLs specific traffic types. SW1(config)#ip access-list extended CoPP_CRITICAL SW1(config-ext-nacl)#remark our control plane adjacencies are critical SW1(config-ext-nacl)#permit ospf host x.x.x.x any SW1(config-ext-nacl)#permit ospf host x.x.x.x any SW1(config-ext-nacl)#permit pim host x.x.x.x any SW1(config-ext-nacl)#permit pim host x.x.x.x any SW1(config-ext-nacl)#permit igmp any 224.0.0.0 15.255.255.255 SW1(config-ext-nacl)#permit tcp host x.x.x.x eq bgp host x.x.x.x SW1(config-ext-nacl)#deny ip any any SW1(config-ext-nacl)#exit SW1(config)#ip access-list extended CoPP_IMPORTANT SW1(config-ext-nacl)#permit tcp host x.x.x.x eq tacacs any SW1(config-ext-nacl)#permit tcp x.x.x.x 0.0.0.255 any eq 22 SW1(config-ext-nacl)#permit udp host x.x.x.x any eq snmp SW1(config-ext-nacl)#permit udp host x.x.x.x eq ntp any SW1(config-ext-nacl)#deny ip any any SW1(config-ext-nacl)#exit SW1(config)#ip access-list extended CoPP_NORMAL SW1(config-ext-nacl)#remark we will want to rate limit ICMP traffic SW1(config-ext-nacl)#permit icmp any any echo SW1(config-ext-nacl)#permit icmp any any echo-reply SW1(config-ext-nacl)#permit icmp any any time-exceeded SW1(config-ext-nacl)#permit icmp any any unreachable SW1(config-ext-nacl)#deny ip any any SW1(config-ext-nacl)#exit SW1(config)#ip access-list extended CoPP_UNDESIRABLE SW1(config-ext-nacl)#remark management plane traffic that should not be received SW1(config-ext-nacl)#permit udp any any eq ntp SW1(config-ext-nacl)#permit udp any any eq snmp SW1(config-ext-nacl)#permit tcp any any eq 22 SW1(config-ext-nacl)#permit tcp any any eq 23 SW1(config-ext-nacl)#remark control plane traffic not configured on switch SW1(config-ext-nacl)#permit eigrp any any SW1(config-ext-nacl)#permit udp any any eq rip SW1(config-ext-nacl)#deny ip any any SW1(config-ext-nacl)#exit SW1(config)#ip access-list extended CoPP_DEFAULT SW1(config-ext-nacl)#permit ip any any SW1(config-ext-nacl)#exit Step 2: Configure class maps referencing each of the ACLs. SW1(config)#class-map match-all CoPP_CRITICAL SW1(config-cmap)#match access-group name CoPP_CRITICAL SW1(config-cmap)#class-map match-any CoPP_IMPORTANT SW1(config-cmap)#match access-group name CoPP_IMPORTANT SW1(config-cmap)#match protocol arp SW1(config-cmap)#class-map match-all CoPP_NORMAL SW1(config-cmap)#match access-group name CoPP_NORMAL SW1(config-cmap)#class-map match-any CoPP_UNDESIRABLE SW1(config-cmap)#match access-group name CoPP_UNDESIRABLE SW1(config-cmap)#class-map match-all CoPP_DEFAULT SW1(config-cmap)#match access-group name CoPP_DEFAULT SW1(config-cmap)#exit Step 3: Configure a policy map referencing the configured class maps and apply appropriate bandwidth allowance and policing attributes. SW1(config)#policy-map CONTROL_PLANE_POLICY SW1(config-pmap)#class CoPP_CRITICAL SW1(config-pmap-c)#police 512000 8000 conform-action transmit exceed-action transmit SW1(config-pmap-c-police)#class CoPP_IMPORTANT SW1(config-pmap-c)#police 256000 4000 conform-action transmit exceed-action drop SW1(config-pmap-c-police)#class CoPP_NORMAL SW1(config-pmap-c)#police 128000 2000 conform-action transmit exceed-action drop SW1(config-pmap-c-police)#class CoPP_UNDESIRABLE SW1(config-pmap-c)#police 8000 1000 conform-action drop exceed-action drop SW1(config-pmap-c-police)#class CoPP_DEFAULT SW1(config-pmap-c)#police 64000 1000 conform-action transmit exceed-action drop SW1(config-pmap-c-police)#exit SW1(config-pmap-c)#exit SW1(config-pmap)#exit Step 4: Apply the policy map to the control plane. SW1(config)#control-plane SW1(config-cp)#service-policy input CONTROL_PLANE_POLICY SW1(config-cp)#end
Review the external and internal ACLs to verify that the switch is configured to only allow specific management and control plane traffic from specific sources destined to itself. Step 1: Verify ACLs has been configured as shown in the example below that matches expected control plane and management plane traffic. With the exception of Internet Control Message Protocol (ICMP), all other traffic destined to the switch should be dropped. ip access-list extended EXTERNAL_ACL permit tcp host x.11.1.1 eq bgp host x.11.1.2 permit tcp host x.11.1.1 host x.11.1.2 eq bgp permit icmp host x.11.1.1 host x.11.1.2 echo permit icmp host x.11.1.1 host x.11.1.2 echo-reply deny ip any host x.11.1.1 log-input permit … … … … deny ip any any log-input ip access-list extended INTERNAL_ACL permit icmp any any permit ospf host 10.1.12.1 host 10.1.12.2 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq 22 permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq tacacs permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp deny ip any host 10.1.12.2 log-input permit … … … … deny ip any any log-input Note: For the internal ACL example, all switches within the hypothetical network (10.1.0.0/16) have been configured to use the loopback address to source all management traffic (not shown); hence, the loopbacks are the only allowable destination address for management traffic. In addition, all management traffic destined to the switch must originate from the management network (10.2.1.0/24). With the exception of link-local control plane traffic and ICMP, all other traffic destined to any physical interface address will be dropped. Step 2: Verify that the ACL has been applied to the appropriate interface as shown in the example below: interface GigabitEthernet0/2 no switchport ip address x.11.1.2 255.255.255.254 ip access-group EXTERNAL_ACL in interface GigabitEthernet0/3 no switchport ip address 10.1.12.2 255.255.255.0 ip access-group INTERNAL_ACL in If the switch is not configured to restrict traffic destined to itself, this is a finding.
Step 1: Configure the ACL for any external interfaces as shown in the example below: SW1(config)#ip access-list extended EXTERNAL_ACL SW1(config-ext-nacl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2 SW1(config-ext-nacl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp SW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo SW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply SW1(config-ext-nacl)#deny ip any host x.11.1.1 log-input SW1(config-ext-nacl)#permit … … … … SW1(config-ext-nacl)#deny ip any any log-input Step 2: Configure the ACL for any external interfaces as shown in the example below: SW1(config)#ip access-list extended INTERNAL_ACL SW1(config-ext-nacl)#permit ospf host 10.1.12.1 host 10.1.12.2 SW1(config-ext-nacl)#permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq 22 SW1(config-ext-nacl)#permit tcp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq tacacs SW1(config-ext-nacl)#permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq snmp SW1(config-ext-nacl)#permit udp 10.2.1.0 0.0.0.255 host 10.1.12.2 eq ntp SW1(config-ext-nacl)#deny ip any host 10.1.12.2 log-input SW1(config-ext-nacl)#permit … … … … SW1(config-ext-nacl)#permit ip any any log-input SW1(config-ext-nacl)#exit Note: Best practice is to configure the ACL statements relative to traffic destined to the switch first followed by ACL statements for transit traffic. Step 3: Apply the ACLs to the appropriate interface as shown in the example below: SW1(config)#int g0/2 SW1(config-if)#ip access-group EXTERNAL_ACL in SW1(config)#int g0/3 SW1(config-if)#ip access-group INTERNAL_ACL in
Review the external and internal ACLs to verify that the switch is configured drop all fragmented ICMP packets destined to itself. ip access-list extended EXTERNAL_ACL permit tcp host x.11.1.1 eq bgp host x.11.1.2 permit tcp host x.11.1.1 host x.11.1.2 eq bgp deny icmp any host x.11.1.2 fragments permit icmp host x.11.1.1 host x.11.1.2 echo … … deny ip any any ! ip access-list extended INTERNAL_ACL deny icmp any host 10.1.12.2 fragments permit icmp any any Note: Ensure the statement to deny ICMP fragments is before any permit statements for ICMP. If the switch is not configured to drop all fragmented ICMP packets destined to itself, this is a finding.
Configure the external and internal ACLs to drop all fragmented ICMP packets destined to itself as shown in the example below: SW1(config)#ip access-list extended EXTERNAL_ACL SW1(config-ext-nacl)#deny icmp any host x.11.1.2 fragments SW1(config)#ip access-list extended INTERNAL_ACL SW1(config-ext-nacl)#deny icmp any host 10.1.12.2 fragments Note: Ensure the above statement is before any permit statements for ICMP.
Review the configuration to determine if gratuitous ARP is disabled. The following command should not be found in the switch configuration: ip gratuitous-arps Note: With Cisco IOS, Gratuitous ARP is enabled and disabled globally. If gratuitous ARP is enabled on any external interface, this is a finding.
Disable gratuitous ARP as shown in the example below: SW1(config)#no ip gratuitous-arps
Review the switch configuration to determine if it is compliant with this requirement. IP directed broadcast command must not be found on any interface as shown in the example below: interface GigabitEthernet0/1 no switchport ip address x.x.x.x 255.255.255.0 ip directed-broadcast … … … Interface Vlan11 no switchport ip address x.x.x.x 255.255.255.0 ip directed-broadcast If IP directed broadcast is not disabled on all interfaces, this is a finding.
Disable IP directed broadcast on all interfaces as shown in the example below: SW1(config)#int g0/1 SW1(config-if)#no ip directed-broadcast SW1(config)#int vlan11 SW1(config-if)#no ip directed-broadcast
Review the configuration to verify the no ip unreachables command has been configured on all external interfaces as shown in the configuration example below: interface GigabitEthernet0/1 ip address x.x.x.x 255.255.255.0 no ip unreachables If ICMP unreachable notifications are sent from any external or null0 interface, this is a finding. Alternative – DODIN Backbone: Verify that the PE switch is configured to rate limit ICMP unreachable messages as shown in the example below: ip icmp rate-limit unreachable 60000 ip icmp rate-limit unreachable DF 1000 Note: In the example above, packet-too-big message (ICMP Type 3 Code 4) can be sent once every second, while all other destination unreachable messages can be sent once every minute. This will avoid disrupting Path MTU Discovery for traffic traversing the backbone while mitigating the risk of an ICMP unreachable DoS attack. If the PE switch is not configured to rate limit ICMP unreachable messages, this is a finding.
Step 1: Disable ip unreachables on all external interfaces. SW1(config)#int g0/1 SW1(config-if)#no ip unreachables Step 2: Disable ip unreachables on the Null0 interface if it is used to backhole packets. SW1(config-if)#int null 0 SW1(config-if)#no ip unreachables Alternative – DODIN Backbone: Configure the PE switch to rate limit ICMP unreachable messages as shown in the example below: SW1(config)#ip icmp rate-limit unreachable df 100 SW1(config)#ip icmp rate-limit unreachable 100000 SW1(config)#end Alternative – Non DODIN Backbone. An alternative for non-backbone networks (i.e. enclave, base, camp, etc.) is to filter messages generated by the switch and silently drop ICMP Administratively Prohibited and Host Unreachable messages using the following configuration steps: Step 1: Configure ACL to include ICMP Type 3 Code 1 (Host Unreachable) and Code 13 (Administratively Prohibited) as shown in the example below: SW1(config)#ip access-list ext ICMP_T3C1C13 SW1(config-ext-nacl)#permit icmp any any host-unreachable SW1(config-ext-nacl)#permit icmp any any administratively-prohibited SW1(config-ext-nacl)#exit Step 2: Create a route map to forward these ICMP messages to the Null0 interface. SW1(config)#route-map LOCAL_POLICY SW1(config-route-map)#match ip address ICMP_T3C1C13 SW1(config-route-map)#set interface Null0 SW1(config-route-map)#exit Step 3: Configure no ip unreachables on the Null0 interface. SW1(config)#int null 0 SW1(config-if)#no ip unreachables SW1(config-if)#exit Step 4: Apply the policy to filter messages generated by the switch. SW1(config)#ip local policy route-map LOCAL_POLICY SW1(config)#end
Review the switch configuration and verify that ip mask-reply command is not enabled on any external interfaces as shown in the example below: interface GigabitEthernet0/1 ip address x.x.x.x 255.255.255.0 ip mask-reply If the ip mask-reply command is configured on any external interface, this is a finding.
Disable ip mask-reply on all external interfaces as shown below: SW1(config)#int g0/1 SW1(config-if)#no ip mask-reply
Review the switch configuration to verify that the no ip redirects command has been configured on all external interfaces as shown in the example below: interface GigabitEthernet0/1 ip address x.x.x.x 255.255.255.0 no ip redirects If ICMP Redirect messages are enabled on any external interfaces, this is a finding.
Disable ICMP redirects on all external interfaces as shown in the example below: SW1(config)#int g0/1 SW1(config-if)#no ip redirects
Review all ACLs used to filter traffic and verify that packets being dropped at interfaces via an ACL are logged as shown in the configuration below: ip access-list extended INGRESS_FILTER permit tcp any any established permit tcp host x.11.1.1 eq bgp host x.11.1.2 permit tcp host x.11.1.1 host x.11.1.2 eq bgp permit tcp any host x.11.1.5 eq www permit icmp host x.11.1.1 host x.11.1.2 echo permit icmp any any echo-reply … … … deny ip any any log If packets being dropped are not logged, this is a finding.
Configure ACLs to log packets that are dropped as shown in the example below: SW1(config)#ip access-list extended INGRESS_FILTER … … … SW1(config-ext-nacl)#deny ip any any log
Review the switch configuration to verify that events are logged containing information to establish where the events occurred as shown in the example below: ip access-list extended INGRESS_FILTER permit tcp any any established permit tcp host x.11.1.1 eq bgp host x.11.1.2 permit tcp host x.11.1.1 host x.11.1.2 eq bgp permit tcp any host x.11.1.5 eq www permit icmp host x.11.1.1 host x.11.1.2 echo permit icmp any any echo-reply … … … deny ip any any log-input Note: When the log-input parameter is configured on deny statements, the log record will contain the interface where ingress packet has been dropped. If the switch is not configured to produce audit records containing information to establish to establish where the events occurred, this is a finding.
Configure the switch to log events containing information to establish where the events occurred as shown in the example below: SW1(config)#ip access-list extended INGRESS_FILTER … … … SW1(config-ext-nacl)#deny ip any any log-input
Review the switch configuration to verify that events are logged containing information to establish the source of the events as shown in the example below: ip access-list extended INGRESS_FILTER permit tcp any any established permit tcp host x.11.1.1 eq bgp host x.11.1.2 permit tcp host x.11.1.1 host x.11.1.2 eq bgp permit tcp any host x.11.1.5 eq www permit icmp host x.11.1.1 host x.11.1.2 echo permit icmp any any echo-reply … … … deny ip any any log-input Note: When the log-input parameter is configured on deny statements, the log record will contain the layer 2 address of the forwarding device for any packet being dropped. If the switch is not configured to produce audit records containing information to establish the source of the events, this is a finding.
Configure the switch to log events containing information to establish where the events occurred as shown in the example below: SW1(config)#ip access-list extended INGRESS_FILTER … … … SW1(config-ext-nacl)#deny ip any any log-input
Review the configuration and verify that the auxiliary port is disabled unless a secured modem providing encryption and authentication is connected to it. line aux 0 no exec Note: Transport input none is the default; hence it will not be shown in the configuration. If the auxiliary port is not disabled or is not connected to a secured modem when it is enabled, this is a finding.
Disable the auxiliary port. SW2(config)#line aux 0 SW2(config-line)#no exec SW2(config-line)#transport input none
Review the switch configuration to verify that the inbound ACL applied to all external interfaces is configured to allow specific ports and protocols and deny all other traffic. Step 1: Verify that an inbound ACL is applied to all external interfaces as shown in the example below: interface GigabitEthernet0/2 ip address x.11.1.2 255.255.255.254 ip access-group EXTERNAL_ACL in Step 2: Review inbound ACL to verify that it is configured to deny all other traffic that is not explicitly allowed. ip access-list extended EXTERNAL_ACL permit tcp any any established permit tcp host x.11.1.1 eq bgp host x.11.1.2 permit tcp host x.11.1.1 host x.11.1.2 eq bgp permit icmp host x.11.1.1 host x.11.1.2 echo permit icmp host x.11.1.1 host x.11.1.2 echo-reply … … … deny ip any any log-input If the ACL is not configured to allow specific ports and protocols and deny all other traffic, this is a finding. If the ACL is not configured inbound on all external interfaces, this is a finding.
Step 1: Configure an inbound ACL to deny all other traffic by default as shown in the example below: SW1(config)#ip access-list extended EXTERNAL_ACL SW1(config-ext-nacl)#permit tcp any any established SW1(config-ext-nacl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2 SW1(config-ext-nacl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp SW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo SW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply … … … SW1(config-ext-nacl)#deny ip any any log-input Step 2: Apply the ingress filter to all external interfaces. SW1(config)#int g0/2 SW1(config-if)#ip access-group EXTERNAL_ACL in
Review the switch configuration to verify that ACLs are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. In the example below, the switch is peering BGP with DISN. ICMP echo and echo-reply packets are allowed for troubleshooting connectivity. WWW traffic is permitted inbound to the NIPRNet host-facing web server (x.12.1.22). interface GigabitEthernet0/1 description Link to DISN ip address x.12.1.10 255.255.255.0 ip access-group FILTER_PERIMETER in … … … ip access-list extended FILTER_PERIMETER permit tcp any any established permit tcp host x.12.1.9 host x.12.1.10 eq bgp permit tcp host x.12.1.9 eq bgp host x.12.1.10 permit icmp host x.12.1.9 host x.12.1.10 echo permit icmp host x.12.1.9 host x.12.1.10 echo-reply permit tcp any host x.12.1.22 eq www deny ip any any log-input If the switch is not configured to enforce approved authorizations for controlling the flow of information between interconnected networks, this is a finding.
Step 1: Configure an ACL to allow or deny traffic as shown in the example below: SW1(config)#ip access-list extended FILTER_PERIMETER SW1(config-ext-nacl)#permit tcp any any established SW1(config-ext-nacl)#permit tcp host x.12.1.9 host x.12.1.10 eq bgp SW1(config-ext-nacl)#permit tcp host x.12.1.9 eq bgp host x.12.1.10 SW1(config-ext-nacl)#permit icmp host x.12.1.9 host x.12.1.10 echo SW1(config-ext-nacl)#permit icmp host x.12.1.9 host x.12.1.10 echo-reply SW1(config-ext-nacl)#permit tcp any host x.12.1.22 eq www SW1(config-ext-nacl)#deny ip any any log-input SW1(config-ext-nacl)#exit Step 2: Apply the ACL inbound on all external interfaces. R2(config)#int g0/0 SW1(config-if)#ip access-group FILTER_PERIMETER in
Review the switch configuration to determine if the switch allows only incoming communications from authorized sources to be routed to authorized destinations. The hypothetical example below allows inbound NTP from server x.1.12.9 only to host x.12.1.21. ip access-list extended FILTER_PERIMETER permit tcp any any established … … … permit udp host x.12.1.9 host x.12.1.21 eq ntp deny ip any any log-input If the switch does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.
Configure the switch to allow only incoming communications from authorized sources to be routed to authorized destinations. SW1(config)#ip access-list extended FILTER_PERIMETER SW1(config-ext-nacl)#permit tcp any any established … … … SW1(config-ext-nacl)#permit udp host x.12.1.9 host x.12.1.21 eq ntp SW1(config-ext-nacl)#deny ip any any log-input SW1(config-ext-nacl)#end
Review the switch configuration to verify that an ingress ACL applied to all external interfaces is blocking packets with Bogon source addresses. Step 1: Verify an ACL has been configured containing the current Bogon prefixes as shown in the example below: ip access-list extended FILTER_PERIMETER deny ip 0.0.0.0 0.255.255.255 any log-input deny ip 10.0.0.0 0.255.255.255 any log-input deny ip 100.64.0.0 0.63.255.255 any log-input deny ip 127.0.0.0 0.255.255.255 any log-input deny ip 169.254.0.0 0.0.255.255 any log-input deny ip 172.16.0.0 0.15.255.255 any log-input deny ip 192.0.0.0 0.0.0.255 any log-input deny ip 192.0.2.0 0.0.0.255 any log-input deny ip 192.168.0.0 0.0.255.255 any log-input deny ip 198.18.0.0 0.1.255.255 any log-input deny ip 198.51.100.0 0.0.0.255 any log-input deny ip 203.0.113.0 0.0.0.255 any log-input deny ip 224.0.0.0 31.255.255.255 any log-input deny ip 240.0.0.0 15.255.255.255 any log-input permit tcp any any established permit tcp host x.12.1.9 host x.12.1.10 eq bgp permit tcp host x.12.1.9 eq bgp host x.12.1.10 permit icmp host x.12.1.9 host x.12.1.10 echo permit icmp host x.12.1.9 host x.12.1.10 echo-reply … … … deny ip any any log-input Step 2: Verify that the inbound ACL applied to all external interfaces will block all traffic from Bogon source addresses. interface GigabitEthernet0/1 description Link to DISN ip address x.12.1.10 255.255.255.254 ip access-group FILTER_PERIMETER in If the switch is not configured to block inbound packets with source Bogon IP address prefixes, this is a finding.
Configure the perimeter to block inbound packets with Bogon source addresses. Step 1: Configure an ACL containing the current Bogon prefixes as shown below: SW1(config)#ip access-list extended FILTER_PERIMETER SW1(config-ext-nacl)#deny ip 0.0.0.0 0.255.255.255 any log-input SW1(config-ext-nacl)#deny ip 10.0.0.0 0.255.255.255 any log-input SW1(config-ext-nacl)#deny ip 100.64.0.0 0.63.255.255 any log-input SW1(config-ext-nacl)#deny ip 127.0.0.0 0.255.255.255 any log-input SW1(config-ext-nacl)#deny ip 169.254.0.0 0.0.255.255 any log-input SW1(config-ext-nacl)#deny ip 172.16.0.0 0.15.255.255 any log-input SW1(config-ext-nacl)#deny ip 192.0.0.0 0.0.0.255 any log-input SW1(config-ext-nacl)#deny ip 192.0.2.0 0.0.0.255 any log-input SW1(config-ext-nacl)#deny ip 192.168.0.0 0.0.255.255 any log-input SW1(config-ext-nacl)#deny ip 198.18.0.0 0.1.255.255 any log-input SW1(config-ext-nacl)#deny ip 198.51.100.0 0.0.0.255 any log-input SW1(config-ext-nacl)#deny ip 203.0.113.0 0.0.0.255 any log-input SW1(config-ext-nacl)#deny ip 224.0.0.0 31.255.255.255 any log-input SW1(config-ext-nacl)#deny ip 240.0.0.0 15.255.255.255 any log-input SW1(config-ext-nacl)#permit tcp any any established SW1(config-ext-nacl)#permit tcp host x.12.1.9 host x.12.1.10 eq bgp SW1(config-ext-nacl)#permit tcp host x.12.1.9 eq bgp host x.12.1.10 SW1(config-ext-nacl)#permit icmp host x.12.1.9 host x.12.1.10 echo SW1(config-ext-nacl)#permit icmp host x.12.1.9 host x.12.1.10 echo-reply … … … SW1(config-ext-nacl)#deny ip any any log-input SW1(config-ext-nacl)#end Step 2: Apply the ACL inbound on all external interfaces. SW1(config)#int g0/0 SW1(config-if)#ip access-group FILTER_PERIMETER in SW1(config-if)#end
Review the switch configuration to verify uRPF or an egress ACL has been configured on all internal interfaces to restrict the switch from accepting outbound IP packets that contain an illegitimate address in the source address field. uRPF example: interface GigabitEthernet0/1 description downstream link to LAN ip address 10.1.25.5 255.255.255.0 ip verify unicast source reachable-via rx Egress ACL example: interface GigabitEthernet0/1 description downstream link to LAN ip address 10.1.25.5 255.255.255.0 ip access-group EGRESS_FILTER in … … … ip access-list extended EGRESS_FILTER permit udp 10.1.15.0 0.0.0.255 any eq domain permit tcp 10.1.15.0 0.0.0.255 any eq ftp permit tcp 10.1.15.0 0.0.0.255 any eq ftp-data permit tcp 10.1.15.0 0.0.0.255 any eq www permit icmp 10.1.15.0 0.0.0.255 any permit icmp 10.1.15.0 0.0.0.255 any echo deny ip any any If uRPF or an egress ACL to restrict the switch from accepting outbound IP packets that contain an illegitimate address in the source address field has not been configured on all internal interfaces in an enclave, this is a finding.
Configure the switch to ensure that an egress ACL or uRPF is configured on internal interfaces to restrict the switch from accepting any outbound IP packet that contains an illegitimate address in the source field. The example below enables uRPF. SW1(config)#int g0/1 SW1(config-if)#ip verify unicast source reachable-via rx
Review the switch configuration to verify that the ingress ACL is in accordance with DoD 8551.1. Step 1: Verify that an inbound ACL is configured on all external interfaces. interface GigabitEthernet0/2 ip address x.11.1.2 255.255.255.254 ip access-group EXTERNAL_ACL_INBOUND in Step 2. Review the inbound ACL to verify that it is filtering traffic in accordance with DoD 8551.1. ip access-list extended EXTERNAL_ACL_INBOUND permit tcp any any established permit tcp host x.11.1.1 eq bgp host x.11.1.2 permit tcp host x.11.1.1 host x.11.1.2 eq bgp permit icmp host x.11.1.1 host x.11.1.2 echo permit icmp host x.11.1.1 host x.11.1.2 echo-reply … … < must be in accordance with DoD Instruction 8551.1> … deny ip any any log-input If the switch does not filter traffic in accordance with the guidelines contained in DoD 8551.1, this is a finding.
Configure the switch to use an inbound ACL on all external interfaces as shown in the example below to restrict traffic in accordance with the guidelines contained in DOD Instruction 8551.1. SW1(config)#ip access-list extended EXTERNAL_ACL_INBOUND SW1(config-ext-nacl)#permit tcp any any established SW1(config-ext-nacl)#permit tcp host x.11.1.1 eq bgp host x.11.1.2 SW1(config-ext-nacl)#permit tcp host x.11.1.1 host x.11.1.2 eq bgp SW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo SW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply … … < must be in accordance with DoD Instruction 8551.1> … SW1(config-ext-nacl)#deny ip any any log-input SW1(config-ext-nacl)#exit SW1(config)#int g0/2 SW1(config-if)#ip access-group EXTERNAL_ACL_INBOUND in
Review the switch configuration to verify that an inbound ACL is configured on all external interfaces as shown in the example below: interface GigabitEthernet0/2 ip address x.11.1.2 255.255.255.254 ip access-group EXTERNAL_ACL_INBOUND in If the switch is not configured to filter traffic entering the network at all external interfaces in an inbound direction, this is a finding.
Configure the switch to use an inbound ACL on all external interfaces as shown in the example below: SW1(config)#int g0/2 SW1(config-if)#ip access-group EXTERNAL_ACL_INBOUND in
Review the switch configuration to verify that the egress ACL is bound to the internal interface in an inbound direction. interface interface GigabitEthernet0/2 description downstream link to LAN ip address 10.1.25.5 255.255.255.0 ip access-group EGRESS_FILTER in If the switch is not configured to filter traffic leaving the network at the internal interface in an inbound direction, this is a finding.
Configure the switch to use an inbound ACL on all internal interfaces as shown in the example below: SW1(config)#int g0/2 SW1(config-if)#ip access-group EGRESS_FILTER in
Review the switch configuration to determine if it will block all packets with IP options. ip access-list extended EXTERNAL_ACL permit tcp any any established deny ip any any option any-options permit … … … … deny ip any any log-input If the switch is not configured to drop all packets with IP options, this is a finding.
Configure the switch to drop all packets with IP options. SW1(config)#ip access-list extended EXTERNAL_ACL SW1(config-ext-nacl)#15 deny ip any any option any-options
Step 1: Verify LLDP is not enabled globally via the command. lldp run By default LLDP is not enabled globally. If LLDP is enabled, proceed to Step 2. Step 2: Verify LLDP is not enabled on any external interface as shown in the example below: interface GigabitEthernet0/1 ip address x.1.12.1 255.255.255.252 no lldp transmit Note: LLDP is enabled by default on all interfaces once it is enabled globally; hence the command "lldp transmit" will not be visible on the interface configuration. If LLDP transmit is enabled on any external interface, this is a finding.
Disable LLDP transmit on all external interfaces as shown in the example below: SW1(config)#int g0/1 SW1(config-if)#no lldp transmit
Step 1: Verify if CDP is enabled globally as shown below: cdp run By default, CDP is not enabled globally or on any interface. If CDP is enabled globally, proceed to Step 2. Step 2: Verify CDP is not enabled on any external interface as shown in the example below: interface GigabitEthernet2 ip address z.1.24.4 255.255.255.252 … … … cdp enable If CDP is enabled on any external interface, this is a finding.
Disable CDP on all external interfaces via no cdp enable command or disable CDP globally via no cdp run command.
Review the switch configuration to determine if IP Proxy ARP is disabled on all external interfaces as shown in the example below: interface GigabitEthernet0/1 description link to DISN ip address x.1.12.2 255.255.255.252 no ip proxy-arp Note: By default Proxy ARP is enabled on all interfaces; hence, if enabled, it will not be shown in the configuration. If IP Proxy ARP is enabled on any external interface, this is a finding.
Disable Proxy ARP on all external interfaces as shown in the example below: SW1(config)#int g0/1 SW1(config-if)#no ip proxy-arp
The perimeter switch of the managed network must be configured with an outbound ACL on the egress interface to block all management traffic as shown in the example below: Step 1: Verify that all external interfaces has been configured with an outbound ACL as shown in the example below: interface GigabitEthernet0/2 description link to DISN ip address x.11.1.2 255.255.255.254 ip access-group EXTERNAL_ACL_OUTBOUND out Step 2: Verify that the outbound ACL discards management traffic as shown in the example below: ip access-list extended EXTERNAL_ACL_OUTBOUND deny tcp any any eq tacacs log-input deny tcp any any eq 22 log-input deny udp any any eq snmp log-input deny udp any any eq snmptrap log-input deny udp any any eq syslog log-input permit tcp any any eq www log-input deny ip any any log-input If management traffic is not blocked at the perimeter, this is a finding.
Configure the perimeter switch of the managed network with an outbound ACL on the egress interface to block all management traffic. Step 1: Configure an ACL to block egress management traffic. SW1(config)#ip access-list extended EXTERNAL_ACL_OUTBOUND SW1(config-ext-nacl)#deny tcp any any eq tacacs log-input SW1(config-ext-nacl)#deny tcp any any eq 22 log-input SW1(config-ext-nacl)#deny udp any any eq snmp log-input SW1(config-ext-nacl)#deny udp any any eq snmptrap log-input SW1(config-ext-nacl)#deny udp any any eq syslog log-input SW1(config-ext-nacl)#permit tcp any any eq www SW1(config-ext-nacl)#deny ip any any log-input SW1(config-ext-nacl)#exit Note: Permit commands would be configured to allow applicable outbound traffic. The example above is allowing web traffic. Step 2: Configure the external interfaces with the outbound ACL. SW1(config)#int g0/2 SW1(config-if)#ip access-group EXTERNAL_ACL_OUTBOUND out
This requirement is only applicable where management access to the switch is via an OOBM interface which is not a true OOBM interface. Step 1: Verify that the managed interface has an inbound and outbound ACL configured. interface GigabitEthernet0/7 no switchport description link to OOBM access switch ip address 10.11.1.22 255.255.255.0 ip access-group INGRESS_MANAGEMENT_ACL in ip access-group EGRESS_MANAGEMENT_ACL in Step 2: Verify that the ingress ACL only allows management and ICMP traffic. ip access-list extended INGRESS_MANAGEMENT_ACL permit tcp any host 10.11.1.22 eq tacacs permit tcp any host 10.11.1.22 eq 22 permit udp any host 10.11.1.22 eq snmp permit udp any host 10.11.1.22 eq snmptrap permit udp any host 10.11.1.22 eq ntp permit icmp any host 10.11.1.22 deny ip any any log-input Step 3: Verify that the egress ACL blocks any transit traffic. ip access-list extended EGRESS_MANAGEMENT_ACL deny ip any any log-input Note: On Cisco switches, local generated packets are not inspected by outgoing interface access-lists. Hence, the above configuration would simply drop any packets not generated by the switch; hence, blocking any transit traffic. If the switch does not restrict traffic that ingresses and egresses the management interface, this is a finding.
If the management interface is not a dedicated OOBM interface, it must be configured with both an ingress and egress ACL. Step 1: Configure an ingress ACL a shown in the example below: SW1(config)#ip access-list extended INGRESS_MANAGEMENT_ACL SW1(config-ext-nacl)#permit tcp any host 10.11.1.22 eq tacacs SW1(config-ext-nacl)#permit tcp any host 10.11.1.22 eq 22 SW1(config-ext-nacl)#permit udp any host 10.11.1.22 eq snmp SW1(config-ext-nacl)#permit udp any host 10.11.1.22 eq snmptrap SW1(config-ext-nacl)#permit udp any host 10.11.1.22 eq ntp SW1(config-ext-nacl)#permit icmp any host 10.11.1.22 SW1(config-ext-nacl)#deny ip any any log-input SW1(config-ext-nacl)#exit Step 2: Configure an egress ACL a shown in the example below: SW1(config)#ip access-list extended EGRESS_MANAGEMENT_ACL SW1(config-ext-nacl)#deny ip any any log-input SW1(config-ext-nacl)#exit Step 3: Apply the ACLs to the OOBM interfaces. SW1(config)#int g0/7 SW1(config-if)#ip access-group INGRESS_MANAGEMENT_ACL in SW1(config-if)#ip access-group EGRESS_MANAGEMENT_ACL out
Review the BGP configuration to verify that TTL security has been configured for each external neighbor as shown in the example below: router bgp xx no synchronization bgp log-neighbor-changes neighbor x.1.1.9 remote-as yy neighbor x.1.1.9 password xxxxxxxx neighbor x.1.1.9 ttl-security hops 1 neighbor x.2.1.7 remote-as zz neighbor x.2.1.7 password xxxxxxxx neighbor x.2.1.7 ttl-security hops 1 If the switch is not configured to use GTSM for all Exterior Border Gateway Protocol peering sessions, this is a finding.
Configure TTL security on all external BGP neighbors as shown in the example below: SW1(config)#router bgp xx SW1(config-switch)#neighbor x.1.1.9 ttl-security hops 1 SW1(config-switch)#neighbor x.2.1.7 ttl-security hops 1
Review the BGP configuration to determine if it is peering with multiple autonomous systems. Interview the ISSM and switch administrator to determine if unique keys are being used. router bgp xx no synchronization bgp log-neighbor-changes neighbor x.1.1.9 remote-as yy neighbor x.1.1.9 password yyyyyyyy neighbor x.2.1.7 remote-as zz neighbor x.2.1.7 password zzzzzzzzz If unique keys are not being used, this is a finding.
Configure the switch to use unique keys for each AS that it peers with as shown in the example below: SW1(config)#router bgp xx SW1(config-switch)#neighbor x.1.1.9 password yyyyyyyy SW1(config-switch)#neighbor x.2.1.7 password zzzzzzzzz
Review the switch configuration to verify that it will reject BGP routes for any Bogon prefixes. Step 1: Verify a prefix list has been configured containing the current Bogon prefixes as shown in the example below: ip prefix-list PREFIX_FILTER seq 5 deny 0.0.0.0/8 le 32 ip prefix-list PREFIX_FILTER seq 10 deny 10.0.0.0/8 le 32 ip prefix-list PREFIX_FILTER seq 15 deny 100.64.0.0/10 le 32 ip prefix-list PREFIX_FILTER seq 20 deny 127.0.0.0/8 le 32 ip prefix-list PREFIX_FILTER seq 25 deny 169.254.0.0/16 le 32 ip prefix-list PREFIX_FILTER seq 30 deny 172.16.0.0/12 le 32 ip prefix-list PREFIX_FILTER seq 35 deny 192.0.2.0/24 le 32 ip prefix-list PREFIX_FILTER seq 40 deny 192.88.99.0/24 le 32 ip prefix-list PREFIX_FILTER seq 45 deny 192.168.0.0/16 le 32 ip prefix-list PREFIX_FILTER seq 50 deny 198.18.0.0/15 le 32 ip prefix-list PREFIX_FILTER seq 55 deny 198.51.100.0/24 le 32 ip prefix-list PREFIX_FILTER seq 60 deny 203.0.113.0/24 le 32 ip prefix-list PREFIX_FILTER seq 65 deny 224.0.0.0/4 le 32 ip prefix-list PREFIX_FILTER seq 70 deny 240.0.0.0/4 le 32 ip prefix-list PREFIX_FILTER seq 75 permit 0.0.0.0/0 ge 8 Step 2: Verify that the prefix list has been applied to all external BGP peers as shown in the example below: router bgp xx no synchronization bgp log-neighbor-changes neighbor x.1.1.9 remote-as yy neighbor x.1.1.9 prefix-list PREFIX_FILTER in neighbor x.2.1.7 remote-as zz neighbor x.2.1.7 prefix-list PREFIX_FILTER in Route Map Alternative: Verify that the route map applied to the external neighbors references the configured Bogon prefix list shown above. router bgp xx no synchronization bgp log-neighbor-changes neighbor x.1.1.9 remote-as yy neighbor x.1.1.9 route-map FILTER_PREFIX_MAP neighbor x.2.1.7 remote-as zz neighbor x.2.1.7 route-map FILTER_PREFIX_MAP … route-map FILTER_PREFIX_MAP permit 10 match ip address prefix-list PREFIX_FILTER If the switch is not configured to reject inbound route advertisements for any Bogon prefixes, this is a finding.
Configure the switch to reject inbound route advertisements for any Bogon prefixes. Step 1: Configure a prefix list containing the current Bogon prefixes as shown below: SW1(config)#ip prefix-list PREFIX_FILTER deny 0.0.0.0/8 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 10.0.0.0/8 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 100.64.0.0/10 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 127.0.0.0/8 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 169.254.0.0/16 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 172.16.0.0/12 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 192.0.2.0/24 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 192.88.99.0/24 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 192.168.0.0/16 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 198.18.0.0/15 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 198.51.100.0/24 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 203.0.113.0/24 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 224.0.0.0/4 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 240.0.0.0/4 le 32 SW1(config)#ip prefix-list PREFIX_FILTER deny 240.0.0.0/4 le 32 SW1(config)#ip prefix-list PREFIX_FILTER permit 0.0.0.0/0 ge 8 Step 2: Apply the prefix list filter inbound to each external BGP neighbor as shown in the example: SW1(config)#router bgp xx SW1(config-switch)#neighbor x.1.1.9 prefix-list PREFIX_FILTER in SW1(config-switch)#neighbor x.2.1.7 prefix-list PREFIX_FILTER in Route Map Alternative: Step 1: Configure the route map referencing the configured prefix list above. SW1(config)#route-map FILTER_PREFIX_MAP 10 SW1(config-route-map)#match ip address prefix-list PREFIX_FILTER SW1(config-route-map)#exit Step 2: Apply the route-map inbound to each external BGP neighbor as shown in the example: SW1(config)#router bgp xx SW1(config-switch)#neighbor x.1.1.9 route-map FILTER_PREFIX_MAP in SW1(config-switch)#neighbor x.2.1.7 route-map FILTER_PREFIX_MAP in SW1(config-switch)#end
Review the switch configuration to verify that it will reject routes belonging to the local AS. Step 1: Verify a prefix list has been configured containing prefixes belonging to the local AS. In the example below x.13.1.0/24 is the global address space allocated to the local AS. ip prefix-list PREFIX_FILTER seq 5 deny 0.0.0.0/8 le 32 … … … ip prefix-list PREFIX_FILTER seq 74 deny x.13.1.0/24 le 32 ip prefix-list PREFIX_FILTER seq 75 permit 0.0.0.0/0 ge 8 Step 2: Verify that the prefix list has been applied to all external BGP peers as shown in the example below: router bgp xx no synchronization bgp log-neighbor-changes neighbor x.1.1.9 remote-as yy neighbor x.1.1.9 prefix-list PREFIX_FILTER in neighbor x.2.1.7 remote-as zz neighbor x.2.1.7 prefix-list PREFIX_FILTER in If the switch is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.
Review the switch configuration to verify that it will reject routes belonging to the local AS. Configure the router to reject inbound route advertisements for any prefixes belonging to the local AS. Step 1: Add to the prefix filter list those prefixes belonging to the local autonomous system. SW1(config)#ip prefix-list PREFIX_FILTER seq 74 deny x.13.1.0/24 le 32 Step 2: If not already completed to be compliant with previous requirement, apply the prefix list filter inbound to each external BGP neighbor as shown in the example. SW1(config)#switch bgp xx SW1(config-switch)#neighbor x.1.1.9 prefix-list PREFIX_FILTER in SW1(config-switch)#neighbor x.2.1.7 prefix-list PREFIX_FILTER in SW1(config-switch)#end
Review the switch configuration to verify that there are ACLs defined to only accept routes for prefixes that belong to specific customers. Step 1: Verify prefix list has been configured for each customer containing prefixes belonging to each customer as shown in the example below: ip prefix-list PREFIX_FILTER_CUST1 seq 5 permit x.13.1.0/24 le 32 ip prefix-list PREFIX_FILTER_CUST1 seq 10 deny 0.0.0.0/0 ge 8 ip prefix-list PREFIX_FILTER_CUST2 seq 5 permit x.13.2.0/24 le 32 ip prefix-list PREFIX_FILTER_CUST2 seq 10 deny 0.0.0.0/0 ge 8 Step 2: Verify that the prefix lists has been applied to all to the applicable CE peers as shown in the example below: router bgp xx no synchronization bgp log-neighbor-changes neighbor x.12.4.14 remote-as 64514 neighbor x.12.4.14 prefix-list FILTER_PREFIXES_CUST1 in neighbor x.12.4.16 remote-as 64516 neighbor x.12.4.16 prefix-list FILTER_PREFIXES_CUST2 in Note: Routes to PE-CE links within a VPN are needed for troubleshooting end-to-end connectivity across the MPLS/IP backbone. Hence, these prefixes are an exception to this requirement. If the switch is not configured to reject inbound route advertisements from each CE switch for prefixes that are not allocated to that customer, this is a finding.
Configure the switch to reject inbound route advertisements from each CE switch for prefixes that are not allocated to that customer. Step 1: Configure a prefix list for each customer containing prefixes belonging to each. SW1(config)#ip prefix-list PREFIX_FILTER_CUST1 permit x.13.1.0/24 le 32 SW1(config)#ip prefix-list PREFIX_FILTER_CUST1 deny 0.0.0.0/0 ge 8 SW1(config)#ip prefix-list PREFIX_FILTER_CUST2 permit x.13.2.0/24 le 32 SW1(config)#ip prefix-list PREFIX_FILTER_CUST2 deny 0.0.0.0/0 ge 8 Step 2: Apply the prefix list filter inbound to each CE neighbor as shown in the example. SW1(config)#router bgp xx SW1(config-switch)#neighbor x.12.4.14 prefix-list FILTER_PREFIXES_CUST1 in SW1(config-switch)#neighbor x.12.4.16 prefix-list FILTER_PREFIXES_CUST2 in
Step 1: Verify that a prefix list has been configured containing prefixes belonging to customers as well as the local AS as shown in the example below: ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 5 permit x.13.1.0/24 le 32 ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 10 permit x.13.2.0/24 le 32 ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 15 permit x.13.3.0/24 le 32 ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 20 permit x.13.4.0/24 le 32 … … … ip prefix-list CE_PREFIX_ADVERTISEMENTS seq 80 deny 0.0.0.0/0 ge 8 Step 2: Verify that the prefix lists has been applied to all CE peers as shown in the example below: router bgp 64512 no synchronization bgp log-neighbor-changes neighbor x.12.4.14 remote-as 64514 neighbor x.12.4.14 prefix-list CE_PREFIX_ADVERTISEMENTS out neighbor x.12.4.16 remote-as 64516 neighbor x.12.4.16 prefix-list CE_PREFIX_ADVERTISEMENTS out If the switch is not configured to reject outbound route advertisements that do not belong to any customers or the local AS, this is a finding.
Step 1: Configure a prefix list for containing all customer and local AS prefixes as shown in the example below: SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS permit x.13.1.0/24 le 32 SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS permit x.13.2.0/24 le 32 SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS permit x.13.3.0/24 le 32 SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS permit x.13.4.0/24 le 32 … … … SW1(config)#ip prefix-list CE_PREFIX_ADVERTISEMENTS deny 0.0.0.0/0 ge 8 Step 2: Apply the prefix list filter outbound to each CE neighbor as shown in the example. SW1(config)#router bgp 64512 SW1(config-switch)#neighbor x.12.4.14 prefix-list CE_PREFIX_ADVERTISEMENTS out SW1(config-switch)#neighbor x.12.4.16 prefix-list CE_PREFIX_ADVERTISEMENTS out
Step 1: Verify that a prefix list has been configured containing prefixes belonging to the IP core. ip prefix-list FILTER_CORE_PREFIXES seq 5 deny x.1.1.0/24 le 32 ip prefix-list FILTER _CORE_PREFIXES seq 10 deny x.1.2.0/24 le 32 ip prefix-list FILTER _CORE_PREFIXES seq 15 permit 0.0.0.0/0 ge 8 Step 2: Verify that the prefix lists has been applied to all external BGP peers as shown in the example below: router bgp xx no synchronization bgp log-neighbor-changes neighbor x.1.4.12 remote-as yy neighbor x.1.4.12 prefix-list FILTER _CORE_PREFIXES out If the switch is not configured to reject outbound route advertisements for prefixes belonging to the IP core, this is a finding.
Step 1: Configure a prefix list for containing all customer and local AS prefixes as shown in the example below: SW1(config)#ip prefix-list FILTER_CORE_PREFIXES deny x.1.1.0/24 le 32 SW1(config)#ip prefix-list FILTER _CORE_PREFIXES deny x.1.2.0/24 le 32 SW1(config)#ip prefix-list FILTER _CORE_PREFIXES permit 0.0.0.0/0 ge 8 Step 2: Apply the prefix list filter outbound to each CE neighbor as shown in the example. SW1(config)#router bgp xx SW1(config-switch)#neighbor x.1.4.12 prefix-list FILTER _CORE_PREFIXES out
Review the switch configuration to verify the switch is configured to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute. By default, Cisco IOS enforces the first AS in the AS_PATH attribute for all route advertisements. Review the switch configuration to verify that the command no bgp enforce-first-as is not configured. router bgp xx no synchronization no bgp enforce-first-as If the switch is not configured to reject updates from peers that do not list their AS number as the first AS in the AS_PATH attribute, this is a finding.
Configure the switch to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute. SW1(config)#router bgp xx SW1(config-switch)#bgp enforce-first-as
Review the switch configuration to verify the switch is configured to deny updates received from CE switches with an originating AS in the AS_PATH attribute that does not belong to that customer. Step 1: Review switch configuration and verify that there is an as-path access-list statement defined to only accept routes from a CE switch whose AS did not originate the route. The configuration should look similar to the following: ip as-path access-list 10 permit ^yy$ ip as-path access-list 10 deny .* Note: The characters “^” and “$” representing the beginning and the end of the expression respectively are optional and are implicitly defined if omitted. Step 2: Verify that the as-path access-list is referenced by the filter-list inbound for the appropriate BGP neighbors as shown in the example below: router bgp xx neighbor x.1.4.12 remote-as yy neighbor x.1.4.12 filter-list 10 in If the switch is not configured to reject updates from CE switches with an originating AS in the AS_PATH attribute that does not belong to that customer, this is a finding.
Configure the switch to reject updates from CE switches with an originating AS in the AS_PATH attribute that does not belong to that customer. Step 1: Configure the as-path ACL as shown in the example below: SW1(config)#ip as-path access-list 10 permit ^yy$ SW1(config)#ip as-path access-list 10 deny .* Step 2: Apply the as-path filter inbound as shown in the example below: SW1(config)#router bgp xx SW1(config-switch)#neighbor x.1.4.12 filter-list 10 in
Review the switch configuration to verify that the number of received prefixes from each eBGP neighbor is controlled. router bgp xx neighbor x.1.1.9 remote-as yy neighbor x.1.1.9 maximum-prefix nnnnnnn neighbor x.2.1.7 remote-as zz neighbor x.2.1.7 maximum-prefix nnnnnnn If the switch is not configured to control the number of prefixes received from each peer to protect against route table flooding and prefix de-aggregation attacks, this is a finding.
Configure the switch to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks as shown in the example below: SW1(config)#router bgp xx SW1(config-switch)#neighbor x.1.1.9 maximum-prefix nnnnnnn SW1(config-switch)#neighbor x.2.1.7 maximum-prefix nnnnnnn
Review the switch configuration to determine if it is compliant with this requirement. Step 1: Verify that a route filter has been configured to reject prefixes longer than /24, or the least significant prefixes issued to the customers as shown in the example below: ip prefix-list FILTER_PREFIX_LENGTH seq 5 permit 0.0.0.0/0 ge 8 le 24 ip prefix-list FILTER_PREFIX_LENGTH seq 10 deny 0.0.0.0/0 le 32 Step 2: Verify that prefix filtering has been applied to each eBGP peer as shown in the example: router bgp xx neighbor x.1.1.9 remote-as yy neighbor x.1.1.9 prefix-list FILTER_PREFIX_LENGTH in neighbor x.2.1.7 remote-as zz neighbor x.2.1.7 prefix-list FILTER_PREFIX_LENGTH in If the switch is not configured to limit the prefix size on any inbound route advertisement to /24, or the least significant prefixes issued to the customer, this is a finding.
Configure the switch to limit the prefix size on any route advertisement to /24, or the least significant prefixes issued to the customer. Step 1: Configure a prefix list to reject any prefix that is longer than /24. SW1(config)#ip prefix-list FILTER_PREFIX_LENGTH permit 0.0.0.0/0 ge 8 le 24 SW1(config)#ip prefix-list FILTER_PREFIX_LENGTH deny 0.0.0.0/0 le 32 Step 2: Apply the prefix list to all eBGP peers as shown in the example below: SW1(config)#router bgp xx SW1(config-switch)#neighbor x.1.1.9 prefix-list FILTER_PREFIX_LENGTH in SW1(config-switch)#neighbor x.2.1.7 prefix-list FILTER_PREFIX_LENGTH in
Step 1: Review the switch configuration to verify that a loopback address has been configured. interface Loopback0 ip address 10.1.1.1 255.255.255.255 Step 2: Verify that the loopback interface is used as the source address for all iBGP sessions. router bgp xx no synchronization no bgp enforce-first-as bgp log-neighbor-changes redistribute static neighbor 10.1.1.1 remote-as xx neighbor 10.1.1.1 password xxxxxxxx neighbor 10.1.1.1 update-source Loopback0 If the switch does not use its loopback address as the source address for all iBGP sessions, this is a finding.
Configure the switch to use its loopback address as the source address for all iBGP peering. SW1(config)#router bgp xx SW1(config-switch)#neighbor 10.1.1.1 update-source Loopback0
Review the switch configuration to determine if it is compliant with this requirement. Verify that a loopback address has been configured as shown in the example below: interface Loopback0 ip address 10.1.1.1 255.255.255.255 By default, switches will use its loopback address for LDP peering. If an address has not be configured on the loopback interface, it will use its physical interface connecting to the LDP peer. If the router-id command is specified that overrides this default behavior, verify that it is a loopback interface as shown in the example below: mpls ldp router-id Loopback0 If the switch is not configured to use its loopback address for LDP peering, this is a finding.
Configure the switch to use their loopback address as the source address for LDP peering sessions. As noted in the check content, the default behavior is to use its loopback address. SW1(config)#mpls ldp router-id lo0
Review the switch OSPF or IS-IS configuration and verify that LDP will synchronize with the link-state routing protocol as shown in the example below: OSPF Example: router ospf 1 mpls ldp sync IS-IS Example: router isis mpls ldp sync net 49.0001.1234.1600.5531.00 If the switch is not configured to synchronize IGP and LDP, this is a finding.
Configure the MPLS switch to synchronize IGP and LDP, minimizing packet loss when an IGP adjacency is established prior to LDP peers completing label exchange. OSPF Example: SW2(config)#router ospf 1 SW2(config-switch)#mpls ldp sync IS-IS Example: SW1(config)#router isis SW1(config-switch)#mpls ldp sync
Review the switch configuration to determine RSVP messages are rate limited. Step 1: Determine if MPLS TE is enabled globally and at least one interface as shown in the example below: mpls traffic-eng tunnels … … … interface GigabitEthernet0/2 no switchport ip address x.x.x.x 255.255.255.0 mpls traffic-eng tunnels mpls ip Step 2: If MPLS TE is enabled, verify that message pacing is enabled. ip rsvp signalling rate-limit period 30 burst 9 maxsize 2100 limit 50 Note: The command "ip rsvp msg-pacing" has been deprecated by the command "ip rsvp signalling rate-limit". If the switch with RSVP-TE enabled does not rate limit RSVP messages based on the link speed and input queue size of adjacent core switches, this is a finding.
Configure the switch to rate limit RSVP messages per interface as shown in the example. SW2(config)#ip rsvp signalling rate-limit burst 9 maxsize 2100 period 30 limit 50
Review the switch configuration to verify that TTL propagation is disabled as shown in the example below: no mpls ip propagate-ttl If the MPLS switch is not configured to disable TTL propagation, this is a finding.
Configure the MPLS switch to disable TTL propagation as shown in the example below: SW1(config)#no mpls ip propagate-ttl
Step 1: Review the design plan for deploying L3VPN and VRF-lite. Step 2: Review the design plan for deploying L3VPN and VRF-lite. Review all CE-facing interfaces and verify that the proper VRF is defined via the "ip vrf forwarding" command. In the example below, COI1 is bound to interface GigabitEthernet0/1, while COI2 is bound to GigabitEthernet0/2. interface GigabitEthernet0/1 description link to COI1 no switchport ip vrf forwarding COI1 ip address x.1.0.1 255.255.255.0 ! interface GigabitEthernet0/2 description link to COI2 no switchport ip vrf forwarding COI2 ip address x.2.0.2 255.255.255.0 If any VRFs are not bound to the appropriate physical or logical interface, this is a finding.
Configure the PE switch to have each VRF bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.
Review the design plan for MPLS/L3VPN and VRF-lite to determine what RTs have been assigned for each VRF. Review the switch configuration and verify that the correct RT is configured for each VRF. In the example below, route target 13:13 has been configured for customer 1. ip vrf CUST1 rd 13:13 route-target export 13:13 route-target import 13:13 If there are VRFs configured with the wrong RT, this is a finding.
Configure the switch to have each VRF instance defined with the correct RT. SW1(config)#ip vrf CUST1 SW1(config-vrf)#route-target import 13:13 SW1(config-vrf)#route-target export 13:13 SW1(config-vrf)#end
Review the design plan for MPLS/L3VPN to determine what RD has been assigned for each VRF. Review the switch configuration and verify that the correct RD is configured for each VRF. In the example below, route distinguisher 13:13 has been configured for customer 1. ip vrf CUST1 rd 13:13 Note: This requirement is only applicable for MPLS L3VPN implementations. If the wrong RD has been configured for any VRF, this is a finding.
Configure the correct RD for each VRF. SW1(config)#ip vrf CUST1 SW1(config-vrf)#rd 13:13 SW1(config-vrf)#end
The Cisco switch is not compliant with this requirement; hence, it is a finding. However, the severity level can be downgraded to a category 3 if the switch is configured to authenticate targeted LDP sessions using MD5 as shown in the configuration example below: mpls ldp neighbor 10.1.1.2 password xxxxxxx mpls label protocol ldp If the switch is not configured to authenticate targeted LDP sessions using MD5, the finding will remain as a CAT II.
The severity level can be downgraded to a category 3 if the switch is configured to authenticate targeted LDP sessions using MD5 as shown in the example below: SW1(config)#mpls ldp neighbor 10.1.1.2 password xxxxxxxx
Verify that the correct and unique VCID has been configured for the appropriate attachment circuit. In the example below, GigabitEthernet0/1 is the CE-facing interface that is configured for VPWS with the VCID of 55. interface GigabitEthernet0/1 xconnect x.2.2.12 55 encapsulation mpls If the correct VC ID has not been configured on both switches, this is a finding.
Assign globally unique VC IDs for each virtual circuit and configure the attachment circuits with the appropriate VC ID.
Step 1: Review the implementation plan and the VPN IDs assigned to customer VLANs for the VPLS deployment. Step 2: Review the PE switch configuration to verify that customer attachment circuits are associated to the appropriate VFI. In the example below, the attached circuit at interface GigabitEthernet0/1 is associated to VPN ID 110. l2 vfi VPLS_A manual vpn id 110 bridge-domain 100 neighbor 10.3.3.3 encapsulation mpls neighbor 10.3.3.4 encapsulation mpls … … … interface GigabitEthernet0/1 no switchport no ip address service instance 10 ethernet encapsulation untagged bridge-domain 100 If the attachment circuits have not been bound to the VFI configured with the assigned VPN ID for each VLAN, this is a finding.
Assign globally unique VPN IDs for each customer bridge domain using VPLS for carrier Ethernet services between multiple sites, and configure the attachment circuits to the appropriate VFI. SW1(config)#l2 vfi VPLS_A manual SW1(config-vfi)#vpn id 110 SW1(config-vfi)#neighbor 10.3.3.3 encapsulation mpls SW1(config-vfi)#bridge-domain 100 SW1(config-vfi)#exit SW1(config)#int g0/1 SW1(config-if)#service instance 10 ethernet SW1(config-if-srv)#encapsulation untagged SW1(config-if-srv)#bridge-domain 100 SW1(config-if-srv)#end
Review the PE switch configuration to verify that split horizon is enabled. By default, split horizon is enabled; hence, the attribute no-split-horizon should not be seen on the neighbor command as shown in the example below: l2 vfi VPLS_A manual vpn id 110 bridge-domain 100 neighbor 10.3.3.3 encapsulation mpls no-split-horizon If split horizon is not enabled, this is a finding. Note: This requirement is only applicable to a mesh VPLS topology. VPLS solves the loop problem by using a split-horizon rule which states that member PE switches of a VPLS must forward VPLS traffic only to the local attachment circuits when they receive the traffic from the other PE switches. In a ring VPLS, split horizon must be disabled so that a PE switch can forward a packet received from one pseudowire to another pseudowire. To prevent the consequential loop, at least one span in the ring would not have a pseudowire for any given VPLS instance.
Enable split horizon on all PE switches deploying VPLS in a full-mesh configuration. SW1(config)#l2 vfi VPLS_A manual SW1(config-vfi)#neighbor 10.3.3.3 encapsulation mpls
Review the switch configuration to verify that storm control is enabled on CE-facing interfaces deploying VPLS as shown in the example below: interface GigabitEthernet3 no switchport no ip address service instance 10 ethernet encapsulation untagged bridge-domain 100 storm-control broadcast cir 12000000 ! ! If storm control is not enabled at a minimum for broadcast traffic, this is a finding.
Configure storm control for each CE-facing interface as shown in the example below: SW1(config)#int g3 SW1(config-if)#service instance 10 ethernet SW1(config-if-srv)#storm-control broadcast cir 12000000 SW1(config-if-srv)#end Note: The acceptable range is 10000000 -1000000000 for a gigabit ethernet interface, and 100000000-10000000000 for a ten gigabit interface. Storm control is not supported on most FastEthernet interfaces.
Review the switch configuration to verify that IGMP or MLD snooping has been configured for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain. The example below are the steps to verify that IGMP snooping is enabled for a VPLS bridge domain. Step 1: Verify that IGMP snooping is enabled globally. By default, IGMP snooping is enabled globally; hence, the following command should not be in the switch configuration: no ip igmp snooping Step 2: If IGMP snooping is enabled globally, it will also be enabled by default for each VPLS bridge domain. Hence, the command “no ip igmp snooping” should not be configured for any VPLS bridge domain as shown in the example below: bridge-domain 100 no ip igmp snooping ! If the switch is not configured to implement IGMP or MLD snooping for each VPLS bridge domain, this is a finding.
Configure IGMP or MLD snooping for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain. SW1(config)#bridge-domain 100 SW1(config-bdomain)#ip igmp snooping SW1(config-bdomain)#end
Review the PE switch configuration to determine if a MAC address limit has been set for each VPLS bridge domain. bridge-domain 100 mac limit maximum addresses nnnnn If a limit has not been configured, this is a finding.
Configure a MAC address learning limit for each VPLS bridge domain. SW1(config-bdomain)#mac limit maximum addresses nnnn
Step 1: Review the switch configuration to verify that an ingress ACL is applied to all external or CE-facing interfaces. interface GigabitEthernet0/2 no switchport ip address x.1.12.2 255.255.255.252 ip access-group BLOCK_TO_CORE in Step 2: Verify that the ingress ACL discards and logs packets destined to the IP core address space. ip access-list extended BLOCK_TO_CORE deny ip any 10.1.x.0 0.0.255.255 log-input permit ip any any ! If the PE switch is not configured to block any traffic with a destination address assigned to the IP core infrastructure, this is a finding. Note: Internet Control Message Protocol (ICMP) echo requests and traceroutes will be allowed to the edge from external adjacent neighbors.
Configure protection for the IP core to be implemented at the edges by blocking any traffic with a destination address assigned to the IP core infrastructure. Step 1: Configure an ingress ACL to discard and log packets destined to the IP core address space. SW2(config)#ip access-list extended BLOCK_TO_CORE SW2(config-ext-nacl)#deny ip any 10.1.x.0 0.0.255.255 log-input SW2(config-ext-nacl)#exit Step 2: Apply the ACL inbound to all external or CE-facing interfaces. SW2(config)#int SW1(config)#int g0/2 SW2(config-if)#ip access-group BLOCK_TO_CORE in SW2(config-if)#end
Review the switch configuration to determine if uRPF loose mode is enabled on all CE-facing interfaces. interface GigabitEthernet0/2 no switchport ip address x.1.12.2 255.255.255.252 ip access-group BLOCK_TO_CORE in ip verify unicast source reachable-via any If uRPF loose mode is not enabled on all CE-facing interfaces, this is a finding.
Configure uRPF loose mode on all CE-facing interfaces as shown in the example below: SW2(config)#int SW1(config)#int g0/2 SW2(config-if)#ip verify unicast source reachable-via any SW2(config-if)#end
Review the switch configuration to determine if it will ignore or drop all packets with IP options as shown in the examples below: ip options drop or ip options ignore If the switch is not configured to drop or block all packets with IP options, this is a finding.
Configure the switch to ignore or drop all packets with IP options as shown in the examples below: SW1(config)#ip options ignore or SW1(config)#ip options drop
Review the switch configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications in accordance with the QoS GIG Technical Profile. Step 1: Verify that the class-maps are configured to match on DSCP values as shown in the configuration example below: class-map match-all C2_VOICE match ip dscp af47 class-map match-all VOICE match ip dscp ef class-map match-all VIDEO match ip dscp af41 class-map match-all CONTROL_PLANE match ip dscp cs6 class-map match-all PREFERRED_DATA match ip dscp af33 Step 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the example below: policy-map QOS_POLICY class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class CONTROL_PLANE priority percent 10 class PREFERRED_DATA bandwidth percent 25 class class-default bandwidth percent 15 Step 3: Verify that an output service policy is bound to all interfaces as shown in the configuration example below: interface GigabitEthernet1/1 no switchport ip address 10.1.15.1 255.255.255.252 service-policy output QOS_POLICY ! interface GigabitEthernet1/2 no switchport ip address 10.1.15.4 255.255.255.252 service-policy output QOS_POLICY Note: Enclaves must mark or re-mark their traffic to be consistent with the DODIN backbone admission criteria to gain the appropriate level of service. A general DiffServ principle is to mark or trust traffic as close to the source as administratively and technically possible. However, certain traffic types might need to be re-marked before handoff to the DODIN backbone to gain admission to the correct class. If such re-marking is required, it is recommended that the re-marking be performed at the CE egress edge. Note: The GTP QOS document (GTP-0009) can be downloaded via the following link: https://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List If the switch is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.
Configure a QoS policy in accordance with the QoS GIGTechnical Profile. Step 1: Configure class-maps to match on DSCP values as shown in the configuration example below: SW1(config)#class-map match-all PREFERRED_DATA SW1(config-cmap)#match ip dscp af33 SW1(config-cmap)#class-map match-all CONTROL_PLANE SW1(config-cmap)#match ip dscp cs6 SW1(config-cmap)#class-map match-all VIDEO SW1(config-cmap)#match ip dscp af41 SW1(config-cmap)#class-map match-all VOICE SW1(config-cmap)#match ip dscp ef SW1(config-cmap)#class-map match-all C2_VOICE SW1(config-cmap)#match ip dscp 47 SW1(config-cmap)#exit Step 2: Configure a policy map to be applied to the core-layer-facing interface that reserves the bandwidth for each traffic type as shown in the example below: SW1(config)#policy-map QOS_POLICY SW1(config-pmap)#class CONTROL_PLANE SW1(config-pmap-c)#priority percent 10 SW1(config-pmap-c)#class C2_VOICE SW1(config-pmap-c)#priority percent 10 SW1(config-pmap-c)#class VOICE SW1(config-pmap-c)#priority percent 15 SW1(config-pmap-c)#class VIDEO SW1(config-pmap-c)#bandwidth percent 25 SW1(config-pmap-c)#class PREFERRED_DATA SW1(config-pmap-c)#bandwidth percent 25 SW1(config-pmap-c)#class class-default SW1(config-pmap-c)#bandwidth percent 15 SW1(config-pmap-c)#exit SW1(config-pmap)#exit Step 3: Apply the output service policy to all interfaces as shown in the configuration example below: SW1(config)#int g1/1 SW1(config-if)#service-policy output QOS_POLICY SW1(config-if)#exit SW1(config)#int g1/2 SW1(config-if)#service-policy output QOS_POLICY SW1(config-if)#end
Review the switch configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications in accordance with the QoS GIG Technical Profile. Step 1: Verify that the class-maps are configured to match on DSCP values as shown in the configuration example below: class-map match-all PREFERRED_DATA match ip dscp af33 class-map match-all CONTROL_PLANE match ip dscp cs6 class-map match-all VIDEO match ip dscp af41 class-map match-all VOICE match ip dscp ef class-map match-all C2_VOICE match ip dscp 47 Step 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the example below: policy-map QOS_POLICY class CONTROL_PLANE priority percent 10 class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class PREFERRED_DATA bandwidth percent 25 class class-default bandwidth percent 15 Step 3: Verify that an output service policy is bound to all interfaces as shown in the configuration example below: interface GigabitEthernet1/1 no switchport ip address 10.1.15.5 255.255.255.252 service-policy output QOS_POLICY ! interface GigabitEthernet1/2 no switchport ip address 10.1.15.8 255.255.255.252 service-policy output QOS_POLICY Note: The GTP QOS document (GTP-0009) can be downloaded via the following link: https://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List If the switch is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.
Configure a QoS policy in accordance with the QoS GIG Technical Profile. Step 1: Configure class-maps to match on DSCP values as shown in the configuration example below: SW1(config)#class-map match-all PREFERRED_DATA SW1(config-cmap)#match ip dscp af33 SW1(config-cmap)#class-map match-all CONTROL_PLANE SW1(config-cmap)#match ip dscp cs6 SW1(config-cmap)#class-map match-all VIDEO SW1(config-cmap)#match ip dscp af41 SW1(config-cmap)#class-map match-all VOICE SW1(config-cmap)#match ip dscp ef SW1(config-cmap)#class-map match-all C2_VOICE SW1(config-cmap)#match ip dscp 47 SW1(config-cmap)#exit Step 2: Configure a policy map to be applied to the core-layer-facing interface that reserves the bandwidth for each traffic type as shown in the example below: SW1(config)#policy-map QOS_POLICY SW1(config-pmap)#class CONTROL_PLANE SW1(config-pmap-c)#priority percent 10 SW1(config-pmap-c)#class C2_VOICE SW1(config-pmap-c)#priority percent 10 SW1(config-pmap-c)#class VOICE SW1(config-pmap-c)#priority percent 15 SW1(config-pmap-c)#class VIDEO SW1(config-pmap-c)#bandwidth percent 25 SW1(config-pmap-c)#class PREFERRED_DATA SW1(config-pmap-c)#bandwidth percent 25 SW1(config-pmap-c)#class class-default SW1(config-pmap-c)#bandwidth percent 15 SW1(config-pmap-c)#exit SW1(config-pmap)#exit Step 3: Apply the output service policy to all interfaces as shown in the configuration example below: SW1(config)#int g1/1 SW1(config-if)#service-policy output QOS_POLICY SW1(config-if)#exit SW1(config)#int g1/2 SW1(config-if)#service-policy output QOS_POLICY SW1(config-if)#end
Review the switch configuration to determine if it is configured to enforce a QoS policy to limit the effects of packet flooding DoS attacks. Step 1: Verify that a class map has been configured for the Scavenger class as shown in the example below: class-map match-all SCAVENGER match ip dscp cs1 Step 2: Verify that the policy map includes the SCAVENGER class with low priority as shown in the example below: policy-map QOS_POLICY class CONTROL_PLANE priority percent 10 class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class PREFERRED_DATA bandwidth percent 25 class SCAVENGER bandwidth percent 5 class class-default bandwidth percent 10 Note: Traffic out of profile must be marked at the customer access layer or CE egress edge. If the switch is not configured to enforce a QoS policy to limit the effects of packet flooding DoS attacks, this is a finding.
Step 1: Configure a class map for the SCAVENGER class. SW1(config)#class-map match-all SCAVENGER SW1(config-cmap)#match ip dscp cs1 Step 2: Add the SCAVENGER class to the policy map as shown in the example below: SW1(config)#policy-map QOS_POLICY SW1(config-pmap-c)#no class class-default SW1(config-pmap)#class SCAVENGER SW1(config-pmap-c)#bandwidth percent 5 SW1(config-pmap-c)#class class-default SW1(config-pmap-c)#bandwidth percent 10 SW1(config-pmap-c)#end
Step 1: Review the network's multicast topology diagram. Step 2: Review the switch configuration to verify that only the PIM interfaces as shown in the multicast topology diagram are enabled for PIM as shown in the example below: interface GigabitEthernet1/1 no switchport ip address 10.1.3.3 255.255.255.0 ip pim sparse-mode If an interface is not required to support multicast routing and it is enabled, this is a finding.
Document all enabled interfaces for PIM in the network's multicast topology diagram. Disable support for PIM on interfaces that are not required to support it. SW1(config)#int g1/1 SW1(config-if)#no ip pim sparse-mode
Step 1: Verify all interfaces enabled for PIM have a neighbor ACL bound to the interface as shown in the example below: interface GigabitEthernet1/1 no switchport ip address 10.1.2.2 255.255.255.0 ip pim neighbor-filter PIM_NEIGHBORS ip pim sparse-mode Step 2: Review the configured ACL for filtering PIM neighbors as shown in the example below: ip access-list standard PIM_NEIGHBORS permit 10.1.2.6 If PIM neighbor ACLs are not bound to all interfaces that have PIM enabled, this is a finding.
Configure neighbor ACLs to only accept PIM control plane traffic from documented PIM neighbors. Bind neighbor ACLs to all PIM enabled interfaces. Step 1: Configure ACL for PIM neighbors. SW2(config)#ip access-list standard PIM_NEIGHBORS SW2(config-std-nacl)#permit 10.1.2.6 SW2(config-std-nacl)#exit Step 2: Apply the ACL to all interfaces enabled for PIM. SW2(config)#int g1/1 SW2(config-if)#ip pim neighbor-filter PIM_NEIGHBORS
Review the switch configuration and verify that admin-scope multicast traffic is blocked at the external edge as shown in the example below: interface GigabitEthernet1/2 ip address x.1.12.2 255.255.255.252 ip pim sparse-mode ip multicast boundary MULTICAST_SCOPE … … … ip access-list standard MULTICAST_SCOPE deny 239.0.0.0 0.255.255.255 permit any If the switch is not configured to establish boundaries for administratively scoped multicast traffic, this is a finding.
Step 1: Configure the ACL to deny packets with multicast administratively scoped destination addresses as shown in the example below: SW2(config)#ip access-list standard MULTICAST_SCOPE SW2(config-std-nacl)#deny 239.0.0.0 0.255.255.255 SW2(config-std-nacl)#permit any SW2(config-std-nacl)#exit Step 2: Apply the multicast boundary at the appropriate interfaces as shown in the example below: SW2(config)#int g1/2 SW2(config-if)#ip multicast boundary MULTICAST_SCOPE SW2(config-if)#end
The Cisco switch does not have a mechanism to limit the multicast forwarding cache. However, the risk associated with this requirement can be fully mitigated by configuring the switch to: 1. Filter PIM register messages. 2. Rate limiting the number of PIM register messages. 3. Accept MSDP packets only from known MSDP peers. Step 1: Verify that the RP is configured to filter PIM register messages for any undesirable multicast groups and sources. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources x.1.2.6 and x.1.2.7. ip pim rp-address 10.1.12.3 ip pim accept-register list PIM_REGISTER_FILTER … … … ip access-list extended PIM_REGISTER_FILTER deny ip any 239.5.0.0 0.0.255.255 permit ip host x.1.2.6 any permit ip host x.1.2.7 any deny ip any any Step 2: Verify that the RP is configured to rate limiting the number of PIM register messages as shown in the example below: ip pim rp-address 10.2.2.2 ip pim register-rate-limit nn Step 3: Review the switch configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers as shown in the example below: Step 3a: Verify that interfaces used for MSDP peering have an inbound ACL as shown in the example. interface GigabitEthernet1/1 ip address x.1.28.8 255.255.255.0 ip access-group EXTERNAL_ACL_INBOUND in ip pim sparse-mode Step 3b: Verify that the ACL restricts MSDP peering to only known sources. ip access-list extended EXTERNAL_ACL_INBOUND permit tcp any any established permit tcp host x.1.28.2 host x.1.28.8 eq 639 deny tcp any host x.1.28.8 eq 639 log permit tcp host x.1.28.2 host 10.1.28.8 eq bgp permit tcp host x.1.28.2 eq bgp host x.1.28.8 permit pim host x.1.28.2 pim host x.1.28.8 … … … deny ip any any log Note: MSDP connections is via TCP port 639. If the RP switch is not configured to filter PIM register messages, rate limiting the number of PIM register messages, and accept MSDP packets only from known MSDP peers, this is a finding.
The risk associated with this requirement can be fully mitigated by configuring the switch to filter PIM register messages, rate limiting the number of PIM register messages, and accept MSDP packets only from known MSDP peers. Step 1: Configure the switch to filter PIM register messages received from a multicast DR for any undesirable multicast groups and sources. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources x.1.2.6 and x.1.2.7. SW1(config)#ip access-list extended PIM_REGISTER_FILTER SW1(config-ext-nacl)#deny ip any 239.5.0.0 0.0.255.255 SW1(config-ext-nacl)#permit ip host x.1.2.6 any SW1(config-ext-nacl)#permit ip host x.1.2.7 any SW1(config-ext-nacl)#deny ip any any SW1(config-ext-nacl)#exit SW1(config)#ip pim accept-register list PIM_REGISTER_FILTER SW1(config)#end Step 2: Configure the RP to rate limit the number of multicast register messages. SW1(config)#ip pim register-rate-limit nn Step 3: Configure the receive path or interface ACLs to only accept MSDP packets from known MSDP peers. SW1(config)#ip access-list extended EXTERNAL_ACL_INBOUND SW1(config-ext-nacl)#permit tcp any any established SW1(config-ext-nacl)#permit tcp host x.1.28.2 host x.1.28.8 eq 639 SW1(config-ext-nacl)#deny tcp any host x.1.28.8 eq 639 SW1(config-ext-nacl)#permit tcp host x.1.28.2 host x.1.28.8 eq bgp SW1(config-ext-nacl)#permit tcp host x.1.28.2 eq bgp host x.1.28.8 SW1(config-ext-nacl)#permit pim host x.1.28.2 host x.1.28.8 … … … SW1(config-ext-nacl)#deny ip any any
Verify that the RP is configured to filter PIM register messages. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources x.1.2.6 and x.1.2.7. ip pim rp-address 10.1.12.3 ip pim accept-register list PIM_REGISTER_FILTER … … … ip access-list extended PIM_REGISTER_FILTER deny ip any 239.5.0.0 0.0.255.255 permit ip host x.1.2.6 any permit ip host x.1.2.7 any deny ip any any If the RP switch peering with PIM-SM switches is not configured with a policy to block registration messages for any undesirable multicast groups and sources, this is a finding.
Configure the switch to filter PIM register messages received from a multicast DR for any undesirable multicast groups and sources. The example below will deny any multicast streams for groups 239.5.0.0/16 and allow from only sources x.1.2.6 and x.1.2.7. SW2(config)#ip access-list extended PIM_REGISTER_FILTER SW2(config-ext-nacl)#deny ip any 239.5.0.0 0.0.255.255 SW2(config-ext-nacl)#permit ip host x.1.2.6 any SW2(config-ext-nacl)#permit ip host x.1.2.7 any SW2(config-ext-nacl)#deny ip any any SW2(config-ext-nacl)#exit SW2(config)#ip pim accept-register list PIM_REGISTER_FILTER SW2(config)#end
Verify that the RP is configured to filter PIM join messages for any undesirable multicast groups. In the example below, groups from 239.8.0.0/16 are not allowed. ip pim rp-address 10.2.2.2 ip pim accept-rp 10.2.2.2 FILTER_PIM_JOINS … … … ip access-list standard FILTER_PIM_JOINS deny 239.8.0.0 0.0.255.255 permit any ! If the RP is not configured to filter join messages received from the DR for any undesirable multicast groups, this is a finding.
Configure the RP to filter PIM join messages for any undesirable multicast groups as shown in the example below: SW2(config)#ip access-list standard PIM_JOIN_FILTER SW2(config-std-nacl)#deny 239.8.0.0 0.0.255.255 SW2(config-std-nacl)#permit any SW2(config-std-nacl)#exit SW2(config)#ip pim accept-rp 10.2.2.2 PIM_JOIN_FILTER SW2(config)#end
Review the configuration of the RP to verify that it is rate limiting the number of PIM register messages. ip pim rp-address 10.2.2.2 ip pim register-rate-limit nn If the RP is not limiting PIM register messages, this is a finding.
Configure the RP to rate limit the number of multicast register messages. SW2(config)#ip pim register-rate-limit nn
Review the configuration of the DR to verify that it is filtering IGMP or MLD Membership Report messages, allowing hosts to join only those groups that have been approved. Step 1: Verify that all host-facing layer 3 and VLAN interfaces are configured to filter IGMP Membership Report messages (IGMP joins) as shown in the example below: interface Vlan3 ip address 10.3.3.3 255.255.255.0 ip pim sparse-mode ip igmp access-group IGMP_JOIN_FILTER ip igmp version 3 Step 2: Verify that the ACL denies unauthorized groups or permits only authorized groups. The example below denies all groups from 239.8.0.0/16 range. ip access-list standard IGMP_JOIN_FILTER deny 239.8.0.0 0.0.255.255 permit any Note: This requirement is only applicable to Source Specific Multicast (SSM) implementation. This requirement is not applicable to Any Source Multicast (ASM) since the filtering is being performed by the Rendezvous Point switch. If the DR is not filtering IGMP or MLD Membership Report messages, this is a finding.
Configure the DR to filter the IGMP or MLD Membership Report messages to allow hosts to join only those multicast groups that have been approved. Step 1: Configure the ACL to filter IGMP Membership Report messages as shown in the example below: SW2(config)#ip access-list standard IGMP_JOIN_FILTER SW2(config-std-nacl)#deny 239.8.0.0 0.0.255.255 SW2(config-std-nacl)#permit any SW2(config-std-nacl)#exit Step 2: Apply the filter to all host-facing layer 3 and VLAN interfaces. SW2(config)#int vlan3 SW2(config-if)#ip igmp access-group IGMP_JOIN_FILTER
Review the configuration of the DR to verify that it is filtering IGMP or MLD report messages, allowing hosts to only join multicast groups from sources that have been approved. Step 1: Verify that all host-facing layer 3 and VLAN interfaces are configured to filter IGMP Membership Report messages (IGMP joins) as shown in the example below: interface Vlan3 ip address 10.3.3.3 255.255.255.0 ip pim sparse-mode ip igmp access-group IGMP_JOIN_FILTER ip igmp version 3 Step 2: Verify that the ACL denies unauthorized sources or allows only authorized sources. The example below denies all groups from 232.8.0.0/16 range and permits sources only from the x.0.0.0/8 network. ip access-list extended IGMP_JOIN_FILTER deny ip any 232.8.0.0 0.0.255.255 permit ip x.0.0.0 0.255.255.255 any deny ip any any Note: This requirement is only applicable to Source Specific Multicast (SSM) implementation. If the DR is not filtering IGMP or MLD report messages, this is a finding.
Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only those multicast groups from sources that have been approved as shown in the example below: SW2(config)#ip access-list extended IGMP_JOIN_FILTER SW2(config-ext-nacl)#deny ip any 232.8.0.0 0.0.255.255 SW2(config-ext-nacl)#permit ip x.0.0.0 0.255.255.255 any SW2(config-ext-nacl)#deny ip any any SW2(config-ext-nacl)#exit Step 2: Apply the filter to all host-facing layer 3 and VLAN interfaces. SW2(config)#int vlan3 SW2(config-if)#ip igmp access-group IGMP_JOIN_FILTER
Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD. Verify IGMP limits have been configured globally or on each host-facing layer 3 and VLAN interface via the ip igmp limit command as shown in the example below: interface Vlan3 ip address 10.3.3.3 255.255.255.0 … … … ip igmp limit nn If the DR is not limiting multicast join requests via IGMP or MLD on a global or interfaces basis, this is a finding.
Configure the DR on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports. SW2(config)#int vlan3 SW2(config-if)#ip igmp limit 2
Review the DR configuration to verify that the SPT switchover threshold is increased (default is "0") or set to infinity (never switch over). ip pim rp-address 10.2.2.2 ip pim spt-threshold infinity If the DR is not configured to increase the SPT threshold or set to infinity to minimalize (S, G) state, this is a finding.
Configure the DR to increase the SPT threshold or set it to infinity to minimalize (S, G) state within the multicast topology where ASM is deployed. SW2(config)#ip pim spt-threshold infinity
Review the switch configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers. Step 1: Verify that interfaces used for MSDP peering have an inbound ACL as shown in the example below: interface GigabitEthernet1/1 no switchport ip address x.1.28.8 255.255.255.0 ip access-group EXTERNAL_ACL_INBOUND in ip pim sparse-mode Step 2: Verify that the ACL restricts MSDP peering to only known sources. ip access-list extended EXTERNAL_ACL_INBOUND permit tcp any any established permit tcp host x.1.28.2 host x.1.28.8 eq 639 deny tcp any host x.1.28.8 eq 639 log permit tcp host x.1.28.2 host 10.1.28.8 eq bgp permit tcp host x.1.28.2 eq bgp host x.1.28.8 permit pim host x.1.28.2 host x.1.28.8 … … … deny ip any any log Note: MSDP connections is via TCP port 639. If the switch is not configured to only accept MSDP packets from known MSDP peers, this is a finding.
Configure the receive path or interface ACLs to only accept MSDP packets from known MSDP peers. SW1(config)#ip access-list extended EXTERNAL_ACL_INBOUND SW1(config-ext-nacl)#permit tcp any any established SW1(config-ext-nacl)#permit tcp host x.1.28.2 host x.1.28.8 eq 639 SW1(config-ext-nacl)#deny tcp any host x1.28.8 eq 639 SW1(config-ext-nacl)#permit tcp host x.1.28.2 host x.1.28.8 eq bgp SW1(config-ext-nacl)#permit tcp host x.1.28.2 eq bgp host x.1.28.8 SW1(config-ext-nacl)#permit pim host x.1.28.2 host x.1.28.8 … … … SW1(config-ext-nacl)#deny ip any any
Review the switch configuration to determine if received MSDP packets are authenticated. ip msdp peer x.1.28.8 remote-as 8 ip msdp password peer x.1.28.8 xxxxxxxxxxxx If the switch does not require MSDP authentication, this is a finding.
Configure the switch to authenticate MSDP messages as shown in the following example: SW2(config)#ip msdp password peer x.1.28.8 xxxxxxxxxxxx
Review the switch configuration to determine if there is import policy to block source-active multicast advertisements for any undesirable multicast groups, as well as any (S, G) states with undesirable source addresses. Step 1: Verify that an inbound source-active filter is bound to each MSDP peer. ip msdp peer x.1.28.2 remote-as 2 ip msdp sa-filter in x.1.28.2 list INBOUND_MSDP_SA_FILTER Step 2: Review the access lists referenced by the source-active filter to verify that undesirable multicast groups, auto-RP, single source multicast (SSM) groups, and advertisements from undesirable sources are blocked. ip access-list extended INBOUND_MSDP_SA_FILTER deny ip any host 224.0.1.3 deny ip any host 224.0.1.24 deny ip any host 224.0.1.22 deny ip any host 224.0.1.2 deny ip any host 224.0.1.35 deny ip any host 224.0.1.60 deny ip any host 224.0.1.39 deny ip any host 224.0.1.40 deny ip any 232.0.0.0 0.255.255.255 deny ip any 239.0.0.0 0.255.255.255 deny ip 10.0.0.0 0.255.255.255 any deny ip 127.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any permit ip any any If the switch is not configured with an import policy to filter undesirable SA multicast advertisements, this is a finding.
Configure the MSDP switch to filter received source-active multicast advertisements for any undesirable multicast groups and sources as shown in the example below: SW1(config)#ip access-list extended INBOUND_MSDP_SA_FILTER SW1(config-ext-nacl)#deny ip any host 224.0.1.3 ! Rwhod SW1(config-ext-nacl)#deny ip any host 224.0.1.24 ! Microsoft-ds SW1(config-ext-nacl)#deny ip any host 224.0.1.22 ! SVRLOC SW1(config-ext-nacl)#deny ip any host 224.0.1.2 ! SGI-Dogfight SW1(config-ext-nacl)#deny ip any host 224.0.1.35 ! SVRLOC-DA SW1(config-ext-nacl)#deny ip any host 224.0.1.60 ! hp-device-disc SW1(config-ext-nacl)#deny ip any host 224.0.1.39 ! Auto-RP SW1(config-ext-nacl)#deny ip any host 224.0.1.40 ! Auto-RP SW1(config-ext-nacl)#deny ip any 232.0.0.0 0.255.255.255 ! SSM range SW1(config-ext-nacl)#deny ip any 239.0.0.0 0.255.255.255 ! Admin scoped range SW1(config-ext-nacl)#deny ip 10.0.0.0 0.255.255.255 any ! RFC 1918 address range SW1(config-ext-nacl)#deny ip 127.0.0.0 0.255.255.255 any ! RFC 1918 address range SW1(config-ext-nacl)#deny ip 172.16.0.0 0.15.255.255 any ! RFC 1918 address range SW1(config-ext-nacl)#deny ip 192.168.0.0 0.0.255.255 any ! RFC 1918 address range SW1(config-ext-nacl)#permit ip any any SW1(config-ext-nacl)#exit SW1(config)#ip msdp sa-filter in x.1.28.2 list INBOUND_MSDP_SA_FILTER
Review the switch configuration to determine if there is export policy to block local source-active multicast advertisements. Step 1: Verify that an outbound source-active filter is bound to each MSDP peer as shown in the example below: ip msdp peer 10.1.28.8 remote-as 8 ip msdp sa-filter out 10.1.28.8 list OUTBOUND_MSDP_SA_FILTER Step 2: Review the access lists referenced by the source-active filters and verify that MSDP source-active messages being sent to MSDP peers do not leak advertisements that are local. ip access-list extended OUTBOUND_MSDP_SA_FILTER deny ip 10.0.0.0 0.255.255.255 any permit ip any any If the switch is not configured with an export policy to filter local source-active multicast advertisements, this is a finding.
Configure the switch with an export policy avoid global visibility of local multicast (S, G) states. The example below will prevent exporting multicast active sources belonging to the private network. SW1(config)#ip access-list extended OUTBOUND_MSDP_SA_FILTER SW1(config-ext-nacl)#deny ip 10.0.0.0 0.255.255.255 any SW1(config-ext-nacl)#permit ip any any SW1(config-ext-nacl)#exit SW1(config)#ip msdp sa-filter in x.1.28.2 list OUTBOUND_MSDP_SA_FILTER
Review the switch configuration to determine if it is configured to limit the amount of source-active messages it accepts on a per-peer basis. ip msdp peer x.1.28.2 remote-as nn ip msdp sa-filter in 10.1.28.2 list MSDP_SA_FILTER ip msdp sa-limit X.1.28.2 nnn If the switch is not configured to limit the source-active messages it accepts, this is a finding.
Configure the switch to limit the amount of source-active messages it accepts from each peer. SW1(config)#ip msdp sa-limit x.1.28.2 nnn
Step 1: Review the switch configuration to verify that a loopback address has been configured. interface Loopback12 ip address x.12.2.2 255.255.255.255 Step 2: Verify that the loopback interface is used as the source address for all MSDP packets generated by the switch. ip msdp peer x.44.2.34 connect-source Loopback12 remote-as nn If the switch does not use its loopback address as the source address when originating MSDP traffic, this is a finding.
Configure the switch to use its loopback address is used as the source address when sending MSDP packets. SW2(config)#ip msdp peer x.44.2.34 connect-source lo12 remote-as nn
Review the switch to verify that CEF is enabled. IPv4 Example: ip cef IPv6 Example: ipv6 cef If the switch is not configured to have CEF enabled, this is a finding.
Enable CEF IPv4 Example: ip cef IPv6 Example: ipv6 cef
Review the switch configuration to determine if the hop limit has been configured for Router Advertisement messages as shown in the example. ipv6 hop-limit 128 If hop-limit has been configured and has not been set to at least 32, it is a finding.
Configure the switch to advertise a hop limit of at least 32 in Router Advertisement messages as shown in the example. SW1(config)#ipv6 hop-limit 128
Review the switch configuration to ensure FEC0::/10 IPv6 addresses are not defined. If IPv6 Site Local Unicast addresses are defined, this is a finding.
Configure the switch using only authorized IPv6 addresses.
This requirement is not applicable for the DODIN Backbone. Review the switch configuration to verify that Router Advertisements are suppressed on all external IPv6-enabled interfaces as shown in the example below. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 nd ra suppress If the switch is not configured to suppress Router Advertisements on all external IPv6-enabled interfaces, this is a finding.
Configure the switch to suppress Router Advertisements on all external IPv6-enabled interfaces as shown in the example below. SW1(config)#int g1/0 SW1(config-if)#ipv6 nd ra suppress SW1(config-if)#end
This requirement is not applicable for the DODIN Backbone. Review the switch configuration to determine if it is configured to drop IPv6 undetermined transport packets. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops undetermined transport packets as shown in the example below. ipv6 access-list FILTER_IPV6 deny ipv6 any any log undetermined-transport permit ipv6 … … … … deny ipv6 any any log If the switch is not configured to drop IPv6 undetermined transport packets, this is a finding.
Configure the switch to drop IPv6 undetermined transport packets as shown in the example below. SW1(config)#ipv6 access-list FILTER_IPV6 SW1(config-ipv6-acl)#deny ipv6 any any undetermined-transport log SW1(config-ipv6-acl)#permit ipv6 … … … … SW1(config-ipv6-acl)#deny ipv6 any any log SW1(config-ipv6-acl)#exit SW1(config)#int g1/0 SW1(config-if)#ipv6 traffic-filter FILTER_IPV6 in
This requirement is not applicable for the DODIN Backbone. Review the switch configuration to determine if it is configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3-255. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets with a Routing Header type 0, 1, or 3-255 as shown in the example below. ipv6 access-list FILTER_IPV6 permit ipv6 any host 2001:DB8::1:1:1234 routing-type 2 deny ipv6 any any log routing permit ipv6 … … … … deny ipv6 any any log Note: The example above allows routing-type 2 in the event Mobility IPv6 is deployed. If the switch is not configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3-255, this is a finding.
Configure the switch to drop IPv6 packets with Routing Header of type 0, 1, or 3-255 as shown in the example below. SW1(config)#ipv6 access-list FILTER_IPV6 SW1(config-ipv6-acl)#permit ipv6 any host 2001:DB8::0:1:1:1234 routing-type 2 SW1(config-ipv6-acl)#deny ipv6 any any routing log SW1(config-ipv6-acl)#permit … … … … SW1(config-ipv6-acl)#deny ipv6 any any log SW1(config-ipv6-acl)#exit SW1(config)#int g1/0 SW1(config-if)#ipv6 traffic-filter FILTER_IPV6
This requirement is not applicable for the DODIN Backbone. Review the switch configuration to determine if it is compliant with this requirement. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets containing a Hop-by-Hop header with option type values of 0x04 (Tunnel Encapsulation Limit), 0xC9 (Home Address Destination), or 0xC3 (NSAP Address) as shown in the example below. ipv6 access-list FILTER_IPV6 deny hbh any any dest-option-type 4 log deny hbh any any dest-option-type 195 log deny hbh any any dest-option-type home-address log permit ipv6 … … … … deny ipv6 any any log If the switch is not configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values, this is a finding.
Configure the switch to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values as shown in the example below. SW1(config)#ipv6 access-list FILTER_IPV6 SW1(config-ipv6-acl)#deny hbh any any dest-option-type 4 log SW1(config-ipv6-acl)#deny hbh any any dest-option-type 195 log SW1(config-ipv6-acl)#deny hbh any any dest-option-type home-address log SW1(config-ipv6-acl)# permit ipv6 … … … … SW1(config-ipv6-acl)#deny ipv6 any any log SW1(config-ipv6-acl)#exit SW1(config)#int g1/0 SW1(config-if)#ipv6 traffic-filter FILTER_IPV6 SW1(config-if)#end
This requirement is not applicable for the DODIN Backbone. Review the switch configuration to determine if it is compliant with this requirement. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets containing a Destination Option header with option type values of 0x05 (Switch Alert) or 0xC2 (Jumbo Payload) as shown in the example below. ipv6 access-list FILTER_IPV6 deny 60 any any dest-option-type 5 log deny 60 any any dest-option-type 194 log permit ipv6 … … … … deny ipv6 any any log If the switch is not configured to drop IPv6 packets containing a Destination Option header with option type values of 0x05 (Switch Alert) or 0xC2 (Jumbo Payload), this is a finding.
Configure the switch to drop IPv6 packets containing a Destination Option header with option type values of 0x05 (Switch Alert) or 0xC2 (Jumbo Payload) as shown in the example below. SW1(config)#ipv6 access-list FILTER_IPV6 SW1(config-ipv6-acl)#deny 60 any any dest-option-type 5 log SW1(config-ipv6-acl)#deny 60 any any dest-option-type 194 log SW1(config-ipv6-acl)#permit … … … … SW1(config-ipv6-acl)#deny ipv6 any any log SW1(config-ipv6-acl)#exit SW1(config)#int g1/0 SW1(config-if)#ipv6 traffic-filter FILTER_IPV6 SW1(config-if)#end
This requirement is not applicable for the DODIN Backbone. Review the switch configuration to determine if it is compliant with this requirement. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets containing an extension header with the Endpoint Identification option as shown in the example below. ipv6 access-list FILTER_IPV6 deny any any dest-option-type 138 log permit ipv6 … … … … deny ipv6 any any log If the switch is not configured to drop IPv6 packets containing an extension header with the Endpoint Identification option, this is a finding.
Configure the switch to drop IPv6 packets containing an option type values of 0x8A (Endpoint Identification) regardless of whether it appears in a Hop-by-Hop or Destination Option header as shown in the example below. SW1(config)#ipv6 access-list FILTER_IPV6 SW1(config-ipv6-acl)#deny any any dest-option-type 138 log SW1(config-ipv6-acl)#permit ipv6 … … … … SW1(config-ipv6-acl)# deny ipv6 any any log SW1(config-ipv6-acl)#exit SW1(config)#int g1/0 SW1(config-if)#ipv6 traffic-filter FILTER_IPV6 SW1(config-if)#end
This requirement is not applicable for the DODIN Backbone. Review the switch configuration and determine if filters are bound to the applicable interfaces to drop IPv6 packets containing a Destination Option header with option type value of 0xC3 (NSAP address). Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets containing the NSAP address option within Destination Option header as shown in the example below. ipv6 access-list FILTER_IPV6 deny 60 any any dest-option-type 195 log permit ipv6 … … … … deny ipv6 any any log If the switch is not configured to drop IPv6 packets containing the NSAP address option within Destination Option header, this is a finding.
Configure the switch to to drop IPv6 packets containing the NSAP address option within Destination Option header as shown in the example below. SW1(config)#ipv6 access-list FILTER_IPV6 SW1(config-ipv6-acl)#deny 60 any any dest-option-type 195 log SW1(config-ipv6-acl)#permit … … … … SW1(config-ipv6-acl)# deny ipv6 any any log SW1(config-ipv6-acl)#exit SW1(config)#int g1/0 SW1(config-if)#ipv6 traffic-filter FILTER_IPV6 SW1(config-if)#end
This requirement is not applicable for the DODIN Backbone. Review the switch configuration and determine if filters are bound to the applicable interfaces to drop all inbound IPv6 packets containing an undefined option type value regardless of whether they appear in a Hop-by-Hop or Destination Option header. Undefined values are 0x02, 0x03, 0x06, 0x9 – 0xE, 0x10 – 0x22, 0x24, 0x25, 0x27 – 0x2F, and 0x31 – 0xFF. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type as shown in the example below. ipv6 access-list FILTER_IPV6 deny any any dest-option-type 2 deny any any dest-option-type 3 deny any any dest-option-type 6 deny any any dest-option-type 9 deny any any dest-option-type 10 deny any any dest-option-type 11 deny any any dest-option-type 12 deny any any dest-option-type 13 deny any any dest-option-type 14 deny any any dest-option-type 16 … deny any any dest-option-type 34 deny any any dest-option-type 36 deny any any dest-option-type 37 deny any any dest-option-type 39 … deny any any dest-option-type 47 deny any any dest-option-type 49 … deny any any dest-option-type 255 permit … … … … deny ipv6 any any log Note: Because hop-by-hop and destination options have the same exact header format, they can be combined under the dest-option-type keyword. Since Hop-by-Hop and Destination Option headers have non-overlapping types, you can use dest-option-type to match either. If the switch is not configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type, this is a finding.
Configure the switch to drop all inbound IPv6 packets containing an undefined option type value regardless of whether they appear in a Hop-by-Hop or Destination Option header as shown in the example below. SW1(config)#ipv6 access-list FILTER_IPV6 SW1(config-ipv6-acl)#deny any any dest-option-type 2 SW1(config-ipv6-acl)#deny any any dest-option-type 3 SW1(config-ipv6-acl)#deny any any dest-option-type 6 SW1(config-ipv6-acl)#deny any any dest-option-type 9 SW1(config-ipv6-acl)#deny any any dest-option-type 10 SW1(config-ipv6-acl)#deny any any dest-option-type 11 SW1(config-ipv6-acl)#deny any any dest-option-type 12 SW1(config-ipv6-acl)#deny any any dest-option-type 13 SW1(config-ipv6-acl)#deny any any dest-option-type 14 SW1(config-ipv6-acl)#deny any any dest-option-type 16 … SW1(config-ipv6-acl)#deny any any dest-option-type 34 SW1(config-ipv6-acl)#deny any any dest-option-type 36 SW1(config-ipv6-acl)#deny any any dest-option-type 37 SW1(config-ipv6-acl)#deny any any dest-option-type 39 … SW1(config-ipv6-acl)#deny any any dest-option-type 47 SW1(config-ipv6-acl)#deny any any dest-option-type 49 … SW1(config-ipv6-acl)#deny any any dest-option-type 255 SW1(config-ipv6-acl)#permit … … … … SW1(config-ipv6-acl)#deny ipv6 any any log SW1(config-ipv6-acl)#exit SW1(config)#int g1/0 SW1(config-if)#ipv6 traffic-filter FILTER_IPV6