Monday, April 17, 2017
Wednesday, April 24, 2013
Tuesday, April 2, 2013
IPv6 OSPF Configuration lab
This short lab should provide some exposure to configuring OSPF for IPv6 under IOS. OSPFv3 is to IPv6 as OSPFv2 is to IPv4, and the two OSPF versions are not compatible with one another. The two protocols can be run simultaneously to support parallel (but separate) IPv6 and IPv4 routing domains, but the lab provided here will cover only OSPFv3.
Since the 2001:db8:0:3::/64 and 2001:db8:0:4::/64 subnets have no neighboring OSPFv3 routers, we'll designate the F0/1 interfaces on R3 and R4 as passive to protect against malicious or accidental adjacency formation.
Area configuration is still performed under the OSPF process. Here we'll configure area 2 as a stub since it has only one connection to the backbone. (This won't have any affect on our internal OSPF routes, but will cause the ABR R3 to inject a default route into the the area.) Be sure to apply the stub configuration to both routers 3 and 4.
IPv6 Addressing
The first step in base configuration is to enable IPv6 unicast routing:R1(config)# ipv6 unicast-routingNext we'll need to assign IPv6 addresses to the necessary interfaces. IPv6 stateless address autoconfiguration (RFC 4862) allows the interface ID portion of the address to be automatically formed from an EUI-64 address. We'll take advantage of this by appending the
eui-64 keyword to the ipv6 address command and leaving the interface ID portion of the IPv6 address zeroed.R1(config)# interface f0/1 R1(config-if)# ipv6 address 2001:db8:0:12::/64 eui-64Although we could address our serial interfaces in the same manner, setting the interface ID manually makes it easier to define the static frame relay mappings. We'll also have create frame relay mappings for the link-local (FE80::/10) addresses, so we may as well manually specify the interface IDs of those addresses as well.
R1(config)# interface s1/0 R1(config-if)# ipv6 address 2001:db8::1/64 R1(config-if)# ipv6 address fe80::1 link-localCreating IPv6 frame relay mappings is very similar to the commands issued for IPv4 addresses. The most important detail to remember is that link-local interface addresses must also be mapped, as all OSPFv3 communication takes places across these addresses.
R1(config-if)# encapsulation frame-relay R1(config-if)# no frame-relay inverse-arp R1(config-if)# frame-relay map ipv6 2001:db8::3 103 R1(config-if)# frame-relay map ipv6 2001:db8::2 103 R1(config-if)# frame-relay map ipv6 fe80::3 103 broadcast R1(config-if)# frame-relay map ipv6 fe80::2 103We can verify that each interface has both a link-local address and our configured global unicast address assigned:
R1# show ipv6 interface brief ... FastEthernet0/1 [up/up] FE80::C001:47FF:FEFD:1 2001:DB8:0:12:C001:47FF:FEFD:1 Serial1/0 [up/up] FE80::1 2001:DB8::1 ...Likewise, we can verify our frame relay mappings as we would with IPv4:
R1# show frame-relay map | include Serial1/0 Serial1/0 (up): ipv6 FE80::2 dlci 103(0x67,0x1870), static, Serial1/0 (up): ipv6 FE80::3 dlci 103(0x67,0x1870), static, Serial1/0 (up): ipv6 2001:DB8::2 dlci 103(0x67,0x1870), static, Serial1/0 (up): ipv6 2001:DB8::3 dlci 103(0x67,0x1870), static,Once all interfaces on routers have been addressed, it's a good idea to verify connectivity across individual links before moving onto OSPF configuration. You can ping global unicast IPv6 addresses just like IPv4 addresses, but notice that you are prompted for the outgoing interface when pinging a link-local address. This is because the router has no way of knowing which link you want to reach.
R1# ping fe80::2 Output Interface: serial1/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::2, timeout is 2 seconds: Packet sent with a source address of FE80::1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/18/36 ms
Configuring OSPFv3
OSPFv3 differs from its predecessor in a number of ways, as we'll see in the following configurations. The first step, of course, is to enable the OSPF process:R1(config)# ipv6 router ospf 1If you have console logging enabled, you may notice this message pop up:
%OSPFv3-4-NORTRID: OSPFv3 process 1 could not pick a router-id, please configure manuallyAlthough OSPFv3 deals solely with IPv6 addresses, it still uses 32-bit router IDs, which are expressed in dotted-decimal (IPv4) format. Since we haven't configured any IPv4 interfaces in our lab, we'll need to define the OSPFv3 router IDs manually on each router:
R1(config-rtr)# router-id 1.1.1.1Although formatted as an IPv4 address, the router ID is an arbitrary value used to identify an OSPF router to its neighbors.
Since the 2001:db8:0:3::/64 and 2001:db8:0:4::/64 subnets have no neighboring OSPFv3 routers, we'll designate the F0/1 interfaces on R3 and R4 as passive to protect against malicious or accidental adjacency formation.
R3(config-rtr)# passive-interface f0/1
R4(config-rtr)# passive-interface f0/1Next we'll need to assign interfaces to OSPF areas. Unlike OSPFv2, which used the
network command under the router process to assign subnets to areas, OSPFv3 area assignments are made under interface configuration.R1(config)# interface s1/0 R1(config-if)# ipv6 ospf 1 area 0 R1(config-if)# interface f0/1 R1(config-if)# ipv6 ospf 1 area 1Be sure to set the DR priorities appropriately for frame relay interfaces, to ensure that R3 (the multipoint hub) becomes the DR. You might also want to set the priorities for the other two frame relay routers to zero.
R3(config)# interface s1/0 R3(config-if)# ipv6 ospf priority 100Since our frame relay cloud is a non-broadcast multiaccess (NBMA) link, we'll need to manually configure our OSPF neighbors on the hub. Like area assignment, this is done under interface configuration. Each neighbor must be listed with its link-local address.
R3(config-if)# ipv6 ospf neighbor fe80::1 R3(config-if)# ipv6 ospf neighbor fe80::2Notice that the priority and neighbor configurations do not specify the OSPF process like the area assignments do; if multiple OSPFv3 processes are running, interface priority and neighbor configurations affect all of them.
Area configuration is still performed under the OSPF process. Here we'll configure area 2 as a stub since it has only one connection to the backbone. (This won't have any affect on our internal OSPF routes, but will cause the ABR R3 to inject a default route into the the area.) Be sure to apply the stub configuration to both routers 3 and 4.
R3(config)# ipv6 router ospf 1 R3(config-rtr)# area 2 stub
R4(config)# ipv6 router ospf 1 R4(config-rtr)# area 2 stub
Verification
If everything is configured properly, all routers should now have full reachability via IPv6. We can inspect a router's neighbor adjacencies with theshow ipv6 ospf neighbor command:R3# show ipv6 ospf neighbor Neighbor ID Pri State Dead Time Interface ID Interface 2.2.2.2 1 FULL/BDR 00:01:34 6 Serial1/0 1.1.1.1 1 FULL/DROTHER 00:01:44 6 Serial1/0 4.4.4.4 1 FULL/DR 00:00:33 4 FastEthernet0/0Similarly, we can inspect the IPv6 routing table of R4 to verify it has received all OSPF routes, including the default route (::/0) injected into area 2 from R3.
R4# show ipv6 route IPv6 Routing Table - 10 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external OI ::/0 [110/11] via FE80::C003:48FF:FE10:0, FastEthernet0/0 OI 2001:DB8::/64 [110/74] via FE80::C003:48FF:FE10:0, FastEthernet0/0 O 2001:DB8:0:3::/64 [110/20] via FE80::C003:48FF:FE10:0, FastEthernet0/0 C 2001:DB8:0:4::/64 [0/0] via ::, FastEthernet0/1 L 2001:DB8:0:4:C004:48FF:FE10:1/128 [0/0] via ::, FastEthernet0/1 OI 2001:DB8:0:12::/64 [110/84] via FE80::C003:48FF:FE10:0, FastEthernet0/0 C 2001:DB8:0:34::/64 [0/0] via ::, FastEthernet0/0 L 2001:DB8:0:34:C004:48FF:FE10:0/128 [0/0] via ::, FastEthernet0/0 L FE80::/10 [0/0] via ::, Null0 L FF00::/8 [0/0] via ::, Null0Beyond what was demonstrated here, you'll find the majority of OSPFv3 configuration commands are nearly identical to those of its predecessor. If you've configured OSPFv2 routing in the past and have a solid grasp of IPv6, OSPFv3 shouldn't give you any trouble.
OSPFv3 Neighbor Authentication
Most IPv4 routing protocols support some form of neighbor authentication, provided by either a plaintext password or MD5 HMAC. However, OSPFv3 (OSPF for IPv6) doesn't include any authentication capabilities of its own; instead, it relies entirely on IPsec to secure communications between neighbors. This is beneficial in simplifying the OSPFv3 protocol and standardizing its authentication mechanism.
Continuing from our OSPFv3 configuration lab, we can identify several points in the network where adding authentication would be prudent. In the real world, of course, it's considered best practice to implement authentication for all adjacencies, regardless of the apparent need.
First, because end users may be present in the 2001:db8:0:12::/64 subnet connecting R1 and R2, adjacency authentication in this subnet is critical. Second, since a diligent network engineer never trusts his service provider, we'll also implement authentication across the frame relay network. The IPsec Authentication Header (AH) protocol will be used to preserve packet integrity. Unfortunately, IOS doesn't currently support IPsec payload encryption via Encapsulating Security Payload (ESP). ESP can be configured with null encryption, but this has the same affect as configuring AH.
The first parameter to specify is the Security Policy Index (SPI). The SPI functions similarly to key numbers in a key chain, but is communicated via AH and must match between both ends of the adjacency. The SPI number is arbitrary, but must be between 256 and 4,294,967,295 (the 32-bit ceiling). We'll use the SPI of 256 for our lab.
Next we must decide on the type of authentication and the key string to use. AH provides authentication via either MD5 or SHA1, with a string length of 128 or 160 bits, respectively. Since SHA1 is the stronger algorithm, we'll choose it, and specify a random bit string as our key. Note that the key lengths must be exact: 40 hex digits (or 32 for MD5). For reasons outlined in section 7 of RFC 4552, the same keying is used for the SA in each direction between two OSPFv3 neighbors; this is in contrast to normal IPsec implementations, in which each unidirectional SA is built from its own unique keying via IKE.
Continuing from our OSPFv3 configuration lab, we can identify several points in the network where adding authentication would be prudent. In the real world, of course, it's considered best practice to implement authentication for all adjacencies, regardless of the apparent need.
First, because end users may be present in the 2001:db8:0:12::/64 subnet connecting R1 and R2, adjacency authentication in this subnet is critical. Second, since a diligent network engineer never trusts his service provider, we'll also implement authentication across the frame relay network. The IPsec Authentication Header (AH) protocol will be used to preserve packet integrity. Unfortunately, IOS doesn't currently support IPsec payload encryption via Encapsulating Security Payload (ESP). ESP can be configured with null encryption, but this has the same affect as configuring AH.
Enabling Authentication on the Interface
Currently, IOS requires IPsec for OSPFv3 be configured separate from the normal configuration of an IPsec policy; fortunately the entire configuration is accomplished with one line. As with legacy authentication, IPsec authentication can be configured either per-interface or per-area. We'll configure per-interface authentication between R1 and R2.The first parameter to specify is the Security Policy Index (SPI). The SPI functions similarly to key numbers in a key chain, but is communicated via AH and must match between both ends of the adjacency. The SPI number is arbitrary, but must be between 256 and 4,294,967,295 (the 32-bit ceiling). We'll use the SPI of 256 for our lab.
Next we must decide on the type of authentication and the key string to use. AH provides authentication via either MD5 or SHA1, with a string length of 128 or 160 bits, respectively. Since SHA1 is the stronger algorithm, we'll choose it, and specify a random bit string as our key. Note that the key lengths must be exact: 40 hex digits (or 32 for MD5). For reasons outlined in section 7 of RFC 4552, the same keying is used for the SA in each direction between two OSPFv3 neighbors; this is in contrast to normal IPsec implementations, in which each unidirectional SA is built from its own unique keying via IKE.
R1(config-if)# ipv6 ospf authentication ipsec spi 256 sha1 24e692732d80fac4f6dc2b9abfb73678ef660babIf you're feeling especially lazy, you can generate an SHA1 hash from random data with
dd and sha1sum on a Linux or UNIX box:LinuxBox$ dd if=/dev/urandom count=1024 | sha1sum 954644a966d69bc14f6148b0be865b803f3bc9c9 - 1024+0 records in 1024+0 records out 524288 bytes (524 kB) copied, 0.0940048 s, 5.6 MB/sAfter configuring authentication on FastEthernet0/1 at both routers, you may notice the OSPFv3 adjacency drop and reform. The OSPFv3 interface display verifies that SHA1 authentication is in use:
R1# show ipv6 ospf interface f0/1 FastEthernet0/1 is up, line protocol is up Link Local Address FE80::1, Interface ID 5 Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1 Network Type BROADCAST, Cost: 10 SHA1 authentication SPI 256, secure socket UP (errors: 0) Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 2.2.2.2, local address FE80::2 Backup Designated router (ID) 1.1.1.1, local address FE80::1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:03 Index 1/1/1, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 6, maximum is 6 Last flood scan time is 4 msec, maximum is 4 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 2.2.2.2 (Designated Router) Suppress hello for 0 neighbor(s)Incidentally, we can also verify the state of the IPsec AH security associations in use:
R1# show crypto ipsec sa
interface: FastEthernet0/1
Crypto map tag: (none), local addr FE80::1
IPsecv6 policy name: OSPFv3-1-256
IPsecv6-created ACL name: FastEthernet0/1-ipsecv6-ACL
...
inbound ah sas:
spi: 0x100(256)
transform: ah-sha-hmac ,
in use settings ={Transport, }
conn id: 1, flow_id: SW:1, crypto map: (none)
no sa timing
replay detection support: N
Status: ACTIVE
...
outbound ah sas:
spi: 0x100(256)
transform: ah-sha-hmac ,
in use settings ={Transport, }
conn id: 2, flow_id: SW:2, crypto map: (none)
no sa timing
replay detection support: N
Status: ACTIVE
Enabling Authentication for the Area
Configuring authentication for an area follows the same logic as for an interface. First we enter OSFPv3 router configuration, then specify the authentication parameters for the area:R1(config)# ipv6 router ospf 1 R1(config-rtr)# area 0 authentication ipsec spi 500 sha1 954644a966d69bc14f6148b0be865b803f3bc9c9Again, the SPI is an arbitrary value, and the key string must be the appropriate length for whichever hashing method (MD5 or SHA1) is chosen. The above configuration enables IPsec authentication for all of R1's interfaces in area 0 (which in our case is just Serial1/0). We can use the
show ipv6 ospf interface and show crypto ipsec sa commands as we did in the first section to verify OSPFv3 authentication is in use. The show crypto ipsec policy also provides a convenient overview of the authentication policies in use:R1# show crypto ipsec policy Crypto IPsec client security policy data Policy name: OSPFv3-1-256 Policy refcount: 1 Inbound AH SPI: 256 (0x100) Outbound AH SPI: 256 (0x100) Inbound AH Key: 24E692732D80FAC4F6DC2B9ABFB73678EF660BAB Outbound AH Key: 24E692732D80FAC4F6DC2B9ABFB73678EF660BAB Transform set: ah-sha-hmac Crypto IPsec client security policy data Policy name: OSPFv3-1-500 Policy refcount: 1 Inbound AH SPI: 500 (0x1F4) Outbound AH SPI: 500 (0x1F4) Inbound AH Key: 954644A966D69BC14F6148B0BE865B803F3BC9C9 Outbound AH Key: 954644A966D69BC14F6148B0BE865B803F3BC9C9 Transform set: ah-sha-hmac
Friday, January 18, 2013
Friday, March 2, 2012
FRAME RELAY
Frame Relay is a high-performance wide-area network (WAN) protocol that operates at the physical and data link layers of the Open System Interconnection (OSI) reference model.
Frame Relay was originally designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well.
Frame Relay Features :
Frames Relay provides a data communications interface between user devices and network devices. This interface forms the basis for communication between user devices across a WAN.
Typical communication speeds for Frame Relay are between 56 Kbps and 2 Mbps (although lower and higher speeds are supported).
Frame Relay is considerably more efficient than X.25, the protocol for which it is often considered a replacement. Because it supports technological advances such as fibre-optic cabling and digital transmission, Frame Relay can eliminate time-consuming processes (such as error correction and flow control) that are necessary when using older, less reliable WAN media and protocols.
Frame Relay Standardisation
Internationally, Frame Relay was standardised by the International Telecommunications Union - Telecommunications Sector (ITU-T). In the United States, Frame Relay is an American National Standards Institute (ANSI) standard.
The Local Management Interface (LMI) specification, developed in 1990, further extends the functionality of Frame Relay.
Frame Relay Devices
Devices attached to a Frame Relay WAN fall into two general categories:
Data terminal equipment (DTE) -- DTE are customer-owned end node and internetworking devices. Examples of DTE devices are terminals, personal computers, routers, and bridges.
Data circuit-terminating equipment (DCE) -- DCE are carrier-owned internetworking devices. In most cases, these are packet switches (although routers or other devices can be configured as DCE as well).
DTE and DCE devices are logical entities. That is, DTE devices initiate a communications exchange, and DCE devices respond.
The following figure shows the relationship between the two categories of devices:
Frame Relay Virtual Circuits
Frame Relay provides connection-oriented data link layer communication. This service is implemented using virtual circuits.
A Frame Relay virtual circuit is a logical connection created between two data terminal equipment (DTE) devices across a Frame Relay packet-switched network (PSN).
Virtual circuits provide a bi-directional communications path from one DTE device to another. They are uniquely identified by a data link connection identifier (DLCI).
A virtual circuit can pass through any number of intermediate data circuit-terminating equipment (DCE) devices (switches) located within the Frame Relay PSN. A number of virtual circuits can be multiplexed into a single physical circuit for transmission across the network.
Frame Relay virtual circuits fall into two categories:
• Switched virtual circuit (SVC)
• Permanent virtual circuit (PVC)
Frame Relay Switched Virtual Circuits (SVCs)
A switched virtual circuit (SVC) is one of the two types of virtual circuits used in Frame Relay implementations. SVCs are temporary connections that are used when there is only sporadic data transfer between DTE devices across the Frame Relay network.
A communication session across an SVC consists of four operational states:
Call setup -- In this state, the virtual circuit between two Frame Relay DTE devices are established.
Data transfer -- In this state, data is being transmitted between the DTE devices over the virtual circuit.
Idle -- In this state, the connection between DTE devices is still active, but no data is being transferred.
Call termination -- In this state, the virtual circuit between DTE devices is terminated.
After the virtual circuit is terminated, the DTE devices must establish a new SVC if there is additional data to be exchanged.
Frame Relay Permanent Virtual Circuits (PVCs)
A permanent virtual circuit (PVC) is one of two types of virtual circuits used in Frame Relay implementations. PVCs are permanently established connections that are used when there is frequent and consistent data transfer between DTE devices across the Frame Relay network.
Communication across a PVC does not require the call setup and termination states that are used with SVCs.
PVCs are always in one of the following two operational states:
Data transfer -- In this state, data is being transmitted between the DTE devices over the virtual circuit.
Idle -- In this state, the connection between DTE devices is active, but no data is being transferred.
DTE devices can begin transferring data whenever they are ready because the circuit is permanently established.
Frame Relay Data Link Connection Identifier (DLCI)
Frame Relay virtual circuits are identified by data link connection identifiers (DLCIs). DLCI values are typically assigned by the Frame Relay service provider (for example, the Telephone Company).
Frame Relay DLCIs have local significance. That is, the values themselves are not unique in the Frame Relay WAN. Two DTE devices connected by a virtual circuit might use a different DLCI value to refer to the same connection.
The following figure shows how a single virtual circuit might be assigned a different DLCI value on each end of the connection:
Frame Relay was originally designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well.
Frame Relay Features :
Frames Relay provides a data communications interface between user devices and network devices. This interface forms the basis for communication between user devices across a WAN.
Typical communication speeds for Frame Relay are between 56 Kbps and 2 Mbps (although lower and higher speeds are supported).
Frame Relay is considerably more efficient than X.25, the protocol for which it is often considered a replacement. Because it supports technological advances such as fibre-optic cabling and digital transmission, Frame Relay can eliminate time-consuming processes (such as error correction and flow control) that are necessary when using older, less reliable WAN media and protocols.
Frame Relay Standardisation
Internationally, Frame Relay was standardised by the International Telecommunications Union - Telecommunications Sector (ITU-T). In the United States, Frame Relay is an American National Standards Institute (ANSI) standard.
The Local Management Interface (LMI) specification, developed in 1990, further extends the functionality of Frame Relay.
Frame Relay Devices
Devices attached to a Frame Relay WAN fall into two general categories:
Data terminal equipment (DTE) -- DTE are customer-owned end node and internetworking devices. Examples of DTE devices are terminals, personal computers, routers, and bridges.
Data circuit-terminating equipment (DCE) -- DCE are carrier-owned internetworking devices. In most cases, these are packet switches (although routers or other devices can be configured as DCE as well).
DTE and DCE devices are logical entities. That is, DTE devices initiate a communications exchange, and DCE devices respond.
The following figure shows the relationship between the two categories of devices:
Frame Relay Virtual Circuits
Frame Relay provides connection-oriented data link layer communication. This service is implemented using virtual circuits.
A Frame Relay virtual circuit is a logical connection created between two data terminal equipment (DTE) devices across a Frame Relay packet-switched network (PSN).
Virtual circuits provide a bi-directional communications path from one DTE device to another. They are uniquely identified by a data link connection identifier (DLCI).
A virtual circuit can pass through any number of intermediate data circuit-terminating equipment (DCE) devices (switches) located within the Frame Relay PSN. A number of virtual circuits can be multiplexed into a single physical circuit for transmission across the network.
Frame Relay virtual circuits fall into two categories:
• Switched virtual circuit (SVC)
• Permanent virtual circuit (PVC)
Frame Relay Switched Virtual Circuits (SVCs)
A switched virtual circuit (SVC) is one of the two types of virtual circuits used in Frame Relay implementations. SVCs are temporary connections that are used when there is only sporadic data transfer between DTE devices across the Frame Relay network.
A communication session across an SVC consists of four operational states:
Call setup -- In this state, the virtual circuit between two Frame Relay DTE devices are established.
Data transfer -- In this state, data is being transmitted between the DTE devices over the virtual circuit.
Idle -- In this state, the connection between DTE devices is still active, but no data is being transferred.
Call termination -- In this state, the virtual circuit between DTE devices is terminated.
After the virtual circuit is terminated, the DTE devices must establish a new SVC if there is additional data to be exchanged.
Frame Relay Permanent Virtual Circuits (PVCs)
A permanent virtual circuit (PVC) is one of two types of virtual circuits used in Frame Relay implementations. PVCs are permanently established connections that are used when there is frequent and consistent data transfer between DTE devices across the Frame Relay network.
Communication across a PVC does not require the call setup and termination states that are used with SVCs.
PVCs are always in one of the following two operational states:
Data transfer -- In this state, data is being transmitted between the DTE devices over the virtual circuit.
Idle -- In this state, the connection between DTE devices is active, but no data is being transferred.
DTE devices can begin transferring data whenever they are ready because the circuit is permanently established.
Frame Relay Data Link Connection Identifier (DLCI)
Frame Relay virtual circuits are identified by data link connection identifiers (DLCIs). DLCI values are typically assigned by the Frame Relay service provider (for example, the Telephone Company).
Frame Relay DLCIs have local significance. That is, the values themselves are not unique in the Frame Relay WAN. Two DTE devices connected by a virtual circuit might use a different DLCI value to refer to the same connection.
The following figure shows how a single virtual circuit might be assigned a different DLCI value on each end of the connection:
Thursday, January 12, 2012
Access Control Lists (ACLs)
Access Control Lists (ACLs)
Access Control List (ACL) are filters that enable you to control which routing updates or packets are permitted or denied in or out of a network. They are specifically used by network administrators to filter traffic and to provide extra security for their networks. This can be applied on routers (Cisco).
ACLs provide a powerful way to control traffic into and out of your network; this control can be as simple as permitting or denying network hosts or addresses. You can configure ACLs for all routed network protocols.
The most important reason to configure ACLs is to provide security for your network. However, ACLs can also be configured to control network traffic based on the TCP port being used.
How ACLs work
A router acts as a packet filter when it forwards or denies packets according to filtering rules. As a Layer 3 device, a packet-filtering router uses rules to determine whether to permit or deny traffic based on source and destination IP addresses, source port and destination port, and the protocol of the packet. These rules are defined using access control lists or ACLs.
To simplify how ACL or a router uses packet filtering work, imagine a guard stationed at a locked door. The guard's instruction is to allow only people whose names appear on a quest list to pass through the door. The guard is filtering people based on the condition of having their names on the authorized list.
When a packet arrives at the router, the router extracts certain information from the packet header and makes decisions according to the filter rules as to whether the packet can pass through or be dropped. Packet filtering process works at the Network layer of the Open Systems Interconnection (OSI) model, or the Internet layer of TCP/IP.
Why use ACLs
* Limits network traffic to increase network performance.
* ACLs provides traffic flow control by restricting the delivery of routing updates.
* It can be used as additional security.
* Controls which type of traffic are forwarded or blocked by the router.
* Ability to control which areas a client access.
Types of Access Control Lists
Standard access-list
Standard access lists create filters based on source addresses and are used for server based filtering. Address based access lists distinguish routes on a network you want to control by using network address number (IP). Address-based access lists consist of a list of addresses or address ranges and a statement as to whether access to or from that address is permitted or denied.
Example of the command syntax for configuring a standard numbered IP ACL:
R1(config)# access-list {1-99} {permit | deny} source-addr [source-wildcard]
i. The first value {1-99} specifies the standard ACL number range.
ii. The second value specifies whether to permit or deny the configured source IP address traffic.
iii. The third value is the source IP address that must be matched.
iv. The fourth value is the wildcard mask to be applied to the previously configured IP address to indicate the range.
Extended access lists
Extended access lists create filters based on source addresses, destination addresses, protocol, port number and other features and are used for packet based filtering for packets that traverse the network.
Example of the command syntax for configuring an extended numbered IP ACL:
Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-wildcard] [operator operand] destination-addr [destination-wildcard] [operator operand] [established]
i. Like the standard ACLs, the first value {100-199 or 2000 - 2699} specifies the ACL number range.
ii. The next value specifies whether to permit or deny according to the criteria that follows.
iii. The third value specifies protocol type ( IP, TCP, UDP, or other specific IP sub-protocols). The source IP address and wildcard mask determine traffic source. The destination IP address and its wildcard mask are used to indicate the final destination of the network traffic. When the destination IP address and mask are configured, the port number must be specified to match, either by number or by a well-known port name, otherwise all traffic to that destination will be dropped.
Standard and Extended access lists can be applied base on the use of ip access-list command.
Access lists use the deny or permit statement to define which packet is allowed or denied entry into a server or network.
Masks
Masks are used with IP addresses in IP ACLs to specify what should be permitted and denied. Masks in order to configure IP addresses on interfaces start with 255 and have the large values on the left side, for example, IP address 172.16.2.14 with a 255.255.255.0 mask. Masks for IP ACLs are the reverse, for example, mask 0.0.0.255. This is sometimes called an inverse mask or a wildcard mask. When the value of the mask is broken down into binary (0s and 1s), the results determine which address bits are to be considered in processing the traffic. A 0 indicates that the address bits must be considered (exact match); a 1 in the mask is a "no".
Note these ACL equivalents.
· The source/source-wildcard of 0.0.0.0/255.255.255.255 means "any".
· The source/wildcard of 10.1.1.2/0.0.0.0 is the same as "host 10.1.1.2".
If you subtract 255.255.255.0 (normal mask) from 255.255.255.255, it yields 0.0.0.255.
Wildcards
The command below defines an ACL that permits this network 192.168.1.0 0.0.0.255.
access-list acl_permit permit ip 192.168.1.0 0.0.0.255
Inbound traffic to the router is compared to access lists entries based on the order that the entries occur in the router. The router looks through the entries until it has a match. If the router found no match when it reaches the end of the list, the traffic is denied. For this reason, you should have the frequently hit entries at the top of the list. There is an implied deny for traffic that is not permitted. Single-entry access lists with only one deny entry has the effect of denying all traffic. You must have at least one permit statement in an ACL or all traffic is blocked.
Access lists implicitly deny all access that is not expressly permitted. The following line is auto-appended to all access-lists:
deny ip any any
If it is desirable to over-ride this implicit denial statement, enter a permit ip any any statement as the last entry in the access-list.
Access Control List (ACL) are filters that enable you to control which routing updates or packets are permitted or denied in or out of a network. They are specifically used by network administrators to filter traffic and to provide extra security for their networks. This can be applied on routers (Cisco).
ACLs provide a powerful way to control traffic into and out of your network; this control can be as simple as permitting or denying network hosts or addresses. You can configure ACLs for all routed network protocols.
The most important reason to configure ACLs is to provide security for your network. However, ACLs can also be configured to control network traffic based on the TCP port being used.
How ACLs work
A router acts as a packet filter when it forwards or denies packets according to filtering rules. As a Layer 3 device, a packet-filtering router uses rules to determine whether to permit or deny traffic based on source and destination IP addresses, source port and destination port, and the protocol of the packet. These rules are defined using access control lists or ACLs.
To simplify how ACL or a router uses packet filtering work, imagine a guard stationed at a locked door. The guard's instruction is to allow only people whose names appear on a quest list to pass through the door. The guard is filtering people based on the condition of having their names on the authorized list.
When a packet arrives at the router, the router extracts certain information from the packet header and makes decisions according to the filter rules as to whether the packet can pass through or be dropped. Packet filtering process works at the Network layer of the Open Systems Interconnection (OSI) model, or the Internet layer of TCP/IP.
Why use ACLs
* Limits network traffic to increase network performance.
* ACLs provides traffic flow control by restricting the delivery of routing updates.
* It can be used as additional security.
* Controls which type of traffic are forwarded or blocked by the router.
* Ability to control which areas a client access.
Types of Access Control Lists
Standard access-list
Standard access lists create filters based on source addresses and are used for server based filtering. Address based access lists distinguish routes on a network you want to control by using network address number (IP). Address-based access lists consist of a list of addresses or address ranges and a statement as to whether access to or from that address is permitted or denied.
Example of the command syntax for configuring a standard numbered IP ACL:
R1(config)# access-list {1-99} {permit | deny} source-addr [source-wildcard]
i. The first value {1-99} specifies the standard ACL number range.
ii. The second value specifies whether to permit or deny the configured source IP address traffic.
iii. The third value is the source IP address that must be matched.
iv. The fourth value is the wildcard mask to be applied to the previously configured IP address to indicate the range.
Extended access lists
Extended access lists create filters based on source addresses, destination addresses, protocol, port number and other features and are used for packet based filtering for packets that traverse the network.
Example of the command syntax for configuring an extended numbered IP ACL:
Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-wildcard] [operator operand] destination-addr [destination-wildcard] [operator operand] [established]
i. Like the standard ACLs, the first value {100-199 or 2000 - 2699} specifies the ACL number range.
ii. The next value specifies whether to permit or deny according to the criteria that follows.
iii. The third value specifies protocol type ( IP, TCP, UDP, or other specific IP sub-protocols). The source IP address and wildcard mask determine traffic source. The destination IP address and its wildcard mask are used to indicate the final destination of the network traffic. When the destination IP address and mask are configured, the port number must be specified to match, either by number or by a well-known port name, otherwise all traffic to that destination will be dropped.
Standard and Extended access lists can be applied base on the use of ip access-list command.
Access lists use the deny or permit statement to define which packet is allowed or denied entry into a server or network.
Masks
Masks are used with IP addresses in IP ACLs to specify what should be permitted and denied. Masks in order to configure IP addresses on interfaces start with 255 and have the large values on the left side, for example, IP address 172.16.2.14 with a 255.255.255.0 mask. Masks for IP ACLs are the reverse, for example, mask 0.0.0.255. This is sometimes called an inverse mask or a wildcard mask. When the value of the mask is broken down into binary (0s and 1s), the results determine which address bits are to be considered in processing the traffic. A 0 indicates that the address bits must be considered (exact match); a 1 in the mask is a "no".
Note these ACL equivalents.
· The source/source-wildcard of 0.0.0.0/255.255.255.255 means "any".
· The source/wildcard of 10.1.1.2/0.0.0.0 is the same as "host 10.1.1.2".
If you subtract 255.255.255.0 (normal mask) from 255.255.255.255, it yields 0.0.0.255.
Wildcards
The command below defines an ACL that permits this network 192.168.1.0 0.0.0.255.
access-list acl_permit permit ip 192.168.1.0 0.0.0.255
Inbound traffic to the router is compared to access lists entries based on the order that the entries occur in the router. The router looks through the entries until it has a match. If the router found no match when it reaches the end of the list, the traffic is denied. For this reason, you should have the frequently hit entries at the top of the list. There is an implied deny for traffic that is not permitted. Single-entry access lists with only one deny entry has the effect of denying all traffic. You must have at least one permit statement in an ACL or all traffic is blocked.
Access lists implicitly deny all access that is not expressly permitted. The following line is auto-appended to all access-lists:
deny ip any any
If it is desirable to over-ride this implicit denial statement, enter a permit ip any any statement as the last entry in the access-list.
Inter VLAN Routing (part 1)
Network devices in different VLANs cannot communicate with one another without a router to route traffic between the VLANs. In most network environments, VLANs are associated with individual networks or subnetworks.
Configuring VLANs helps control the size of the broadcast domain and keeps local traffic local. However, when an end station in one VLAN needs to communicate with an end station in another VLAN, interVLAN communication is required. This communication is supported by interVLAN routing. You configure one or more routers to route traffic to the appropriate destination VLAN.
When Host A in VLAN 10 needs to communicate with Host B in VLAN 10, it sends a packet addressed to that host. Switch A forwards the packet directly to Host B, without sending it to the router.
When Host A sends a packet to Host C in VLAN 20, Switch A forwards the packet to the router, which receives the traffic on the VLAN 10 interface. The router checks the routing table, determines the correct outgoing interface, and forwards the packet out the VLAN 20 interface to Switch B. Switch B receives the packet and forwards it to Host C.
Configuring VLANs helps control the size of the broadcast domain and keeps local traffic local. However, when an end station in one VLAN needs to communicate with an end station in another VLAN, interVLAN communication is required. This communication is supported by interVLAN routing. You configure one or more routers to route traffic to the appropriate destination VLAN.
When Host A in VLAN 10 needs to communicate with Host B in VLAN 10, it sends a packet addressed to that host. Switch A forwards the packet directly to Host B, without sending it to the router.
When Host A sends a packet to Host C in VLAN 20, Switch A forwards the packet to the router, which receives the traffic on the VLAN 10 interface. The router checks the routing table, determines the correct outgoing interface, and forwards the packet out the VLAN 20 interface to Switch B. Switch B receives the packet and forwards it to Host C.
Tuesday, June 29, 2010
CCIE EXAM POLICY
CCIE EXAM POLICY (AS PER CISCO GUIDELINE )
•Age Requirements
In compliance with the Cisco Privacy Policy, age requirements for Cisco certification are as follows:
• Underage Minors are children under 13 who may not test or receive certification even w/parental consent
Minors are individuals between 13–17 years of age who may test and receive certification w/parental consent
Individuals 18 years or older are eligible for certification without any age-related restriction
For more information, please refer to the Cisco Career Certification and Confidentiality Agreement.
Conduct
Candidates must agree they will not compromise the integrity or confidentiality of any Cisco certification exam or certification program. Prohibited actions are described in the Cisco Career Certifications and Confidentiality Agreement. Remedies for violating the policy can include a lifetime ban on all future exams and voiding of all previous certifications.
Confidentiality
The questions and answers of the certification exams are the exclusive and confidential property of Cisco and are protected by Cisco's intellectual property rights. Candidates taking Cisco exams must agree they have read and will abide by the terms and conditions of the Cisco Career Certifications and Confidentiality Agreement before beginning each exam.
Correspondence
All official correspondence to certified CCIEs and candidates is sent to the email address in the CCIE database. This database is SEPARATE from the Cisco customer database. Changing an email address in the Cisco customer database does not automatically update the CCIE database. CCIEs and candidates must keep their CCIE email address updated in order to ensure they received all official correspondence.
Exam Discounts, Vouchers and Promotional Codes
Neither Cisco nor Pearson VUE, its primary test delivery partner, guarantees the authenticity of discount vouchers or promotional codes that are obtained from any individuals or entities other than Pearson VUE.
Individuals or Cisco affiliated partners who use certifications discount vouchers or promotional codes that are fraudulent or otherwise obtained from an unauthorized source (including legitimate vouchers for attempted re-use) may risk up to and including a lifetime ban on all future exams, the nullification of all previous certifications or other program sanctions at the discretion of Cisco. Cisco will not compensate candidates for fraudulent vouchers or vouchers obtained from an unauthorized source.
Exam Violations
Disclosure of test content is strictly prohibited. Please report any suspicious activity as described in Cisco's Exam Violation Rules.
Lab Exam: Double Booking
CCIE candidates are allowed to schedule only a single CCIE lab exam date at any location for each CCIE track. Double booking for lab exams in the same track, at either the same location or different locations, is not permitted by the database. Candidates will be allowed to simultaneously schedule lab exams for different tracks.
Lab Exam: Exam Rules
Candidates for the CCIE written exam or lab exam are not allowed to bring anything into the exam room or take anything out. This includes, but is not limited to: notes, documentation, watches, laptops, keyboards, pagers, PDAs, and mobile phones. DO NOT confer or consult with anyone about the exam while taking the exam or after the exam is completed. During an exam, you may only discuss your exam with the lab engineer.
Lab Exam: Payment
Price not confirmed and is subject to change until full payment is made.
Types. Lab sites in China and Japan will only accept payment via wire transfer. All other locations accept online credit card payment (American Express, Visa, Mastercard, or Eurocard) See “Lab Exam: Scheduling and Payment” for details. You are responsible for any fees your financial institution may charge to complete the payment transaction.
Due Date. Full payment must be received at least 90 days before the lab exam date. Only one e-mail notice is sent as a payment reminder. Payments generally take one to seven business days to process, so be sure to initiate payment in advance of the due date. It is important that if payment will be made by wire transfer, that the payment is scheduled well in advance to prevent the lab date being dropped. Exams for which payment is not received by the due date will be automatically dropped from the schedule. If you still wish to take the lab, you must rebook the exam online and complete your payment. There is no guarantee that your original date will still be available once it has been dropped for non-payment. If you book an exam for a date less than 90 days away, you must complete payment on the day you book the exam or the registration cannot be submitted. Candidates are ultimately responsible for making the lab payment in a timely manner and Cisco will not be held liable for any candidates automatically dropped due to non-payment.
Processing. Credit card payments entered into the system will be processed on the payment due date, exactly 90 days prior to your lab date, as will invoices for all payment types. Be sure the company name, invoicing address and email address are complete and accurate to ensure proper delivery of your invoice. No invoices will be generated before the lab exam due date.
Lab Exam: Rescheduling, Canceling and Postponing
Prior to Due Date. Cancellations or changes to the exam date, location, or track must be made prior to the payment due date--90 days before the scheduled lab date. To make any changes, you must log into the Lab Scheduling tool and drop your current lab. Then you can reschedule according to preferred date, location and track. You may book an exam for a date less than 90 days away, if you complete payment on the day you book the exam.
If you need to cancel an exam before the due date, and paid via a wire transfer that has already cleared, you are eligible for a full refund by requesting support via the Certifications Online Support tool.
After Due Date. Changes and cancellations are not permitted after the payment due date--90 days prior to the scheduled lab date--and no refunds will be issued. If you are not able to attend your scheduled lab date, contact support to let them know the lab seat will not be used. You will still forfeit your payment, but you will be allowed to book another exam date immediately. If you do not contact support, you will be marked as a "no show" for the exam and be barred from booking another exam for 30 days.
Candidates Requiring Visas. If you require a visa to attend your lab exam, it is strongly recommended you apply 10-12 weeks before your lab date. Candidates who fail to obtain required visas will still be bound by these cancellation policies and must cancel their lab exam before the payment due date to be eligible for a full refund. For more information in requesting a CCIE Invitation Letter, please visit our CCIE: Invitation Letter (Entrance Visa) Instant Answer.
Lab Exam: Reevaluation of Lab Results
Exam results appeals are available for the routing and switching, security, and service provider technology tracks. Only exams with potential to change from fail to pass will have the option to request an appeal, based on years of historical data. Appeals are not available for the voice or storage tracks due to equipment limitations.
An appeal consists of a second proctor loading your configurations into a rack to recreate the test and re-score the entire exam. This process takes up to three weeks after receipt of payment. Only one appeal per lab attempt is permitted.
The result of the appeal is a confirmation of the existing fail or an update to a pass.
Payment Terms
Make your request within 14 days following your exam date by using the "Request for Reread" link next to your lab record. Each appeal costs $250.00 USD plus any applicable local taxes. Payment is made online via credit card and your card will be charged upon receipt of the request. You may not cancel the appeal request once the process has been initiated. Refunds are given only when results change from fail to pass.
Lab Exam: Retakes
All candidates must wait 30 days between CCIE lab attempts. Please note the 30 days starts from the day after a failed lab exam.
Lab Exam: Scoring
You must obtain an overall score of at least 80% to pass the lab exam. You can view your lab exam results online (login required), usually within 48 hours. Results are Pass/Fail and failing score reports indicate major topic areas where additional study and preparation may be useful.
Lab Exam: Start Times
Start times for exams are indicated in email can also found on the web page associated with each lab location (for a list, see Lab Exam Locations). Pleaseverify your email address in your candidate profile so we can notify you of any changes. If you have any questions about the start time of your exam, please contact CCIE customer support through the Certifications Online Support tool . If you arrive more than two hours after the start of your exam, you will not be allowed to start. If you arrive less than two hours late, you will be allowed to start but you must finish with the rest of the group.
Logo Guidelines
Certified CCIEs may only use the CCIE logo as provided and in accordance with the published Logo Guidelines.
Recertification
To maintain active CCIE status, CCIEs are required to pass either a CCIE written exam of their choosing from among all of the currently available written exams, or a CCIE lab exam in a new track every 24 months. Candidates can only apply one passed written exam towards recertification for every 24 month recertification period. Certification candidates are responsible for keeping track of their certification expiration dates; your recertification deadline can be viewed online anytime (with login) at Certification Status. Subsequent recertification deadlines are always based on your original certification date, not on when you took your last recertification exam.
If your CCIE recertification requirements are not completed on or before the certification's expiration date, your CCIE certification will be suspended for one year. Candidates have one year to recertify their CCIE certification by passing the required written exam. If a candidate does not recertify prior to the one year suspension period, all CCIE certification requirements must be completed again to obtain the certification (pass both the written exam and the lab exam.) Please see Recertification for detailed information.
Travel Costs
Under no circumstances will Cisco reimburse travel costs for CCIE lab exams.
Written Exam: Expiration
Candidates must make an initial attempt of the CCIE lab exam within 18 months of passing the CCIE written exam. Candidates who do not pass must re-attempt the lab exam within 12 months of their last scored attempt in order for their written exam to remain valid. If a candidate does not pass the lab exam within three years of passing the written exam, he or she must retake the written exam before being allowed to attempt the lab exam again.
Written Exam: Retakes
There is no limit to the number of attempts that can be made on the written exam. However, candidates must wait 5 calendar days between exam attempts. Once a candidate passes a particular written exam, he or she may not retake that same exam for at least 180 days. (Though rare, this may occur in certain recertification situations.)
Written Exam: Scoring
Pass marks are set by using statistical analysis and are subject to change. The pass score is given on the Examination Score Sheet at the end of the test. Along with the candidate's score, there is a notation of either PASS or FAIL. Scores on written exams are automatically downloaded from testing vendors, but may take up to 10 days to appear in the CCIE database.
PROVIDED BY CISCO SYSTEMS
•Age Requirements
In compliance with the Cisco Privacy Policy, age requirements for Cisco certification are as follows:
• Underage Minors are children under 13 who may not test or receive certification even w/parental consent
Minors are individuals between 13–17 years of age who may test and receive certification w/parental consent
Individuals 18 years or older are eligible for certification without any age-related restriction
For more information, please refer to the Cisco Career Certification and Confidentiality Agreement.
Conduct
Candidates must agree they will not compromise the integrity or confidentiality of any Cisco certification exam or certification program. Prohibited actions are described in the Cisco Career Certifications and Confidentiality Agreement. Remedies for violating the policy can include a lifetime ban on all future exams and voiding of all previous certifications.
Confidentiality
The questions and answers of the certification exams are the exclusive and confidential property of Cisco and are protected by Cisco's intellectual property rights. Candidates taking Cisco exams must agree they have read and will abide by the terms and conditions of the Cisco Career Certifications and Confidentiality Agreement before beginning each exam.
Correspondence
All official correspondence to certified CCIEs and candidates is sent to the email address in the CCIE database. This database is SEPARATE from the Cisco customer database. Changing an email address in the Cisco customer database does not automatically update the CCIE database. CCIEs and candidates must keep their CCIE email address updated in order to ensure they received all official correspondence.
Exam Discounts, Vouchers and Promotional Codes
Neither Cisco nor Pearson VUE, its primary test delivery partner, guarantees the authenticity of discount vouchers or promotional codes that are obtained from any individuals or entities other than Pearson VUE.
Individuals or Cisco affiliated partners who use certifications discount vouchers or promotional codes that are fraudulent or otherwise obtained from an unauthorized source (including legitimate vouchers for attempted re-use) may risk up to and including a lifetime ban on all future exams, the nullification of all previous certifications or other program sanctions at the discretion of Cisco. Cisco will not compensate candidates for fraudulent vouchers or vouchers obtained from an unauthorized source.
Exam Violations
Disclosure of test content is strictly prohibited. Please report any suspicious activity as described in Cisco's Exam Violation Rules.
Lab Exam: Double Booking
CCIE candidates are allowed to schedule only a single CCIE lab exam date at any location for each CCIE track. Double booking for lab exams in the same track, at either the same location or different locations, is not permitted by the database. Candidates will be allowed to simultaneously schedule lab exams for different tracks.
Lab Exam: Exam Rules
Candidates for the CCIE written exam or lab exam are not allowed to bring anything into the exam room or take anything out. This includes, but is not limited to: notes, documentation, watches, laptops, keyboards, pagers, PDAs, and mobile phones. DO NOT confer or consult with anyone about the exam while taking the exam or after the exam is completed. During an exam, you may only discuss your exam with the lab engineer.
Lab Exam: Payment
Price not confirmed and is subject to change until full payment is made.
Types. Lab sites in China and Japan will only accept payment via wire transfer. All other locations accept online credit card payment (American Express, Visa, Mastercard, or Eurocard) See “Lab Exam: Scheduling and Payment” for details. You are responsible for any fees your financial institution may charge to complete the payment transaction.
Due Date. Full payment must be received at least 90 days before the lab exam date. Only one e-mail notice is sent as a payment reminder. Payments generally take one to seven business days to process, so be sure to initiate payment in advance of the due date. It is important that if payment will be made by wire transfer, that the payment is scheduled well in advance to prevent the lab date being dropped. Exams for which payment is not received by the due date will be automatically dropped from the schedule. If you still wish to take the lab, you must rebook the exam online and complete your payment. There is no guarantee that your original date will still be available once it has been dropped for non-payment. If you book an exam for a date less than 90 days away, you must complete payment on the day you book the exam or the registration cannot be submitted. Candidates are ultimately responsible for making the lab payment in a timely manner and Cisco will not be held liable for any candidates automatically dropped due to non-payment.
Processing. Credit card payments entered into the system will be processed on the payment due date, exactly 90 days prior to your lab date, as will invoices for all payment types. Be sure the company name, invoicing address and email address are complete and accurate to ensure proper delivery of your invoice. No invoices will be generated before the lab exam due date.
Lab Exam: Rescheduling, Canceling and Postponing
Prior to Due Date. Cancellations or changes to the exam date, location, or track must be made prior to the payment due date--90 days before the scheduled lab date. To make any changes, you must log into the Lab Scheduling tool and drop your current lab. Then you can reschedule according to preferred date, location and track. You may book an exam for a date less than 90 days away, if you complete payment on the day you book the exam.
If you need to cancel an exam before the due date, and paid via a wire transfer that has already cleared, you are eligible for a full refund by requesting support via the Certifications Online Support tool.
After Due Date. Changes and cancellations are not permitted after the payment due date--90 days prior to the scheduled lab date--and no refunds will be issued. If you are not able to attend your scheduled lab date, contact support to let them know the lab seat will not be used. You will still forfeit your payment, but you will be allowed to book another exam date immediately. If you do not contact support, you will be marked as a "no show" for the exam and be barred from booking another exam for 30 days.
Candidates Requiring Visas. If you require a visa to attend your lab exam, it is strongly recommended you apply 10-12 weeks before your lab date. Candidates who fail to obtain required visas will still be bound by these cancellation policies and must cancel their lab exam before the payment due date to be eligible for a full refund. For more information in requesting a CCIE Invitation Letter, please visit our CCIE: Invitation Letter (Entrance Visa) Instant Answer.
Lab Exam: Reevaluation of Lab Results
Exam results appeals are available for the routing and switching, security, and service provider technology tracks. Only exams with potential to change from fail to pass will have the option to request an appeal, based on years of historical data. Appeals are not available for the voice or storage tracks due to equipment limitations.
An appeal consists of a second proctor loading your configurations into a rack to recreate the test and re-score the entire exam. This process takes up to three weeks after receipt of payment. Only one appeal per lab attempt is permitted.
The result of the appeal is a confirmation of the existing fail or an update to a pass.
Payment Terms
Make your request within 14 days following your exam date by using the "Request for Reread" link next to your lab record. Each appeal costs $250.00 USD plus any applicable local taxes. Payment is made online via credit card and your card will be charged upon receipt of the request. You may not cancel the appeal request once the process has been initiated. Refunds are given only when results change from fail to pass.
Lab Exam: Retakes
All candidates must wait 30 days between CCIE lab attempts. Please note the 30 days starts from the day after a failed lab exam.
Lab Exam: Scoring
You must obtain an overall score of at least 80% to pass the lab exam. You can view your lab exam results online (login required), usually within 48 hours. Results are Pass/Fail and failing score reports indicate major topic areas where additional study and preparation may be useful.
Lab Exam: Start Times
Start times for exams are indicated in email can also found on the web page associated with each lab location (for a list, see Lab Exam Locations). Pleaseverify your email address in your candidate profile so we can notify you of any changes. If you have any questions about the start time of your exam, please contact CCIE customer support through the Certifications Online Support tool . If you arrive more than two hours after the start of your exam, you will not be allowed to start. If you arrive less than two hours late, you will be allowed to start but you must finish with the rest of the group.
Logo Guidelines
Certified CCIEs may only use the CCIE logo as provided and in accordance with the published Logo Guidelines.
Recertification
To maintain active CCIE status, CCIEs are required to pass either a CCIE written exam of their choosing from among all of the currently available written exams, or a CCIE lab exam in a new track every 24 months. Candidates can only apply one passed written exam towards recertification for every 24 month recertification period. Certification candidates are responsible for keeping track of their certification expiration dates; your recertification deadline can be viewed online anytime (with login) at Certification Status. Subsequent recertification deadlines are always based on your original certification date, not on when you took your last recertification exam.
If your CCIE recertification requirements are not completed on or before the certification's expiration date, your CCIE certification will be suspended for one year. Candidates have one year to recertify their CCIE certification by passing the required written exam. If a candidate does not recertify prior to the one year suspension period, all CCIE certification requirements must be completed again to obtain the certification (pass both the written exam and the lab exam.) Please see Recertification for detailed information.
Travel Costs
Under no circumstances will Cisco reimburse travel costs for CCIE lab exams.
Written Exam: Expiration
Candidates must make an initial attempt of the CCIE lab exam within 18 months of passing the CCIE written exam. Candidates who do not pass must re-attempt the lab exam within 12 months of their last scored attempt in order for their written exam to remain valid. If a candidate does not pass the lab exam within three years of passing the written exam, he or she must retake the written exam before being allowed to attempt the lab exam again.
Written Exam: Retakes
There is no limit to the number of attempts that can be made on the written exam. However, candidates must wait 5 calendar days between exam attempts. Once a candidate passes a particular written exam, he or she may not retake that same exam for at least 180 days. (Though rare, this may occur in certain recertification situations.)
Written Exam: Scoring
Pass marks are set by using statistical analysis and are subject to change. The pass score is given on the Examination Score Sheet at the end of the test. Along with the candidate's score, there is a notation of either PASS or FAIL. Scores on written exams are automatically downloaded from testing vendors, but may take up to 10 days to appear in the CCIE database.
PROVIDED BY CISCO SYSTEMS
core knowledge exam removed from ccie track
Core Knowledge Questions Removed for CCIE R&S and Voice Lab Exams
With more than six months of exam results now available, Cisco is now able to report that the troubleshooting components of the CCIE R&S v4.0 and CCIE Voice v3.0 lab exams are performing well in validating expert level networking skills. Considering these results, Cisco has decided to eliminate the Core Knowledge questions from the current CCIE R&S v4.0 and CCIE Voice v3.0 Lab Exams. Beginning on May 10, 2010, CCIE R&S and CCIE Voice Lab Exams, in all global locations, will no longer include the four open-ended Core Knowledge questions. The total lab time will remain eight hours. For the CCIE R&S Lab Exam, this means candidates will begin with the two-hour Troubleshooting section, followed by a six-hour Configuration section. For CCIE Voice, candidates will have the full eight hours to complete the integrated exam. At this time, only the R&S and Voice certifications have been designed and validated to allow removal of Core Knowledge.
With more than six months of exam results now available, Cisco is now able to report that the troubleshooting components of the CCIE R&S v4.0 and CCIE Voice v3.0 lab exams are performing well in validating expert level networking skills. Considering these results, Cisco has decided to eliminate the Core Knowledge questions from the current CCIE R&S v4.0 and CCIE Voice v3.0 Lab Exams. Beginning on May 10, 2010, CCIE R&S and CCIE Voice Lab Exams, in all global locations, will no longer include the four open-ended Core Knowledge questions. The total lab time will remain eight hours. For the CCIE R&S Lab Exam, this means candidates will begin with the two-hour Troubleshooting section, followed by a six-hour Configuration section. For CCIE Voice, candidates will have the full eight hours to complete the integrated exam. At this time, only the R&S and Voice certifications have been designed and validated to allow removal of Core Knowledge.
Thursday, June 17, 2010
HSRP vs VRRP vs GLBP
Cisco Hot-Standby Router Protocol (HSRP):
Created by Cisco, for Cisco in 1994
Uses a default hello timer of 3 seconds with a hold timer of 10 seconds
u need unique IP add. as a virtual gateway ip.
active router
standby router
Virtual Router Redundancy Protocol (VRRP)
Created by the IETF in 1999
Works between multiple vendors
Has faster timers than HSRP by default - hello of 1 second, hold timer of 3 seconds
u haven't any need of unique IP add u can use any assigned physical ip as a virtual gateway.
master router
backup router
Gateway Load Balancing Protocol (GLBP)
Created by Cisco, for Cisco in 2005
Identical features to HSRP, but allows an active-active connection that adds load-balancing features
One AVG(active virtual gateway)
Many AVF(active virtual forwarders)
Created by Cisco, for Cisco in 1994
Uses a default hello timer of 3 seconds with a hold timer of 10 seconds
u need unique IP add. as a virtual gateway ip.
active router
standby router
Virtual Router Redundancy Protocol (VRRP)
Created by the IETF in 1999
Works between multiple vendors
Has faster timers than HSRP by default - hello of 1 second, hold timer of 3 seconds
u haven't any need of unique IP add u can use any assigned physical ip as a virtual gateway.
master router
backup router
Gateway Load Balancing Protocol (GLBP)
Created by Cisco, for Cisco in 2005
Identical features to HSRP, but allows an active-active connection that adds load-balancing features
One AVG(active virtual gateway)
Many AVF(active virtual forwarders)
Monday, June 14, 2010
HSRP
HSRP stands for Hot Standy Routing Protocol which provides Automatic Router backup when an active router in the group fails. HSRP allows building resiliency in the networkgateways wherein should an Active Router fail in a HSRP group, the standby router assumes the role of the active router and continue routing packets.
HSRP works by sending multicast "Hello" messages (default: every 3 secs). If the Standby router do not receive any Hello packets from the active router for a preset time (default 10secs) then it assumes the active router is down and becomes the active router. Also, if we are tracking an interface and if the tracked interface is down, the Active Router reduces its priority so a Standby Router can assume to role of Primary Router.
A realtime example would be access to a service providers servers at a remote location. Lets say there are two distinct routes to the same server(s), each through individual routers. The clients on the internal network segment are configured to send the traffic through a gateway. The gateway being the HSRP Address. Then the Server is accessible through one service provider always (based on the active router). However, in a disaster situation when the active router goes down, the standby router assumes the active router role and continues to serve connection to the remote servers but using the other serviceprovider. This way routing redundancy is provided to a remote resource.
To setup HSRP on a pair of routers,
Router 1:
From the Interface Configuration Mode add the IP Address of the Interface
hsrp-router1#conf t
hsrp-router1(config)# int fa0/0
hsrp-router1(config-if)# ip address 192.168.0.2 255.255.255.0
Set the Virtual IP Address
Sets the Virtual IP Address for the interface where "1" is the HSRP group and "92.168.0.1" is the Virtual IP for the HSRP group.
hsrp-router1(config-if)# standby 1 ip 192.168.0.1
Enable Preempt
This is required to make the router from being a Standby Router to an Active Router when it finds the Active Router is down or if it has become the higher priority router in the group
hsrp-router1(config-if)# standby 1 preempt
Set Router Priority
The default priority is "100". We set here as "110" to make the Router 1 as active.
hsrp-router1(config-if)# standby 1 priority 110
Set Authentication String
This is an optional plain text 8 character string that can be used in the multicast "hello" packets to authenticate the HSRP group.
hsrp-router1(config-if)# standby 1 authentication LocalLAN
Set Timers
Sets the time period between the "hello" packets and the hold time before assuming an active router is down. Default is 3seconds and 10 seconds respectively.
hsrp-router1(config-if)# standby 1 timers 5 15
Track Interface
If you track interface to check link status then the following command will track an interface and when the tracked link is down, the active router will mark its priority low so as to allow a Standby router to take over.
hsrp-router1(config-if)# standby 1 track se0/0
Repeat the procedure altering the IP Address of the Local interface and the priority and the tracked interface.
Router 2:
hsrp-router2#conf t
hsrp-router2(config)# int fa0/0
hsrp-router2(config-if)# ip address 192.168.0.3 255.255.255.0
hsrp-router2(config-if)# standby 1 ip 192.168.0.1
hsrp-router2(config-if)# standby 1 preempt
hsrp-router2(config-if)# standby 1 priority 100
hsrp-router2(config-if)# standby 1 authentication LocalLAN
hsrp-router2(config-if)# standby 1 timers 5 15
hsrp-router2(config-if)# standby 1 track se0/0
Thats it. HSRP configuration is complete. You may test the connectivity to a remote route and see for yourself the redudancy in place.
HSRP works by sending multicast "Hello" messages (default: every 3 secs). If the Standby router do not receive any Hello packets from the active router for a preset time (default 10secs) then it assumes the active router is down and becomes the active router. Also, if we are tracking an interface and if the tracked interface is down, the Active Router reduces its priority so a Standby Router can assume to role of Primary Router.
A realtime example would be access to a service providers servers at a remote location. Lets say there are two distinct routes to the same server(s), each through individual routers. The clients on the internal network segment are configured to send the traffic through a gateway. The gateway being the HSRP Address. Then the Server is accessible through one service provider always (based on the active router). However, in a disaster situation when the active router goes down, the standby router assumes the active router role and continues to serve connection to the remote servers but using the other serviceprovider. This way routing redundancy is provided to a remote resource.
To setup HSRP on a pair of routers,
Router 1:
From the Interface Configuration Mode add the IP Address of the Interface
hsrp-router1#conf t
hsrp-router1(config)# int fa0/0
hsrp-router1(config-if)# ip address 192.168.0.2 255.255.255.0
Set the Virtual IP Address
Sets the Virtual IP Address for the interface where "1" is the HSRP group and "92.168.0.1" is the Virtual IP for the HSRP group.
hsrp-router1(config-if)# standby 1 ip 192.168.0.1
Enable Preempt
This is required to make the router from being a Standby Router to an Active Router when it finds the Active Router is down or if it has become the higher priority router in the group
hsrp-router1(config-if)# standby 1 preempt
Set Router Priority
The default priority is "100". We set here as "110" to make the Router 1 as active.
hsrp-router1(config-if)# standby 1 priority 110
Set Authentication String
This is an optional plain text 8 character string that can be used in the multicast "hello" packets to authenticate the HSRP group.
hsrp-router1(config-if)# standby 1 authentication LocalLAN
Set Timers
Sets the time period between the "hello" packets and the hold time before assuming an active router is down. Default is 3seconds and 10 seconds respectively.
hsrp-router1(config-if)# standby 1 timers 5 15
Track Interface
If you track interface to check link status then the following command will track an interface and when the tracked link is down, the active router will mark its priority low so as to allow a Standby router to take over.
hsrp-router1(config-if)# standby 1 track se0/0
Repeat the procedure altering the IP Address of the Local interface and the priority and the tracked interface.
Router 2:
hsrp-router2#conf t
hsrp-router2(config)# int fa0/0
hsrp-router2(config-if)# ip address 192.168.0.3 255.255.255.0
hsrp-router2(config-if)# standby 1 ip 192.168.0.1
hsrp-router2(config-if)# standby 1 preempt
hsrp-router2(config-if)# standby 1 priority 100
hsrp-router2(config-if)# standby 1 authentication LocalLAN
hsrp-router2(config-if)# standby 1 timers 5 15
hsrp-router2(config-if)# standby 1 track se0/0
Thats it. HSRP configuration is complete. You may test the connectivity to a remote route and see for yourself the redudancy in place.
Cisco EtherChannel Topologies(5)
Cisco EtherChannel Technology over CWDM
This figure shows a sample network where Gigabit links are used with Gigabit EtherChannel and CWDM technologies. In Figure 5, four gigabit links have been combined to obtain a total aggregated bandwidth of 4 gigabits. Without incorporating CWDM technologies into the solution, four runs of fiber need to be installed between the two campus points of presence (POPs). By employing CWDM GBICs and two CWDM add/drop multiplexers, the number of runs of fiber can be reduced to one. This translates into significant savings depending on the distance to be spanned by the EtherChannel connection.
Cisco EtherChannel Topologies(4)
Cisco EtherChannel Technology Interconnecting Servers, Switches, and Routers Across the Campus
This figure shows a complete network design based on Cisco EtherChannel technology. As in the previous examples, links from the wiring closets are brought into the data center using 400 Mbps channels, providing bandwidth and resiliency. In the data center, routers are interconnected with EtherChannel connections, providing improved performance by having more bandwidth available to route between subnets. Here the router is configured with two dual-link EtherChannel connections to provide 400 Mbps of bandwidth on each subnet. The EtherChannel technology provides load balancing across two links within the channel based on IP addresses, and the links within the channel can use ISL encapsulation to support multiple subnets per link. The last component in this network design is a server attached via a four-link EtherChannel connection, which provides 800 Mbps of bandwidth to the network. Typical platforms that would require such bandwidth would be high-end Pentium Pro servers, enterprise servers, and high-end graphics imaging and rendering servers. As shown in Figure 4, the server is connected via a multiple-link EtherChannel connection—an excellent match for the bandwidth needs of locally attached users and the users serviced via the router.
Cisco EtherChannel Topologies(3)
Resilience with Cisco EtherChannel Technology Using Spanning-Tree Protocol
This figure shows a configuration where a switch has been configured with two Cisco EtherChannel connections consisting of two links each. Because these are separate channels, Spanning-Tree Protocol will block the second channel to avoid the looped topology. This design is applicable where EtherChannel connections are resident on separate line cards within the switch for resiliency
EtherChannel Topologies(2)
Scaling Bandwidth with Resilience
This figure shows a topology where the network manager has increased bandwidth between the data center and the wiring closet to an aggregate of 800 Mbps, but has also used the physical diversity of the fiber plant to decrease the chances of a network outage. Using a Cisco EtherChannel connection consisting of four Fast Ethernet links, two fiber runs on the east side of the building provide 400 Mbps, and the west side of the building provides the remaining 400 Mbps. In this example, in the event of a fiber cut on one side of the building, the remaining side will pick up the traffic in less than one second, without wiring closet clients losing sessions.
Cisco EtherChannel Topologies(1)
The following diagrams show some common applications of Cisco EtherChannel technology and how they solve the bandwidth requirements of today's networks. Fast EtherChannel and Fast Ethernet links will be used throughout these examples.
This figure shows a network using Cisco EtherChannel connections. The bandwidth between the wiring closets and the data center has been doubled, from 200 Mbps to 400 Mbps. In addition to the increased bandwidth, the resiliency within the channel provides for subsecond convergence if one of the links fails.
EtherChannel (The Indians are everywhere)
EtherChannel technology was invented by Kalpana in the early 1990s. They were later acquired by Cisco Systems in 1994. In 2000 the IEEE passed 802.3ad which is an open standard version of EtherChannel.
Kalpana was a computer networking equipment manufacturer, located in Silicon Valley during the 1980s and 1990s. [1] Kalpana introduced the concept of a multi-port network switch in 1989. They also invented EtherChannel, a technology which provides additional inter-switch bandwidth by running several links in parallel. Kalpana was acquired by Cisco Systems in the year 1994 .
Kalpana had been founded by an entrepreneur of Indian origin Vinod Bhardwaj."Kalpana" meaning "imagination" in Sanskrit/Hindi was named after Vinod Bhardwaj's wife.
"By 1994, Kalpana was in a dogfight with 3Com and other switching vendors, which had embraced higher-speed uplinks and had deeper pockets for development than Kalpana had. It became clear that if Cisco were truly going to own enterprise networking, the company would have to embrace switching--and quickly."
EtherChannel is a port trunking (link aggregation being the general term) technology used primarily on Cisco switches. It allows grouping several physical Ethernet links to create one logical Ethernet link for the purpose of providing fault-tolerance and high-speed links between switches, routers and servers. An EtherChannel can be created from between two and eight active Fast Ethernet, Gigabit Ethernet or 10-Gigabit Ethernet ports, with an additional one to eight inactive (failover) ports which become active as the other active ports fail. EtherChannel is primarily used in the backbone network, but can also be used to connect end user machines.
EtherChannel between a switch and a server.
A limitation of EtherChannel is that all the physical ports in the aggregation group must reside on the same switch, although exceptions do exist on stackable switches such as Cisco's 3750 series. Nortel's SMLT protocol removes this limitation by allowing the physical ports to be split between two switches. Cisco's Virtual Switching System allows the creation of a Multichassis Etherchannel (MEC) allowing ports to be aggregated towards different physical chassis that conform a single "virtual switch" entity.
Cisco EtherChannel Technology
Introduction
The increasing deployment of switched Ethernet to the desktop can be attributed to the proliferation of bandwidth-intensive intranet applications. Any-to-any communications of new intranet applications such as video to the desktop, interactive messaging, and collaborative white-boarding are increasing the need for scalable bandwidth within the core and at the edge of campus networks. At the same time, mission-critical applications call for resilient network designs. With the wide deployment of faster switched Ethernet links in the campus, users need to either aggregate their existing resources or upgrade the speed in their uplinks and core to scale performance across the network backbone.
Cisco EtherChannel® technology builds upon standards-based 802.3 full-duplex Fast Ethernet to provide network managers with a reliable, high-speed solution for the campus network backbone. EtherChannel technology provides bandwidth scalability within the campus by providing up to 800 Mbps, 8 Gbps, or 80 Gbps of aggregate bandwidth for a Fast EtherChannel, Gigabit EtherChannel, or 10 Gigabit EtherChannel connection, respectively. Each of these connection speeds can vary in amounts equal to the speed of the links used (100 Mbps, 1 Gbps, or 10 Gbps). Even in the most bandwidth-demanding situations, EtherChannel technology helps aggregate traffic and keep oversubscription to a minimum, while providing effective link-resiliency mechanisms.
Cisco EtherChannel Benefits
Cisco EtherChannel technology provides a solution for network managers who require higher bandwidth between servers, routers, and switches than single-link Ethernet technology can provide.
Cisco EtherChannel technology provides incremental scalable bandwidth and the following benefits:
• Standards-based—Cisco EtherChannel technology builds upon IEEE 802.3-compliant Ethernet by grouping multiple, full-duplex point-to-point links together. EtherChannel technology uses IEEE 802.3 mechanisms for full-duplex autonegotiation and autosensing, when applicable.
• Multiple platforms—Cisco EtherChannel technology is flexible and can be used anywhere in the network that bottlenecks are likely to occur. It can be used in network designs to increase bandwidth between switches and between routers and switches—as well as providing scalable bandwidth for network servers, such as large UNIX servers or PC-based Web servers.
• Flexible incremental bandwidth—Cisco EtherChannel technology provides bandwidth aggregation in multiples of 100 Mbps, 1 Gbps, or 10 Gbps, depending on the speed of the aggregated links. For example, network managers can deploy EtherChannel technology that consists of pairs of full-duplex Fast Ethernet links to provide more than 400 Mbps between the wiring closet and the data center. In the data center, bandwidths of up to 800 Mbps can be provided between servers and the network backbone to provide large amounts of scalable incremental bandwidth.
• Load balancing—Cisco EtherChannel technology is composed of several Fast Ethernet links and is capable of load balancing traffic across those links. Unicast, broadcast, and multicast traffic is evenly distributed across the links, providing higher performance and redundant parallel paths. When a link fails, traffic is redirected to the remaining links within the channel without user intervention and with minimal packet loss.
• Resiliency and fast convergence—When a link fails, Cisco EtherChannel technology provides automatic recovery by redistributing the load across the remaining links. When a link fails, Cisco EtherChannel technology redirects traffic from the failed link to the remaining links in less than one second. This convergence is transparent to the end user—no host protocol timers expire, so no sessions are dropped.
• Ease of management—Cisco EtherChannel technology takes advantage of Cisco experience developed over the years in troubleshooting and maintaining Ethernet networks. Existing network probes can be used for traffic management and troubleshooting, and management applications such as CiscoWorks and third-party management applications are now EtherChannel-aware.
• Transparent to network applications—Cisco EtherChannel technology does not require changes to networked applications. When EtherChannel technology is used within the campus, switches and routers provide load balancing across multiple links transparently to network users. To support EtherChannel technology on enterprise-class servers and network interface cards, smart software drivers can coordinate distribution of loads across multiple network interfaces.
• Compatible with Cisco IOS® Software—Cisco EtherChannel connections are fully compatible with Cisco IOS virtual LAN (VLAN) and routing technologies. The Inter-Switch Link (ISL) VLAN Trunking Protocol (VTP) can carry multiple VLANs across an EtherChannel link, and routers attached to EtherChannel trunks can provide full multiprotocol routing with support for hot standby using the Hot Standby Router Protocol (HSRP).
• 100 Megabit, 1 Gigabit, and 10 Gigabit Ethernet-ready—Cisco EtherChannel technology is available in all Ethernet link speeds. EtherChannel technology allows network managers to deploy networks that will scale smoothly with the availability of next-generation, standards-based Ethernet link speeds.
• Interoperability with Coarse Wavelength Division Multiplexing (CWDM) Gigabit Interface Converters (GBICs)—By simultaneously implementing Gigabit EtherChannel and CWDM technologies, network managers can increase the bandwidth of their links without having to invest in new long runs of fiber. CWDM technologies allow the traffic aggregated by the Cisco EtherChannel link to be multiplexed on to a single strand of fiber.
Cisco EtherChannel Components
Cisco EtherChannel technology is a trunking technology based on grouping several full-duplex 802.3 Ethernet links to provide fault-tolerant, high-speed links between switches, routers, and servers. It is based on proven industry-standard technology—it has been extended from the EtherChannel technology offered by Kalpana in its switches in the early 1990s, and provides load sharing across multiple Fast Ethernet links while providing redundancy and subsecond convergence times.
Cisco EtherChannel technology consists of the following key elements:
• Fast Ethernet links—Cisco EtherChannel connections can consist of one to eight industry-standard Fast Ethernet links to load share traffic with up to 80 Gbps of usable bandwidth. EtherChannel connections can interconnect LAN switches, routers, servers, and clients. Because load balancing is integrated with Cisco Catalyst®LAN switch architectures, there is no performance degradation for adding links to a channel—high throughput and low latencies can be maintained while gaining more available bandwidth. EtherChannel technology provides link resiliency within a channel—if links fail, the traffic is immediately directed to the remaining links. Finally, EtherChannel technology is not dependent on any type of media—it can be used with Ethernet running on existing unshielded twisted pair (UTP) wiring, or single-mode and multimode fiber.
• Cisco EtherChannel technology is a standard feature across the entire Cisco Catalyst series of switches and Cisco IOS® Software-based routers. The load-sharing algorithms used vary between platforms, allowing for decisions based on source or destination Media Access Control (MAC) addresses, IP addresses, or Transmission Control Protocol/User Datagram Protocol (TCP/UDP) port numbers.
• Redundancy—Cisco EtherChannel technology does not require the use of 802.1D Spanning-Tree Protocol to maintain a topology state within the channel. Rather, it uses a peer-to-peer control protocol that provides autoconfiguration and subsecond convergence times for parallel links, yet allows higher-level protocols (such as Spanning-Tree Protocol) or existing routing protocols to maintain topology. This approach allows EtherChannel technology to use the recovery features of the network without adding complexity or creating incompatibilities with third-party equipment or software. Because the Spanning-Tree Protocol operation is completely standards-based, network managers can use their existing network topologies, augmenting bandwidth by installing EtherChannel technology where single Ethernet links were previously installed.
• Management—Cisco EtherChannel technology is easily configured by a command-line interface (CLI) or by Simple Network Management Protocol (SNMP) applications such as CiscoWorks. A network manager needs to identify and define the number of ports that will make up the channel, and then connect the devices. CiscoWorks for Switched Internetworks will graphically display EtherChannel connections between devices, collect statistics for both individual Ethernet links within the channel, and aggregate statistics for the EtherChannel connection. An integral benefit of EtherChannel technology is the ability to detect, report, and prevent the use of incorrectly paired interfaces within the channel. These may include interfaces that are not configured for full-duplex operation, have mismatched link speeds, or are incorrectly wired. Consistency checks are completed before the activation of a channel to help ensure network integrity.
Kalpana was a computer networking equipment manufacturer, located in Silicon Valley during the 1980s and 1990s. [1] Kalpana introduced the concept of a multi-port network switch in 1989. They also invented EtherChannel, a technology which provides additional inter-switch bandwidth by running several links in parallel. Kalpana was acquired by Cisco Systems in the year 1994 .
Kalpana had been founded by an entrepreneur of Indian origin Vinod Bhardwaj."Kalpana" meaning "imagination" in Sanskrit/Hindi was named after Vinod Bhardwaj's wife.
"By 1994, Kalpana was in a dogfight with 3Com and other switching vendors, which had embraced higher-speed uplinks and had deeper pockets for development than Kalpana had. It became clear that if Cisco were truly going to own enterprise networking, the company would have to embrace switching--and quickly."
EtherChannel is a port trunking (link aggregation being the general term) technology used primarily on Cisco switches. It allows grouping several physical Ethernet links to create one logical Ethernet link for the purpose of providing fault-tolerance and high-speed links between switches, routers and servers. An EtherChannel can be created from between two and eight active Fast Ethernet, Gigabit Ethernet or 10-Gigabit Ethernet ports, with an additional one to eight inactive (failover) ports which become active as the other active ports fail. EtherChannel is primarily used in the backbone network, but can also be used to connect end user machines.
EtherChannel between a switch and a server.
A limitation of EtherChannel is that all the physical ports in the aggregation group must reside on the same switch, although exceptions do exist on stackable switches such as Cisco's 3750 series. Nortel's SMLT protocol removes this limitation by allowing the physical ports to be split between two switches. Cisco's Virtual Switching System allows the creation of a Multichassis Etherchannel (MEC) allowing ports to be aggregated towards different physical chassis that conform a single "virtual switch" entity.
Cisco EtherChannel Technology
Introduction
The increasing deployment of switched Ethernet to the desktop can be attributed to the proliferation of bandwidth-intensive intranet applications. Any-to-any communications of new intranet applications such as video to the desktop, interactive messaging, and collaborative white-boarding are increasing the need for scalable bandwidth within the core and at the edge of campus networks. At the same time, mission-critical applications call for resilient network designs. With the wide deployment of faster switched Ethernet links in the campus, users need to either aggregate their existing resources or upgrade the speed in their uplinks and core to scale performance across the network backbone.
Cisco EtherChannel® technology builds upon standards-based 802.3 full-duplex Fast Ethernet to provide network managers with a reliable, high-speed solution for the campus network backbone. EtherChannel technology provides bandwidth scalability within the campus by providing up to 800 Mbps, 8 Gbps, or 80 Gbps of aggregate bandwidth for a Fast EtherChannel, Gigabit EtherChannel, or 10 Gigabit EtherChannel connection, respectively. Each of these connection speeds can vary in amounts equal to the speed of the links used (100 Mbps, 1 Gbps, or 10 Gbps). Even in the most bandwidth-demanding situations, EtherChannel technology helps aggregate traffic and keep oversubscription to a minimum, while providing effective link-resiliency mechanisms.
Cisco EtherChannel Benefits
Cisco EtherChannel technology provides a solution for network managers who require higher bandwidth between servers, routers, and switches than single-link Ethernet technology can provide.
Cisco EtherChannel technology provides incremental scalable bandwidth and the following benefits:
• Standards-based—Cisco EtherChannel technology builds upon IEEE 802.3-compliant Ethernet by grouping multiple, full-duplex point-to-point links together. EtherChannel technology uses IEEE 802.3 mechanisms for full-duplex autonegotiation and autosensing, when applicable.
• Multiple platforms—Cisco EtherChannel technology is flexible and can be used anywhere in the network that bottlenecks are likely to occur. It can be used in network designs to increase bandwidth between switches and between routers and switches—as well as providing scalable bandwidth for network servers, such as large UNIX servers or PC-based Web servers.
• Flexible incremental bandwidth—Cisco EtherChannel technology provides bandwidth aggregation in multiples of 100 Mbps, 1 Gbps, or 10 Gbps, depending on the speed of the aggregated links. For example, network managers can deploy EtherChannel technology that consists of pairs of full-duplex Fast Ethernet links to provide more than 400 Mbps between the wiring closet and the data center. In the data center, bandwidths of up to 800 Mbps can be provided between servers and the network backbone to provide large amounts of scalable incremental bandwidth.
• Load balancing—Cisco EtherChannel technology is composed of several Fast Ethernet links and is capable of load balancing traffic across those links. Unicast, broadcast, and multicast traffic is evenly distributed across the links, providing higher performance and redundant parallel paths. When a link fails, traffic is redirected to the remaining links within the channel without user intervention and with minimal packet loss.
• Resiliency and fast convergence—When a link fails, Cisco EtherChannel technology provides automatic recovery by redistributing the load across the remaining links. When a link fails, Cisco EtherChannel technology redirects traffic from the failed link to the remaining links in less than one second. This convergence is transparent to the end user—no host protocol timers expire, so no sessions are dropped.
• Ease of management—Cisco EtherChannel technology takes advantage of Cisco experience developed over the years in troubleshooting and maintaining Ethernet networks. Existing network probes can be used for traffic management and troubleshooting, and management applications such as CiscoWorks and third-party management applications are now EtherChannel-aware.
• Transparent to network applications—Cisco EtherChannel technology does not require changes to networked applications. When EtherChannel technology is used within the campus, switches and routers provide load balancing across multiple links transparently to network users. To support EtherChannel technology on enterprise-class servers and network interface cards, smart software drivers can coordinate distribution of loads across multiple network interfaces.
• Compatible with Cisco IOS® Software—Cisco EtherChannel connections are fully compatible with Cisco IOS virtual LAN (VLAN) and routing technologies. The Inter-Switch Link (ISL) VLAN Trunking Protocol (VTP) can carry multiple VLANs across an EtherChannel link, and routers attached to EtherChannel trunks can provide full multiprotocol routing with support for hot standby using the Hot Standby Router Protocol (HSRP).
• 100 Megabit, 1 Gigabit, and 10 Gigabit Ethernet-ready—Cisco EtherChannel technology is available in all Ethernet link speeds. EtherChannel technology allows network managers to deploy networks that will scale smoothly with the availability of next-generation, standards-based Ethernet link speeds.
• Interoperability with Coarse Wavelength Division Multiplexing (CWDM) Gigabit Interface Converters (GBICs)—By simultaneously implementing Gigabit EtherChannel and CWDM technologies, network managers can increase the bandwidth of their links without having to invest in new long runs of fiber. CWDM technologies allow the traffic aggregated by the Cisco EtherChannel link to be multiplexed on to a single strand of fiber.
Cisco EtherChannel Components
Cisco EtherChannel technology is a trunking technology based on grouping several full-duplex 802.3 Ethernet links to provide fault-tolerant, high-speed links between switches, routers, and servers. It is based on proven industry-standard technology—it has been extended from the EtherChannel technology offered by Kalpana in its switches in the early 1990s, and provides load sharing across multiple Fast Ethernet links while providing redundancy and subsecond convergence times.
Cisco EtherChannel technology consists of the following key elements:
• Fast Ethernet links—Cisco EtherChannel connections can consist of one to eight industry-standard Fast Ethernet links to load share traffic with up to 80 Gbps of usable bandwidth. EtherChannel connections can interconnect LAN switches, routers, servers, and clients. Because load balancing is integrated with Cisco Catalyst®LAN switch architectures, there is no performance degradation for adding links to a channel—high throughput and low latencies can be maintained while gaining more available bandwidth. EtherChannel technology provides link resiliency within a channel—if links fail, the traffic is immediately directed to the remaining links. Finally, EtherChannel technology is not dependent on any type of media—it can be used with Ethernet running on existing unshielded twisted pair (UTP) wiring, or single-mode and multimode fiber.
• Cisco EtherChannel technology is a standard feature across the entire Cisco Catalyst series of switches and Cisco IOS® Software-based routers. The load-sharing algorithms used vary between platforms, allowing for decisions based on source or destination Media Access Control (MAC) addresses, IP addresses, or Transmission Control Protocol/User Datagram Protocol (TCP/UDP) port numbers.
• Redundancy—Cisco EtherChannel technology does not require the use of 802.1D Spanning-Tree Protocol to maintain a topology state within the channel. Rather, it uses a peer-to-peer control protocol that provides autoconfiguration and subsecond convergence times for parallel links, yet allows higher-level protocols (such as Spanning-Tree Protocol) or existing routing protocols to maintain topology. This approach allows EtherChannel technology to use the recovery features of the network without adding complexity or creating incompatibilities with third-party equipment or software. Because the Spanning-Tree Protocol operation is completely standards-based, network managers can use their existing network topologies, augmenting bandwidth by installing EtherChannel technology where single Ethernet links were previously installed.
• Management—Cisco EtherChannel technology is easily configured by a command-line interface (CLI) or by Simple Network Management Protocol (SNMP) applications such as CiscoWorks. A network manager needs to identify and define the number of ports that will make up the channel, and then connect the devices. CiscoWorks for Switched Internetworks will graphically display EtherChannel connections between devices, collect statistics for both individual Ethernet links within the channel, and aggregate statistics for the EtherChannel connection. An integral benefit of EtherChannel technology is the ability to detect, report, and prevent the use of incorrectly paired interfaces within the channel. These may include interfaces that are not configured for full-duplex operation, have mismatched link speeds, or are incorrectly wired. Consistency checks are completed before the activation of a channel to help ensure network integrity.
Saturday, June 12, 2010
EtherChannel on various models of Cisco Switches
Catalyst 4500/4000 Series
Catalyst OS
In the Catalyst 4500/4000 series switches with CatOS (Supervisor Engine I and II), you can form an EtherChannel with up to eight compatibly configured Fast Ethernet or Gigabit Ethernet ports on the switch. The exact EtherChannel formation depends on the hardware. Because the spanning tree feature handles the port ID, the maximum number of channels is 126 for a six-slot chassis. In addition, you can configure an EtherChannel with the use of ports from multiple modules in CatOS release 5.x and later. All ports in an EtherChannel must be the same speed.
Catalyst OS for Catalyst 4500/4000 uses MAC address based load balancing. EtherChannel distributes frames across the links in a channel based on the low-order bits of the source and destination MAC addresses of each frame. The frame distribution method is not configurable.
Cisco IOS
A Catalyst 4500/4000 series switch with Cisco IOS Software (Supervisor Engine II+ and later) supports a maximum of 64 EtherChannels. You can form an EtherChannel with up to eight compatibly configured Ethernet interfaces on any module and across modules. All interfaces in each EtherChannel must be the same speed, and you must configure all the interfaces as either Layer 2 or Layer 3 interfaces.
EtherChannel reduces part of the binary pattern that is formed from the addresses in the frame to a numerical value that selects one of the links in the channel in order to balance the traffic load across the links in a channel. EtherChannel load balancing can use MAC addresses, IP addresses, or Layer 4 port numbers and either source mode, destination mode, or both. Use the option that provides the greatest variety in your configuration. For example, if the traffic on a channel only goes to a single MAC address, use of the destination MAC address results in the choice of the same link in the channel each time. Use of source or IP addresses can result in a better load balance. Issue the port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip | src-dst-ip | src-port | dst-port | src-dst-port} global configuration command in order to configure load balancing. Load Balance must be configured globally and the load balancing option cannot be changed on a per port basis.
Note: The switch uses the lower order bits of source MAC address and destination MAC address in order to determine which links must be used to transmit the data. So if the data is received from the same source, then same link of the EtherChannel is used in order to forward the data.
Catalyst 2900XL/3500XL Series
A Catalyst 2900XL that runs a Cisco IOS software release that is earlier than Cisco IOS Software Release 11.2(8)SA3 chooses a link in the channel based on the link on which the destination MAC address was last heard. The software dynamically reallocates this address to another link in the channel if the link on which the address was learned is busier than the others. You can configure a Catalyst 2900XL that runs Cisco IOS Software Release 11.2(8)SA3 or later and a Catalyst 3500XL that runs Cisco IOS Software Release 11.2(8)SA6 or later in order to choose a link to be sent across the Fast EtherChannel. The switch chooses the link on the basis of the destination or source MAC address of the frame. The default is to use the source MAC address. This default means that all packets that the switch receives on a non-Fast EtherChannel port with the same MAC source address that have a destination of the MAC addresses on the other side of the channel take the same link in the channel. Use source-based forwarding when many stations that are attached to the Catalyst 2900XL/3500XL send to a few stations, such as a single router, on the other side of the Fast EtherChannel. The use of source-based forwarding in this situation evenly distributes traffic across all links in the channel. Also, the Catalyst 2900XL/3500XL switches maintain a notion of a default port on which to transmit traffic, such as Spanning Tree Protocol (STP), multicasts, and unknown unicasts.
Catalyst 3750/3560
The Catalyst 3750/3560 series switch can support up to eight compatibly configured Ethernet interfaces in an EtherChannel. The EtherChannel provides full-duplex bandwidth up to 800 Mbps (Fast EtherChannel) or 8 Gbps (Gigabit EtherChannel) between your switch and another switch or host. With Cisco IOS Software Release 12.2(20)SE and earlier, the number of EtherChannels has a limit of 12. With Cisco IOS Software Release 12.2(25)SE and later, the number of EtherChannels has a limit of 48.
EtherChannel balances the traffic load across the links in a channel through the reduction of part of the binary pattern that the addresses in the frame form to a numerical value that selects one of the links in the channel. EtherChannel load balancing can use MAC addresses or IP addresses, source or destination addresses, or both source and destination addresses. The mode applies to all EtherChannels that are configured on the switch. You configure the load balancing and forwarding method with use of the port-channel load-balance {dst-ip | dst-mac | src-dst-ip | src-dst-mac | src-ip | src-mac} global configuration command.
You can find out which interface is used in the EtherChannel to forward traffic based on the load balancing method. The command for this determination is test etherchannel load-balance interface port-channel number {ip | mac} [source_ip_add | source_mac_add] [dest_ip_add | dest_mac_add].
Catalyst 2950/2955/3550
The Catalyst 2950/2955 series switch can support up to eight compatibly configured Ethernet interfaces in an EtherChannel. The EtherChannel can provide full-duplex bandwidth up to 800 Mbps (Fast EtherChannel) or 2 Gbps (Gigabit EtherChannel) between your switch and another switch or host. The number of EtherChannels has the limit of six with eight ports per EtherChannel.
The Catalyst 3550 series switches support both Layer 2 and Layer 3 EtherChannel, with up to eight compatibly configured Ethernet interfaces. The EtherChannel provides full-duplex bandwidth up to 800 Mbps (Fast EtherChannel) or 8 Gbps (Gigabit EtherChannel) between your switch and another switch or host. The limit of the number of EtherChannels is the number of ports of the same type.
For the 2950/2955/3550 series switch, EtherChannel balances the traffic load across the links in a channel by randomly associating a newly learned MAC address with one of the links in the channel. EtherChannel load balancing can use either source-MAC or destination-MAC address forwarding.
With source-MAC address forwarding, when packets are forwarded to an EtherChannel, the packets are distributed across the ports in the channel based on the source-MAC address of the incoming packet. Therefore, to provide load balancing, packets from different hosts use different ports in the channel, but packets from the same host use the same port in the channel. With destination-MAC address forwarding, when packets are forwarded to an EtherChannel, the packets are distributed across the ports in the channel based on the destination host MAC address of the incoming packet. Therefore, packets to the same destination are forwarded over the same port, and packets to a different destination are sent on a different port in the channel.
For the 3550 series switch, when source-MAC address forwarding is used, load distribution based on the source and destination IP address is also enabled for routed IP traffic. All routed IP traffic chooses a port based on the source and destination IP address. Packets between two IP hosts always use the same port in the channel, and traffic between any other pair of hosts can use a different port in the channel.
Issue the port-channel load-balance {dst-mac | src-mac} global configuration command in order to configure the load-balance and forward method.
Note: The default port is used to transmit traffic, such as Spanning Tree Protocol (STP), multicasts, and unknown unicasts. The default port can be identified from the output of the command show etherchannel summary by a notation of d.
Catalyst 1900/2820
With the enablement of PAgP, the two possible methods of link determination are preserve order and maximize load balancing between the links on the Fast EtherChannel. The What Is PAgP and Where Do You Use It? section of this document describes PAgP. The default is to maximize load balancing. PAgP is used to negotiate the configured method with the device at the other side of the channel. If preserve order is configured, the device at the other side is instructed in order to use source-based transmissions so that the Catalyst 1900/2820 always receives packets with the same source MAC address on the same link in the channel. This is the link that the Catalyst 1900/2820 always uses to send traffic to this MAC address. If maximize load balancing is configured, PAgP tells the other side that it can distribute traffic arbitrarily, and unicast traffic is transmitted by the Catalyst 1900/2820 on the link where the source address was last seen. This provides the maximum possible load-balancing configuration. When Fast EtherChannel is configured with PAgP disabled, the switch cannot negotiate with the partner about the switch learning capability. Whether the switch preserves frame ordering depends on whether the Fast EtherChannel partner performs source-based distribution. The Catalyst 1900/2820s also elect an active port. The active port is used for flooded traffic such as unknown unicast, unregistered multicast, and broadcast packets. If the port-channel mode is on (PAgP disabled), the active port is the link with the highest priority value. If the mode is desirable or auto (PAgP enabled), the active port is selected based on the priority of the links on the switch that has the higher Ethernet address. When two ports on the switch with the higher Ethernet address have the same priority, the port with the lower ifIndex is selected.
Catalyst 2948G-L3/4908G-L3 and Catalyst 8500
When one link fails, all traffic that previously used that link now uses the link next to it. For example, if Link 1 fails in a bundle, traffic that previously used Link 1 before the failure now uses Link 2.
Catalyst OS
In the Catalyst 4500/4000 series switches with CatOS (Supervisor Engine I and II), you can form an EtherChannel with up to eight compatibly configured Fast Ethernet or Gigabit Ethernet ports on the switch. The exact EtherChannel formation depends on the hardware. Because the spanning tree feature handles the port ID, the maximum number of channels is 126 for a six-slot chassis. In addition, you can configure an EtherChannel with the use of ports from multiple modules in CatOS release 5.x and later. All ports in an EtherChannel must be the same speed.
Catalyst OS for Catalyst 4500/4000 uses MAC address based load balancing. EtherChannel distributes frames across the links in a channel based on the low-order bits of the source and destination MAC addresses of each frame. The frame distribution method is not configurable.
Cisco IOS
A Catalyst 4500/4000 series switch with Cisco IOS Software (Supervisor Engine II+ and later) supports a maximum of 64 EtherChannels. You can form an EtherChannel with up to eight compatibly configured Ethernet interfaces on any module and across modules. All interfaces in each EtherChannel must be the same speed, and you must configure all the interfaces as either Layer 2 or Layer 3 interfaces.
EtherChannel reduces part of the binary pattern that is formed from the addresses in the frame to a numerical value that selects one of the links in the channel in order to balance the traffic load across the links in a channel. EtherChannel load balancing can use MAC addresses, IP addresses, or Layer 4 port numbers and either source mode, destination mode, or both. Use the option that provides the greatest variety in your configuration. For example, if the traffic on a channel only goes to a single MAC address, use of the destination MAC address results in the choice of the same link in the channel each time. Use of source or IP addresses can result in a better load balance. Issue the port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip | src-dst-ip | src-port | dst-port | src-dst-port} global configuration command in order to configure load balancing. Load Balance must be configured globally and the load balancing option cannot be changed on a per port basis.
Note: The switch uses the lower order bits of source MAC address and destination MAC address in order to determine which links must be used to transmit the data. So if the data is received from the same source, then same link of the EtherChannel is used in order to forward the data.
Catalyst 2900XL/3500XL Series
A Catalyst 2900XL that runs a Cisco IOS software release that is earlier than Cisco IOS Software Release 11.2(8)SA3 chooses a link in the channel based on the link on which the destination MAC address was last heard. The software dynamically reallocates this address to another link in the channel if the link on which the address was learned is busier than the others. You can configure a Catalyst 2900XL that runs Cisco IOS Software Release 11.2(8)SA3 or later and a Catalyst 3500XL that runs Cisco IOS Software Release 11.2(8)SA6 or later in order to choose a link to be sent across the Fast EtherChannel. The switch chooses the link on the basis of the destination or source MAC address of the frame. The default is to use the source MAC address. This default means that all packets that the switch receives on a non-Fast EtherChannel port with the same MAC source address that have a destination of the MAC addresses on the other side of the channel take the same link in the channel. Use source-based forwarding when many stations that are attached to the Catalyst 2900XL/3500XL send to a few stations, such as a single router, on the other side of the Fast EtherChannel. The use of source-based forwarding in this situation evenly distributes traffic across all links in the channel. Also, the Catalyst 2900XL/3500XL switches maintain a notion of a default port on which to transmit traffic, such as Spanning Tree Protocol (STP), multicasts, and unknown unicasts.
Catalyst 3750/3560
The Catalyst 3750/3560 series switch can support up to eight compatibly configured Ethernet interfaces in an EtherChannel. The EtherChannel provides full-duplex bandwidth up to 800 Mbps (Fast EtherChannel) or 8 Gbps (Gigabit EtherChannel) between your switch and another switch or host. With Cisco IOS Software Release 12.2(20)SE and earlier, the number of EtherChannels has a limit of 12. With Cisco IOS Software Release 12.2(25)SE and later, the number of EtherChannels has a limit of 48.
EtherChannel balances the traffic load across the links in a channel through the reduction of part of the binary pattern that the addresses in the frame form to a numerical value that selects one of the links in the channel. EtherChannel load balancing can use MAC addresses or IP addresses, source or destination addresses, or both source and destination addresses. The mode applies to all EtherChannels that are configured on the switch. You configure the load balancing and forwarding method with use of the port-channel load-balance {dst-ip | dst-mac | src-dst-ip | src-dst-mac | src-ip | src-mac} global configuration command.
You can find out which interface is used in the EtherChannel to forward traffic based on the load balancing method. The command for this determination is test etherchannel load-balance interface port-channel number {ip | mac} [source_ip_add | source_mac_add] [dest_ip_add | dest_mac_add].
Catalyst 2950/2955/3550
The Catalyst 2950/2955 series switch can support up to eight compatibly configured Ethernet interfaces in an EtherChannel. The EtherChannel can provide full-duplex bandwidth up to 800 Mbps (Fast EtherChannel) or 2 Gbps (Gigabit EtherChannel) between your switch and another switch or host. The number of EtherChannels has the limit of six with eight ports per EtherChannel.
The Catalyst 3550 series switches support both Layer 2 and Layer 3 EtherChannel, with up to eight compatibly configured Ethernet interfaces. The EtherChannel provides full-duplex bandwidth up to 800 Mbps (Fast EtherChannel) or 8 Gbps (Gigabit EtherChannel) between your switch and another switch or host. The limit of the number of EtherChannels is the number of ports of the same type.
For the 2950/2955/3550 series switch, EtherChannel balances the traffic load across the links in a channel by randomly associating a newly learned MAC address with one of the links in the channel. EtherChannel load balancing can use either source-MAC or destination-MAC address forwarding.
With source-MAC address forwarding, when packets are forwarded to an EtherChannel, the packets are distributed across the ports in the channel based on the source-MAC address of the incoming packet. Therefore, to provide load balancing, packets from different hosts use different ports in the channel, but packets from the same host use the same port in the channel. With destination-MAC address forwarding, when packets are forwarded to an EtherChannel, the packets are distributed across the ports in the channel based on the destination host MAC address of the incoming packet. Therefore, packets to the same destination are forwarded over the same port, and packets to a different destination are sent on a different port in the channel.
For the 3550 series switch, when source-MAC address forwarding is used, load distribution based on the source and destination IP address is also enabled for routed IP traffic. All routed IP traffic chooses a port based on the source and destination IP address. Packets between two IP hosts always use the same port in the channel, and traffic between any other pair of hosts can use a different port in the channel.
Issue the port-channel load-balance {dst-mac | src-mac} global configuration command in order to configure the load-balance and forward method.
Note: The default port is used to transmit traffic, such as Spanning Tree Protocol (STP), multicasts, and unknown unicasts. The default port can be identified from the output of the command show etherchannel summary by a notation of d.
Catalyst 1900/2820
With the enablement of PAgP, the two possible methods of link determination are preserve order and maximize load balancing between the links on the Fast EtherChannel. The What Is PAgP and Where Do You Use It? section of this document describes PAgP. The default is to maximize load balancing. PAgP is used to negotiate the configured method with the device at the other side of the channel. If preserve order is configured, the device at the other side is instructed in order to use source-based transmissions so that the Catalyst 1900/2820 always receives packets with the same source MAC address on the same link in the channel. This is the link that the Catalyst 1900/2820 always uses to send traffic to this MAC address. If maximize load balancing is configured, PAgP tells the other side that it can distribute traffic arbitrarily, and unicast traffic is transmitted by the Catalyst 1900/2820 on the link where the source address was last seen. This provides the maximum possible load-balancing configuration. When Fast EtherChannel is configured with PAgP disabled, the switch cannot negotiate with the partner about the switch learning capability. Whether the switch preserves frame ordering depends on whether the Fast EtherChannel partner performs source-based distribution. The Catalyst 1900/2820s also elect an active port. The active port is used for flooded traffic such as unknown unicast, unregistered multicast, and broadcast packets. If the port-channel mode is on (PAgP disabled), the active port is the link with the highest priority value. If the mode is desirable or auto (PAgP enabled), the active port is selected based on the priority of the links on the switch that has the higher Ethernet address. When two ports on the switch with the higher Ethernet address have the same priority, the port with the lower ifIndex is selected.
Catalyst 2948G-L3/4908G-L3 and Catalyst 8500
When one link fails, all traffic that previously used that link now uses the link next to it. For example, if Link 1 fails in a bundle, traffic that previously used Link 1 before the failure now uses Link 2.
Thursday, June 10, 2010
Subscribe to:
Posts (Atom)