1． 利用接入层交换机端口ACL对一些特殊需求进行限制：
可以利用port acl 进行同网段不通机器间通信限制；也可以限制某网段内某些机器不能访问某种资源，而别的机器可以。具体配置同普通ACL，将其应用在接入层交换机某个端口上即可。
2． CISCO的ACL对分片数据的处理行为：
对于分片的TCP数据，CISCO按以下方式处理：
如果是permit条目，对于分片的数据只检查3层中的内容。
如果是deny条目，则永远也不会匹配分片数据。
简单记录
Reply
Category Archives: 交换机技术
2960 Configuring DHCP Features(IOS12.2)
DHCP Snooping
DHCP snooping is a DHCP security feature that provides network security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding database, also referred to as a DHCP snooping binding table. For more information about this database, see the "Displaying DHCP Snooping Information" section.
DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. You use DHCP snooping to differentiate between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch.
Note 
For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces.
An untrusted DHCP message is a message that is received from outside the network or firewall. When you use DHCP snooping in a service-provider environment, an untrusted message is sent from a device that is not in the service-provider network, such as a customer’s switch. Messages from unknown devices are untrusted because they can be sources of traffic attacks.
The DHCP snooping binding database has the MAC address, the IP address, the lease time, the binding type, the VLAN number, and the interface information that corresponds to the local untrusted interfaces of a switch. It does not have information regarding hosts interconnected with a trusted interface.
In a service-provider network, a trusted interface is connected to a port on a device in the same network. An untrusted interface is connected to an untrusted interface in the network or to an interface on a device that is not in the network.
When a switch receives a packet on an untrusted interface and the interface belongs to a VLAN in which DHCP snooping is enabled, the switch compares the source MAC address and the DHCP client hardware address. If the addresses match (the default), the switch forwards the packet. If the addresses do not match, the switch drops the packet.
The switch drops a DHCP packet when one of these situations occurs:
•A packet from a DHCP server, such as a DHCPOFFER, DHCPACK, DHCPNAK, or DHCPLEASEQUERY packet, is received from outside the network or firewall.
•A packet is received on an untrusted interface, and the source MAC address and the DHCP client hardware address do not match.
•The switch receives a DHCPRELEASE or DHCPDECLINE broadcast message that has a MAC address in the DHCP snooping binding database, but the interface information in the binding database does not match the interface on which the message was received.
•A DHCP relay agent forwards a DHCP packet that includes a relay-agent IP address that is not 0.0.0.0, or the relay agent forwards a packet that includes option-82 information to an untrusted port.
If the switch is an aggregation switch supporting DHCP snooping and is connected to an edge switch that is inserting DHCP option-82 information, the switch drops packets with option-82 information when packets are received on an untrusted interface. If DHCP snooping is enabled and packets are received on a trusted port, the aggregation switch does not learn the DHCP snooping bindings for connected devices and cannot build a complete DHCP snooping binding database.
When an aggregation switch can be connected to an edge switch through an untrusted interface and you enter the ip dhcp snooping information option allow-untrusted (12.1貌似还不支持)global configuration command, the aggregation switch accepts packets with option-82 information from the edge switch. The aggregation switch learns the bindings for hosts connected through an untrusted switch interface. The DHCP security features can still be enabled on the aggregation switch while the switch receives packets with option-82 information on untrusted input interfaces to which hosts are connected. The port on the edge switch that connects to the aggregation switch must be configured as a trusted interface.
Option-82 Data Insertion
In residential, metropolitan Ethernet-access environments, DHCP can centrally manage the IP address assignments for a large number of subscribers. When the DHCP option-82 feature is enabled on the switch, a subscriber device is identified by the switch port through which it connects to the network (in addition to its MAC address). Multiple hosts on the subscriber LAN can be connected to the same port on the access switch and are uniquely identified.
Note The DHCP option-82 feature is supported only when DHCP snooping is globally enabled and on the VLANs to which subscriber devices using this feature are assigned.
Figure 19-1 is an example of a metropolitan Ethernet network in which a centralized DHCP server assigns IP addresses to subscribers connected to the switch at the access layer. Because the DHCP clients and their associated DHCP server do not reside on the same IP network or subnet, a DHCP relay agent (the Catalyst switch) is configured with a helper address to enable broadcast forwarding and to transfer DHCP messages between the clients and the server.
Figure 19-1 DHCP Relay Agent in a Metropolitan Ethernet Network
When you enable the DHCP snooping information option 82 on the switch, this sequence of events occurs:
•The host (DHCP client) generates a DHCP request and broadcasts it on the network.
="pBu1_Bullet1">•
•If the IP address of the relay agent is configured, the switch adds this IP address in the DHCP packet.
•The switch forwards the DHCP request that includes the option-82 field to the DHCP server.
•The DHCP server receives the packet. If the server is option-82-capable, it can use the remote ID, the circuit ID, or both to assign IP addresses and implement policies, such as restricting the number of IP addresses that can be assigned to a single remote ID or circuit ID. Then the DHCP server echoes the option-82 field in the DHCP reply.
•The DHCP server unicasts the reply to the switch if the request was relayed to the server by the switch. The switch verifies that it originally inserted the option-82 data by inspecting the remote ID and possibly the circuit ID fields. The switch removes the option-82 field and forwards the packet to the switch port that connects to the DHCP client that sent the DHCP request.
When the previously described sequence of events occurs, the values in these fields in Figure 19-2 do not change:
•Circuit ID suboption fields
–Suboption type
–Length of the suboption type
–Circuit ID type
–Length of the circuit ID type
•Remote ID suboption fields
–Suboption type
–Length of the suboption type
–Remote ID type
–Length of the remote ID type
In the port field of the circuit ID suboption, the port numbers start at 3. For example, on a switch with 24 10/100 ports and small form-factor pluggable (SFP) module slots, port 3 is the Fast Ethernet 0/1 port, port 4 is the Fast Ethernet 0/2 port, and so forth. Port 27 is the SFP module slot 0/1, and so forth.
Figure 19-2 shows the packet formats for the remote ID suboption and the circuit ID suboption. The switch uses the packet formats when DHCP snooping is globally enabled and when the ip dhcp snooping information option global configuration command is entered.
Figure 19-2 Suboption Packet Formats
http://www.cisco.com/en/US/products/ps6406/products_configuration_guide_chapter09186a008055fc98.html
更多
[原创]VLAN间访问控制的几种方法总结.
VAN10,VLAN20,VLAN30
要求 VLAN20,30都能访问VLAN10,但20,30之间不能相互访问.
1.用策略路由控制,让去往VLAN10的被路由到正确接口,其他的都被送到丢弃口
access-list 100 permit ip any 192.168.10.0 0.0.0.255
route-map tovlan1 permit 10
match address 100
set default interface f 0/0.10
route-map tovlan1 permit 20
set default interface null0
interface f0/0.20
ip policy route-map tovlan1
interface f0/0.30
ip policy route-map tovlan1
上面配置由于存在显式路由(直连的) 用缺省借口的方法不行
(PBR中:
set ip next-hop 不检查是否存在显式路由,只检查下一跳是否可达
set interface 检查是否存在显式路由,必须存在才能正常
set ip default next-hp 检查是否存在显式路由,必须不存在才正常
set default interface 检查是否存在显式路由,必须不存在才正常
)
*Mar 1 02:25:10.443: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy match
*Mar 1 02:25:10.443: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy rejected(explicit route) – normal forwarding
*Mar 1 02:25:10.459: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy match
*Mar 1 02:25:10.459: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1
R1#, len 100, FIB policy rejected(explicit route) – normal forwarding
*Mar 1 02:25:10.475: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy match
*Mar 1 02:25:10.475: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy rejected(explicit route) – normal forwarding
*Mar 1 02:25:10.551: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy match
*Mar 1 02:25:10.551: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy rejected(explicit route) – normal forwarding
改成:
route-map govlan1 permit 10
match address 100
set interface f 0/0.10
route-map govlan1 permit 20
set interface null0
后正常
*Mar 1 02:35:31.059: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy match
*Mar 1 02:35:31.063: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1 (FastEthernet0/0.10), len 100, FIB policy routed
*Mar 1 02:35:31.111: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy match
*Mar 1 02:35:31.111: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1 (FastEthernet0/0.10), len 100, FIB policy routed
*Mar 1 02:35:31.139: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy match
*Mar 1 02:35:31.139: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1 (FastEthernet0/0.10)
R1#, len 100, FIB policy routed
*Mar 1 02:35:31.159: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy match
*Mar 1 02:35:31.159: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1 (FastEthernet0/0.10), len 100, FIB policy routed
*Mar 1 02:35:31.187: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1, len 100, FIB policy match
*Mar 1 02:35:31.187: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.10.1 (FastEthernet0/0.10), len 100, FIB policy routed
R1#
*Mar 1 02:35:35.135: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1, len 100, FIB policy match
*Mar 1 02:35:35.139: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1 (Null0), len 100, FIB policy routed(drop)
R1#
*Mar 1 02:35:37.171: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1, len 100, FIB policy match
*Mar 1 02:35:37.175: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1 (Null0), len 100, FIB policy routed(drop)
R1#
*Mar 1 02:35:39.183: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1, len 100, FIB policy match
*Mar 1 02:35:39.187: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1 (Null0), len 100, FIB policy routed(drop)
R1#
*Mar 1 02:35:41.179: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1, len 100, FIB policy match
*Mar 1 02:35:41.183: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1 (Null0), len 100, FIB policy routed(drop)
R1#
*Mar 1 02:35:43.187: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1, len 100, FIB policy match
*Mar 1 02:35:43.191: IP: s=192.168.20.1 (FastEthernet0/0.20), d=192.168.30.1 (Null0), len 100, FIB policy routed(drop)
2.用访问列表控制:
R1#sh run
Building configuration…
Current configuration : 1245 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
no ip address
speed 100
full-duplex
!
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 192.168.10.254 255.255.255.0
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip address 192.168.20.254 255.255.255.0
ip access-group 120 in
!
interface FastEthernet0/0.30
encapsulation dot1Q 30
ip address 192.168.30.254 255.255.255.0
ip access-group 130 in
!
interface Serial1/0
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/3
no ip address
shutdown
serial restart-delay 0
!
ip http server
!
!
!
access-list 120 deny ip any 192.168.30.0 0.0.0.255
access-list 120 permit ip any any
access-list 130 deny ip any 192.168.20.0 0.0.0.255
access-list 130 permit ip any any
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
logging synchronous
line aux 0
line vty 0 4
!
!
end
3.使用Pvlan
待续
4.三层交换机上,用VLAN间ACL
access-list 120 permit ip any 192.168.30.0 0.0.0.255
access-list 130 permit ip any 192.168.20.0 0.0.0.255
vlan access-map deny20-30 100
match ip add 120
action drop
exit
vlan filter deny20-30 vlan-list 20
vlan access-map deny30-20 101
match ip add 130
action drop
exit
vlan filter deny30-20 vlan-list 30
上面配置由于没
有设备无法验证.
show vlan里的一些状态提示[831]
Usage Guidelines
Each Ethernet switch port and Ethernet repeater group belong to only one VLAN. Trunk ports can be on multiple VLANs.
If you shut down a VLAN using the state suspend or the state active command, these values appear in the Status field:
•suspended—VLAN is suspended.
•active—VLAN is active.
If you shut down a VLAN using the shutdown command, these values appear in the Status field:
•act/lshut—VLAN status is active but shut down locally.
•sus/lshut—VLAN status is suspended but shut down locally.
This is an example of the ouput for a VLAN (VLAN0002) that is active but shut down locally:
Router# show vlanVLAN Name Status Ports---- -------------------------------- --------- -------------------------------1 default active Fa5/92 VLAN0002 act/lshut Fa5/9<...Output truncated...>If a VLAN is shut down internally, these values appear in the Status field:
•act/ishut—VLAN status is active but shut down internally.
•sus/ishut—VLAN status is suspended but shut down internally.
This is an example of the ouput for a VLAN (VLAN0002) that is active but shut down internally:
Router# show vlanVLAN Name Status Ports---- -------------------------------- --------- -------------------------------1 default active Fa5/92 VLAN0002 act/ishut Fa5/9<...Output truncated...>If a VLAN is shut down locally and internally, the value that is displayed in the Status field is act/ishut or sus/ishut. If a VLAN is shut down locally only, the value that is displayed in the Status field is act/lshut or sus/lshut.
http://www.cisco.com/en/US/products/ps6922/products_command_reference_chapter09186a00806c0fb4.html
双工问题
Note: This section is only applicable for 10/100/1000 Mbps (1000BASE-T) NICs, and not 1000BASE-X NICs.
Table 1—Autonegotiation Valid Configuration Table
|
Configuration NIC (Speed/Duplex) |
Configuration Switch (Speed/Duplex) |
Resulting NIC Speed/Duplex |
Resulting Catalyst Speed/Duplex |
Comments |
|---|---|---|---|---|
|
AUTO |
AUTO |
1000 Mbps, Full-duplex |
1000 Mbps, Full-duplex |
Assuming maximum capability of Catalyst switch, and NIC is 1000 Mbps, full-duplex. |
|
1000 Mbps, Full-duplex |
AUTO |
1000 Mbps, Full-duplex |
1000 Mbps, Full-duplex |
Link is established, but the switch does not see any autonegotiation information from NIC. Since Catalyst switches support only full-duplex operation with 1000 Mbps, they default to full-duplex, and this happens only when operating at 1000 Mbps. |
|
1000 Mbps, Full-duplex |
1000 Mbps, Full-duplex |
1000 Mbps, Full-duplex |
1000 Mbps, Full-duplex |
Correct Manual Configuration |
|
100 Mbps, Full-duplex |
1000 Mbps, Full-duplex |
No Link |
No Link |
Neither side establishes link, due to speed mismatch |
|
100 Mbps, Full-duplex |
AUTO |
100 Mbps, Full-duplex |
100 Mbps, Half-duplex |
Duplex Mismatch 1 |
|
AUTO |
100 Mbps, Full-duplex |
100 Mbps, Half-duplex |
100 Mbps, Full-duplex |
Duplex Mismatch 1 |
|
100 Mbps, Full-duplex |
100 Mbps, Full-duplex |
100 Mbps, Full-duplex |
100 Mbps, Full-duplex |
Correct Manual Configuration2 |
|
100 Mbps, Half-duplex |
AUTO |
100 Mbps, Half-duplex |
100 Mbps, Half-duplex |
Link is established, but switch does not see any autonegotiation information from NIC and defaults to half-duplex when operating at 10/100 Mbps. |
|
10 Mbps, Half-duplex |
AUTO |
10 Mbps, Half-duplex |
10 Mbps, Half-duplex |
Link is established, but switch does not see Fast Link Pulse (FLP) and defaults to 10 Mbps half-duplex. |
|
10 Mbps, Half-duplex |
100 Mbps, Half-duplex |
No Link |
No Link |
Neither side establishes link, due to speed mismatch. |
|
AUTO |
100 Mbps, Half-duplex |
100 Mbps, Half-duplex |
100 Mbps, Half-duplex |
Link is established, but NIC does not see any autonegotiation information and defaults to 100 Mbps, half-duplex. |
|
AUTO |
10 Mbps, Half-duplex |
10 Mbps, Half-duplex |
10 Mbps, Half-duplex |
Link is established, but NIC does not see FLP and defaults to 10 Mbps, half-duplex. |
1 A duplex mismatch may result in performance issues, intermittent connectivity, and loss of communication. When troubleshooting NIC issues, verify that the NIC and switch are using a valid configuration.
2 Some third-party NIC cards may fall back to half-duplex operation mode, even though both the switchport and NIC configuration have been manually configured for 100 Mbps, full-duplex. This behavior is due to the fact that NIC autonegotiation link detection is still operating when the NIC has been manually configured. This causes duplex inconsistency between the switchport and the NIC. Symptoms include poor port performance and frame check sequence (FCS) errors that increment
on the switchport. To tro
ubleshoot this issue, try manually configuring the switchport to 100 Mbps, half-duplex. If this action resolves the connectivity problems,爕ou may be running into this NIC issue. Try updating to the latest drivers for your NIC, or contact your NIC card vendor for additional support.
As indicated in the Autonegotiation Valid Configuration Table above, manually setting the speed and duplex for full-duplex on one link partner results in a duplex mismatch. This is the result of disabling autonegotiation on one link partner while the other link partner defaults to a half-duplex configuration. A duplex mismatch results in slow performance, intermittent connectivity, data link errors, and other issues. If the intent is not to use autonegotiation, both link partners must be manually configured for speed and duplex for full-duplex settings.
Recommended Port Configuration (Autonegotiation or Manual Configuration)
There are many opinions on the subject of autonegotiation. Previously, many engineers advised customers not to use autonegotiation with any switch-connected device. However, improvements in the interoperation of autonegotiation and the maturity of the technology has recently changed the view of using autonegotiation. In addition, performance issues due to duplex mismatches, caused by the manual setting of speed and duplex on only one link partner, have become more common. Because of these recent issues, the use of autonegotiation is regarded as a valid practice.
EtherChannel and Trunking Between Catalyst Switches and NICs
EtherChannel can be configured dynamically using Port Aggregation Protocol (PAgP), and trunking can also be configured dynamically using Dynamic Trunking Protocol (DTP). Both PAgP and DTP are Cisco proprietary protocols and supported only on Catalyst switches. If you want to configure EtherChannel or trunking between Catalyst switches and NICs, it is recommended that you configure these features statically, as other vendor NICs may not support PAgP and DTP. On Catalyst switches, configure the EtherChannel mode to on and trunking mode to nonegotiate, which disables the PAgP and DTP protocols. If you configure the switch port with auto or desirable mode, you may not be able to form the EtherChannel or trunk with NICs.
更多交换机与NIC之间的排错 http://www.cisco.com/warp/public/473/46.html
Why Is It That the Speed and Duplex Cannot Be Hardcoded on Only One Link Partner?
关于导致多播问题的一些案例
Router Does Not Forward Multicast Packets to Host Due to RPF Failure
Background Information
When troubleshooting multicast routing, the primary concern is the source address. Multicast has a concept of Reverse Path Forwarding check (RPF check). When a multicast packet arrives on an interface, the RPF process checks to ensure that this incoming interface is the outgoing interface used by unicast routing to reach the source of the multicast packet. This RPF check process prevents loops. Multicast routing does not forward a packet unless the source of the packet passes a reverse path forwarding (RPF) check. Once a packet passes this RPF check, multicast routing forwards the packet based only upon the destination address.
Like unicast routing, multicast routing has several available protocols, such as Protocol Independent Multicast dense mode (PIM-DM), PIM sparse mode (PIM-SM), Distance Vector Multicast Routing Protocol (DVMRP), Multicast Border Gateway Protocol (MBGP), and Multicast Source Discovery Protocol (MSDP). The case studies in this document walk you through the process of troubleshooting various problems. You will see which commands are used to quickly pinpoint the problem and learn how to resolve it. The case studies listed here are generic across the protocols, except where noted.
Router Does Not Forward Multicast Packets to Host Due to RPF Failure
This section provides a solution to the common problem of an IP multicast Reverse Path Forwarding (RPF) failure. This network diagram is used as an example.
In the figure above, multicast packets come into E0/0 of Router 75a from a server whose IP address is 1.1.1.1 and sends to group 224.1.1.1. This is known as an (S,G) or (1.1.1.1, 224.1.1.1).
Diagnose the Problem
Hosts directly connected to Router 75a receive the multicast feed, but hosts directly connected to Router 72a do not. First, issue the show ip mroute 224.1.1.1 command to see what is going on with Router 75a. This command examines the multicast route (mroute) for the group address 224.1.1.1:
75a#show ip mroute 224.1.1.1IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - PrunedR - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPTM - MSDP created entry, X - Proxy Join Timer RunningA - Advertised via MSDPTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: DIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00(1.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TAIncoming interface: Ethernet0/0, RPF nbr 0.0.0.0Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
Since the router is running PIM dense mode (we know it is dense mode because of the D flag), ignore the *,G entry and focus on the S,G entry. This entry tells you that the multicast packets are sourced from a server whose address is 1.1.1.1, which sends to a multicast group of 224.1.1.1. The packets are coming in the Ethernet0/0 interface and are forwarded out the Ethernet0/1 interface. This is a perfect scenario.
Issue the show ip pim neighbor command to see whether Router 72a is showing the upstream router (75a) as a PIM neighbor:
ip22-72a#show ip pim neighborPIM Neighbor Table Neighbor Address InterfaceUptime Expires Ver Mode 2.1.1.1Ethernet3/1 2d00h 00:01:15 v2
From the show ip pim neighbor command output, the PIM neighborship look good.
Use this show ip mroute command to see whether Router 72a has good mroute:
ip22-72a#show ip mroute 224.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report, Z - Multicast TunnelY - Joined MDT-data group, y - Sending to MDT-data groupOutgoing interface flags: H - Hardware switched, A - Assert winnerTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DCIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet3/1, Forward/Dense, 00:10:42/00:00:00Ethernet3/2, Forward/Dense, 00:10:42/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags:Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0Outgoing interface list:Ethernet3/1, Forward/Dense, 00:01:10/00:00:00Ethernet3/2, Forward/Dense, 00:00:16/00:00:00 ip22-72a#
You can see from the show ip mroute 224.1.1.1 command that the incoming interface is Ethernet2/0, while Etheret3/1 is expected.
Issue the show ip mroute 224.1.1.1 count command to see if any multicast traffic for this group arrives to the Router 72a and what happens next:
ip22-72a#show ip mroute 224.1.1.1 countIP Multicast Statistics3 routes using 2032 bytes of memory2 groups, 0.50 average sources per groupForwarding Counts: Pkt Count/Pkts per second/AvgPkt Size/Kilobits per secondOther counts: Total/RPF failed/Other drops(OIF-null,rate-limit etc)Group: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471Source: 1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0ip22-72a#
You can see from the Other counts that traffic gets dropped due to RPF failure: total 471 drops, due to RPF failure – 471…
Issue the show ip rpf <source> command to see if there is an RPF error:
ip22-72a#show ip rpf 1.1.1.1RPF information for ? (1.1.1.1)RPF interface: Ethernet2/0RPF neighbor: ? (0.0.0.0)RPF route/mask: 1.1.1.1/32RPF type: unicast (static)RPF recursion count: 0Doing distance-preferred lookups across tablesip22-72a#
Cisco IOS® calculates the RPF interface in this way. Possible sources of RPF information are Unicast Routing Table, MBGP routing table, DVMRP routing table and Static Mroute table. When you calculate the RPF interface, primarily administrative distance is used to determine exactly which source of information the RPF calculation is based on. The specific rules are:
-
All preceding sources of RPF data are searched for a match on the source IP address. When using Shared Trees, the RP address is used instead of the source address.
-
If more than one matching route is found, the route with the lowest administrative distance is used.
-
If the admin distances are equal, then this order of preference is used:
-
Static mroutes
-
DVMRP routes
-
MBGP routes
-
Unicast routes
-
-
If multiple entries for a route occur within the same route table, the longest match route is used.
The show ip rpf 1.1.1.1 command output shows the RPF interface being E2/0, but the incoming interface should be E3/1.
Issue the show ip route 1.1.1.1 command to see why the RPF interface is different from what was expected.
ip22-72a#show ip route 1.1.1.1Routing entry for 1.1.1.1/32Known via "static", distance 1, metric 0 (connected)Routing Descriptor Blocks: * directly connected, via Ethernet2/0Route metric is 0, traffic share count is 1
You can see from this show ip route 1.1.1.1 command output that there is a static /32 route, which makes the wrong interface to be chosen as RPF interface.
Issue some further debug commands:
ip22-72a#debug ip mpacket 224.1.1.1*Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface*Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface*Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface*Jan 14 09:45:33.120: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface
The packets are coming in on E3/1, which is correct. However, they are being dropped because that is not the interface the unicast routing table uses for the RPF check.
Note: Debugging packets is dangerous. Pakcet debugging triggers process switching of the multicast pakcets, which is CPU intensive. Also, packet debugging can produce huge output which can hang the router completely due to slow output to the console port. Befor debugging packet, special care must be taken to disable logging output to the console, and enable logging to the memory buffer. In order to achieve this, configure no logging console and logging buffered debugging. The results of the debug can be seen with the show logging command.
Possible Fixes
You can either change the unicast routing table to satisfy this requirement or you can add a static mroute to force multicast to RPF out a particular interface, regardless of what the unicast routing table states. Add a static mroute:
ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1
This static mroute states that to get to the address 1.1.1.1, for RPF, use 2.1.1.1 as the next hop, which is out interface E3/1.
ip22-72a#show ip rpf 1.1.1.1RPF information for ? (1.1.1.1)RPF interface: Ethernet3/1RPF neighbor: ? (2.1.1.1)RPF route/mask: 1.1.1.1/32RPF type: static mrouteRPF recursion count: 0Doing distance-preferred lookups across tablesThe output of show ip mroute and debug ip mpacket looks good,the number of sent packets in the show ip mroute count increases and HostA receives packets.ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00(1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 2.1.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00ip22-72a#show ip mroute 224.1.1.1 countIP Multicast Statistics3 routes using 2378 bytes of memory2 groups, 0.50 average sources per groupForwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per secondOther counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019 Source: 1.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0 ip22-72a#show ip mroute 224.1.1.1 countIP Multicast Statistics3 routes using 2378 bytes of memory2 groups, 0.50 average sources per groupForwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per secondOther counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026 Source: 1.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0ip22-72a#ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 10:18:29.951: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward
不支持硬件交换的数据类型
Software Switching
Software switching occurs when traffic cannot be processed in hardware. The following types of exception packets are processed in software at a much slower rate:
 |
Note Packets that use TCP header options are switched in hardware because they do not affect the forwarding decision. |
- Packets that have an expiring IP time-to-live (TTL) counter
- Packets that are forwarded to a tunnel interface
- Packets that arrive with non-supported encapsulation types
- Packets that are routed to an interface with non-supported encapsulation types
- Packets that exceed the MTU of an output interface and must be fragmented
- Packets that require an IGMP redirect to be routed
- 802.3 Ethernet packets
一个关于IOS软件引起的SPT 端口问题
本来是看一个题目觉得奇怪的,于是去查CISCO 文档,结果发现那个题目就是CISCO 文档上的东西.
只是这个文档本来是发布IOS bug的一个通告,下面是关键内容.
Loopback Test: Test for a spanning-tree BPDU error. A crossover cable should be connected between two unused access ports. In this case, FastEthernet0/1 and FastEthernet0/2 are configured as access ports and are connected by a crossover cable. See RJ-45 Cables for information on Ethernet RJ-45 crossover pinouts. The interface configuration is shown below:
Switch#show run interface FastEthernet0/1Building configuration...Current configuration : 72 bytes!interface FastEthernet0/1switchport mode accessno ip addressendSwitch#show run interface FastEthernet0/2Building configuration...Current configuration : 72 bytes!interface FastEthernet0/2switchport mode accessno ip addressend
If, after 30 seconds, one of the port LEDs turns amber and the other stays green, the switch is working correctly, either because it does not have the problem or already has the Cisco IOS software upgrade that corrects the problem. If, after 30 seconds, both of the LEDs turn green and flash rapidly, the Cisco IOS software will need to be upgraded. This can also be verified by looking at the output from the following commands. If the switch is working correctly, the number of BPDUs received on the blocked port will be a non-zero number and will increase every two seconds, using the default timers
WORKING_Switch#show spanning-tree interface FastEthernet 0/1 detailPort 1 (FastEthernet0/1) of VLAN0001 is forwardingPort path cost 19, Port priority 128, Port Identifier 128.1.Designated root has priority 32769, address 000a.4107.7400Designated bridge has priority 32769, address 000a.4107.7400Designated port id is 128.1, designated path cost 0Timers: message age 0, forward delay 0, hold 0Number of transitions to forwarding state: 1BPDU: sent 237, received 1^^^^^^^^^^^^^^^^^^^^^^^^^^ Port is forwarding and sending BPDUs correctly.WORKING_Switch#show spanning-tree interface FastEthernet 0/2 detailPort 2 (FastEthernet0/2) of VLAN0001 is blockingPort path cost 19, Port priority 128, Port Identifier 128.2.Designated root has priority 32769, address 000a.4107.7400Designated bridge has priority 32769, address 000a.4107.7400Designated port id is 128.1, designated path cost 0Timers: message age 1, forward delay 0, hold 0Number of transitions to forwarding state: 0BPDU: sent 1, received 242^^^^^^^^^^^^^^^^^^^^^^^^^^ Port is blocking and receiving BPDUs correctly.
On a switch that is experiencing the problem, the number of BPDUs received on each port will stay at 0 (zero),
and both ports will be forwarding.
PROBLEM_Switch#show spanning-tree interface FastEthernet 0/1 detailPort 1 (FastEthernet0/1) of VLAN0001 is forwardingPort path cost 19, Port priority 128, Port Identifier 128.1.Designated root has priority 32769, address 000a.4107.7400Designated bridge has priority 32769, address 000a.4107.7400Designated port id is 128.1, designated path cost 0Timers: message age 0, forward delay 0, hold 0Number of transitions to forwarding state: 1BPDU: sent 24, received 0^^^^^^^^^^^^^^^^^^^^^^^^^^ No BPDUs received. Port is forwarding.PROBLEM_Switch#show spanning-tree interface FastEthernet 0/2 detailPort 2 (FastEthernet0/2) of VLAN0001 is forwardingPort path cost 19, Port priority 128, Port Identifier 128.2.Designated root has priority 32769, address 000a.4107.7400Designated bridge has priority 32769, address 000a.4107.7400Designated port id is 128.2, designated path cost 0Timers: message age 0, forward delay 0, hold 0Number of transitions to forwarding state: 1BPDU: sent 26, received 0^^^^^^^^^^^^^^^^^^^^^^^^^^ No BPDUs received. Port is forwarding.考811的战友应该对这个不陌生了原文点这里
AAA Configuring Authentication
Configuring Authentication
Authentication verifies users before they are allowed access to the network and network services. The Cisco IOS software implementation of authentication is divided into two main categories:
• AAA Authentication Methods Configuration Task List
• Non-AAA Authentication Methods
Authentication, for the most part, is implemented through the AAA security services. Cisco recommends that, whenever possible, AAA be used to implement authentication.
This chapter describes both AAA and non-AAA authentication methods. For authentication configuration examples, refer to the "Authentication Examples" section at the end of this chapter. For a complete description of the AAA commands used in this chapter, refer to the "Authentication, Authorization, and Accounting (AAA)" part of the Cisco IOS Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature, or refer to the software release notes for a specific release. For more information, see the section "Identifying Supported Platforms" in the chapter "Using Cisco IOS Software."
In This Chapter
This chapter contains the following sections:
• Named Method Lists for Authentication
• AAA Authentication Methods Configuration Task List
• Non-AAA Authentication Methods
Named Method Lists for Authentication
To configure AAA authentication, you must first define a named list of authentication methods, and then apply that list to various interfaces. The method list defines the types of authentication to be performed and the sequence in which they will be performed; it must be applied to a specific interface before any of the defined authentication methods will be performed. The only exception is the default method list (which is named "default"). The default method list is automatically applied to all interfaces except those that have a named method list explicitly defined. A defined method list overrides the default method list.
A method list is a sequential list describing the authentication methods to be queried in order to authenticate a user. Method lists enable you to designate one or more security protocols to be used for authentication, thus ensuring a backup system for authentication in case the initial method fails. Cisco IOS software uses the first listed method to authenticate users. If that method fails to respond, the Cisco IOS software selects the next authentication method listed in the method list. This process continues until there is successful communication with a listed authentication method, or all methods defined in the method list are exhausted.
It is important to note that the Cisco IOS software attempts authentication with the next listed authentication method only when there is no response from the previous method. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops and no other authentication methods are attempted.
This section contains the following subsections:
• Method Lists and Server Groups
• AAA Authentication General Configuration Procedure
Method Lists and Server Groups
A server group is a way to group existing RADIUS or TACACS+ server hosts for use in method lists. Figure 2 shows a typical AAA network configuration that includes four security servers: R1 and R2 are RADIUS servers and T1 and T2 are TACACS+ servers. R1 and R2 make up the group of RADIUS server. T1 and T2 make up the group of TACACS+ servers.
Figure 2 Typical AAA Network Configuration
ght="288" alt="" width="57
9" border="0" src="http://www.cisco.com/univercd/illus/s/46/s6746.jpg" />
Using server groups, you can specify a subset of the configured server hosts and use them for a particular service. For example, server groups allow you to define R1 and R2 as a server group, and define T1 and T2 as a separate server group. For example, you can specify R1 and T1 in the method list for authentication login, while specifying R2 and T2 in the method list for PPP authentication.
Server groups also can include multiple host entries for the same server, as long as each entry has a unique identifier. The combination of an IP address and a UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. In other words, this unique identifier enables RADIUS requests to be sent to different UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, authentication—the second host entry configured acts as failover backup to the first one. Using this example, if the first host entry fails to provide accounting services, the network access server will try the second host entry configured on the same device for accounting services. (The RADIUS host entries will be tried in the order in which they are configured.)
For more information about configuring server groups and about configuring server groups based on Dialed Number Identification Service (DNIS) numbers, refer to the "Configuring RADIUS" or "Configuring TACACS+" chapter.
Method List Examples
Suppose the system administrator has decided on a security solution where all interfaces will use the same authentication methods to authenticate PPP connections. In the RADIUS group, R1 is contacted first for authentication information, then if there is no response, R2 is contacted. If R2 does not respond, T1 in the TACACS+ group is contacted; if T1 does not respond, T2 is contacted. If all designated servers fail to respond, authentication falls to the local username database on the access server itself. To implement this solution, the system administrator would create a default method list by entering the following command:
aaa authentication ppp default group radius group tacacs+ local
In this example, "default" is the name of the method list. The protocols included in this method list are listed after the name, in the order they are to be queried. The default list is automatically applied to all interfaces.
When a remote user attempts to dial in to the network, the network access server first queries R1 for authentication information. If R1 authenticates the user, it issues a PASS response to the network access server and the user is allowed to access the network. If R1 returns a FAIL response, the user is denied access and the session is terminated. If R1 does not respond, then the network access server processes that as an ERROR and queries R2 for authentication information. This pattern would continue through the remaining designated methods until the user is either authenticated or rejected, or until the session is terminated.
It is important to remember that a FAIL response is significantly different from an ERROR. A FAIL means that the user has not met the criteria contained in the applicable authentication database to be successfully authenticated. Authentication ends with a FAIL response. An ERROR means that the security server has not responded to an authentication query. Because of this, no authentication has been attempted. Only when an ERROR is detected will AAA select the next authentication method defined in the authentication method list.
Suppose the system administrator wants to apply a method list only to a particular interface or set of interfaces. In this case, the system administrator creates a named method list and then applies this named list to the applicable interfaces. The following example shows how the system administrator can implement an authentication method that will be applied only to interface 3:
aaa authentication ppp default group radius group tacacs+ local
aaa authentication ppp apple group radius group tacacs+ local none
(To specify that the authentication should succeed even if all methods return an error,
specify none as the final method in the command line. )
interface async 3
ppp authentication chap apple
In this example, "apple" is the name of the method list, and the protocols included in this method list are listed after the name in the order in which they are to be performed. After the method list has been created, it is applied to the appropriate interface. Note that the method list name (apple) in both the AAA and PPP authentication commands must match.
In the following example, the system administrator uses server groups to specify that only R2 and T2 are valid servers for PPP authentication. To do this, the administrator must define specific server groups whose members are R2 (172.16.2.7) and T2 (172.16.2.77), respectively. In this example, the RADIUS server group "rad2only" is defined as follows using the aaa group server command:
aaa group server radius rad2only
server 172.16.2.7
The TACACS+ server group "tac2only" is defined as follows using the aaa group server command:
aaa group server tacacs+ tac2only
server 172.16.2.77
The administrator then applies PPP authentication using the server groups. In this example, the default methods list for PPP authentication follows this order: group rad2only, group tac2only, and local:
aaa authentication ppp default group rad2only group tac2only local
AAA Authentication General Configuration Procedure
To configure AAA authentication, perform the following tasks:
1. Enable AAA by using the aaa new-model global configuration command. For more information about configuring AAA, refer to the chapter "AAA Overview".
2. Configure security protocol parameters, such as RADIUS, TACACS+, or Kerberos if you are using a security server. For more information about RADIUS, refer to the chapter "Configuring RADIUS". For more information about TACACS+, refer to the chapter "Configuring TACACS+". For more information about Kerberos, refer to the chapter "Configuring Kerberos".
3. Define the method lists for authentication by using an AAA authentication command.
4. Apply the method lists to a particular interface or line, if required.
AAA Authentication Methods Configuration Task List
This section discusses the following AAA authentication methods:
• Configuring Login Authentication Using AAA
• Configuring PPP Authentication Using AAA
• Configuring AAA Scalability for PPP Requests
• Configuring ARAP Authentication Using AAA
• Configuring NASI Authentication Using AAA
• Specifying the Amount of Time for Login Input
• Enabling Password Protection at the Privileged Level
• Changing the Text Displayed at the Password Prompt
• Configuring Message Banners for AAA Authentication
• Configuring AAA Packet of Disconnect
• Enabling Double Authentication
• Enabling Automated Double Authentication
Note AAA features are not available for use until you enable AAA globally by issuing the aaa new-model command. For more information about enabling AAA, refer to the "AAA Overview" chapter.
For authentication configuration examples using the commands in this chapter, refer to the section "Authentication Examples" at the end of the this chapter.