Jaycee's Networking

June 12, 2010

Enable/Establish BGP

Filed under: BGP, IOS — Tags: , — Jaycee @ 7:54 pm

I. BGP Overview:

1. Path Vector EGP – used to exchange prefix information b/w ASs.

2. Uses TCP port 179 for transport:

a. Required underlying IGP
b. Network cannot route on BGP alone

II. Enabling BGP:

1. Enable the global process

router bgp [AS]

*Only one processes per router

2. Establish BGP Peerings

neighbor [address] remote-as [AS]

*Need to have ip reach-ability

III. Establishing BGP Peerings:

1. Two types of peers:

iBGP – member of the same AS
EBGP – members of different ASs

2. TCP 179 for transport

Normal TCP operations apply

3. Listen for address 1.2.3.4 starting a TCP session at port 179:

neighbor 1.2.3.4 remote-as 100

(router is doing “show ip route 1.2.3.4”, and do router recursion process to the interface – source of the BGP packet is from)

4. TCP server must agree on where the session is coming from. Need to know which one is TCP Client and which one is TCP Server.

bgp-notes-01

5. TCP Client has the higher BGP router-id

6. If server doesn’t expect session it will refuse

7. Packet sourced from outgoing interface in the routing table

BGP update source

*If there are multiple links b/w BGP peers, you can use “bgp update source” to update the BGP source interface.

(15:00)

IV.

Advertisements

November 6, 2009

Decision of BGP Path Selection on IOS and JUNOS

Filed under: BGP, IOS — Tags: , , — Jaycee @ 11:02 am

BGP Path Selection Process Decision Steps

IOS

JUNOS

Next-Hop accessible/resolvable (mandatory
attribute)
By default, the NEXT-HOP is changed for EBGP and is unchanged for iBGP.

 

The NEXT-HOP identifies the EBGP speaker in the adjoining AS, and IGP will not carry this route, thereby leading to an unreachable next hop.

Synchronization

BGP process expects the IGP to have a copy of each route before that route can be advertised by BGP. This is why disabling synchronization is the 1st step in IOS configuration.

NONE.

Weight (Influences OUTBOUND traffic, but apply on inbound). This is Cisco proprietary parameter given to a route on a particular router and is used only within that router. The weight is never given to other routers.

 

*Default weight = 0, except for locally sourced routes which get a default weight = 32,768. The maximum weight is 65,535.

*Weight value => the higher the better.

NONE.

Local Preference (Influences OUTBOUND traffic,
but apply on inbound).
(discretionary attribute)

 

Local preferences are shared among iBGP routers, but they are NOT shared with external BGP routers.

 

*Default Local_PREF = 100.

*Local_PREF value => the higher the better.

Self-Originated

BGP routes prefer routes that originate inside their own AS. That is, to choose the route that originated with BGP on this router.
AS Path (Influences INBOUND traffic, but apply on outbound). (mandatory
attribute)
By default, BGP discards any route advertisement that contains its local AS number in the AS path to prevent routing loop. For routes that originate outside of the AS, BGP will prefer the one with the shortest path.
Origin. (mandatory attribute)

 

ORIGIN has 3 values:

0 = IGP, 1 = EGP, 2 = Incomplete

BGP selects IGP routes in preference to EGP, and EGP in preference to INCOMPLETE routes. An INCOMPLETE route is one that is injected into BGP via redistribution.

*Origin value => the lower the better.

MED (Influences INBOUND traffic, but apply on outbound). (nontransitive attribute)

 

Use MED to tell your ISPs which of several entrances to your
network they should use. You should use MED values ONLY IF you are multihomed to a single provider. MED values are ONLY propagated to adjacent ASes, so routers that are further downstream don’t see them at all.

MED is used by the local AS to influence the routing decisions in an adjacent AS for traffic that is inbound to the local AS. BGP selects the route with the lowest MED value. MED actually leaves your AS and tells your neighbor routers which link we want them to talk to.

 

*Default MED = 0.

*MED value => the lower the better

MED is used ONLY if both routes are received from the same AS, or if the command “bgp always-compare-med” has been enabled.

 

With “bgp always-compare-med” enabled, BGP will compare MED values even if they come from different ASes, although to reach this step the AS_PATHs must have the same length. You should use this command throughout the AS or you risk creating routing loops.

External

 

BGP prefer the paths learned using EBGP over paths learned using iBGP to eliminate loops.

EBGP AD = 20 is lower than other IGP because it should go out of the AS instead of staying in AS.

 

iBGP AD = 200 is higher than other IGP because if it¡¯s an internal route, it should use internal IGP.

BGP default protocol preference = 170
IGP Cost

 

BGP prefers paths with the lowest IGP metric.

a. Make sure disabling synchronization.

 

b. Choose the routes with the lowest IGP administrative distance.

a. Examine route tables inet.0 and inet.3 for the BGP next hop, and then install the physical next hop for the route with the better preference.

 

b. For preference ties, install the physical next hop found in inet.3.

c. For preference ties within the same route table, install the physical next hop where the greater number of equal-cost paths exists.

eBGP
Peering/Ages of the routes
BGP will look at the ages of the routes and use the oldest route to particular destination for stability.
Router ID A router’s ID is the IP address assigned to the loopback interface or the highest IP address on an active interface at boot time.

 

*Router ID => the lower the better

October 15, 2009

IOS ADs vs JUNOS Preferences

Filed under: IOS, Junos — Tags: , — Jaycee @ 8:17 pm
Source IOS administrative distance JUNOS protocol preference Purpose
Local 0 0 Local IP of the interface
Connected Interface 0 0 Subnet corresponding to the directly connected interface
System Routes 4
Static 1 5 Static routes
RSVP 7 Routes learned from the Resource Reservation Protocol used in MPLS
LDF 8
LDP 9 Routes learned from the Label Distribution Protocol used in MPLS
OSPF internal route 10 OSPF internal routes such as interfaces that are running OSPF
IS-IS Level 1 internal route 15 IS-IS Level 1 internal routes such as interfaces that are running ISIS
IS-IS Level 2 internal route 18 IS-IS Level 2 internal routes such as interfaces that are running ISIS
EBGP 20
Redirects 30 Routes from ICMP redirect
Kernel 40 Routes learned via route socket from kernel
SNMP 50 Routes installed by NMS through the SNMP
Router discovery 55 Routes installed by ICMP Router Discovery
Internal EIGRP 90 Cisco proprietary routing protocol
RIP 100 Routes from Routing Information Protocol (IPv4)
RIPng 100 Routes from Routing Information Protocol (IPv6)
IGRP 100 Internal Gateway Routing Protocol
PIM 105 Routes from Protocol Independent Multicast
DVMRP 110 Routes from Distance Vector Multicast
OSPF 110
IS-IS 115
RIP 120 Routes from Routing Information Protocol
Aggregate 130 Aggregate and generated routes
EGP 140 Routes from Exterior Gateway Protocol
OSPF AS external routes 150 Routes from OSPF that have been redistributed into OSPF
ODR 160 On Demand Routing
IS-IS Level 1 external route 160 Routes from IS-IS Level 1 that have been redistributed into ISIS
IS-IS Level 2 external route 165 Routes from IS-IS Level 2 that have been redistributed into ISIS
BGP 170 Routes from BGP
MSDP 175
External EIGRP 170
iBGP 200
Unknown 255 255

August 21, 2009

Router Design Concept

Filed under: IOS, Routing Design — Tags: , — Jaycee @ 3:58 pm
GRES (graceful Routing Engine switchover) – In a router that contains a master and a backup Routing Engine, allows the backup Routing Engine to assume mastership automatically, with no disruption of packet forwarding.
Graceful switchover — JUNOS software feature that allows a change from the primary device, such as a Routing Engine, to the backup device without interruption of packet forwarding.

(lecture by Tim Chung)

1. Basic Router and Routing:

basic-routing-01

a. R1 and R2 has routing protocol (i.e RIP or OSPF), so the computer can reach the destination server 10.0.0.1.

b. R2 is a single CPU router which is like a Linux server doing a routing job.

c. A single CPU needs to process all of the packets whichever goes through the router. If the computer is sending too many data packets through R2, then the CPU of R2 is going to be occupied by the data packets.

d. When CPU is too busy (up to 99%~100% usage) on processing the data packets, other important packets for control, such as routing protocols, SNMP, wouldn’t be processed in time which would cause routing adjacency dropped. All of the data packets would not reach the destination.

e. Thus, Cisco 2800 series can only do T1 since it’s a single RISC processor, and Juniper J-series is also single IBM CPU. They both couldn’t handle high traffic. They are both software based routers.

2. For modern routers, they have more than 1 CPU doing data packet forwarding and processing control information.

router-basic-02

a. Take Juniper router as an example, a router has 2 plane: RE and PFE. All of the data packets going through PFE and goes out.

b. PFE passes all important control packets to RE.

c. In this way, router wouldn’t drop the adjacency which wont lose the routes. Data packets can be sent to the destination.

3. For Redundancy:

router-basic-03

a. Uses fabric between RE and PFE and PIC for high traffic transmissions.

b. Uses full-mesh x-bar for PFEs.

4. For more redundancy with GRES:

router-basic-04

August 16, 2009

6500 Multilayer Switches

Filed under: IOS — Tags: , , — Jaycee @ 2:54 pm
*Multilayer switches are divided by chassis type.
SUP-32 = Supervisor 32Gbps backplane bus
SUP-720 = Supervisor 720Gbps fabric bus with 1,440Gbps on the horizon.
SVIs (Switched Virtual Interfaces)
GSR (Gigabit Switch Router)
GBIC (Gigabit Interface Converter)
SFP (Small Form-factor Pluggable)
dCEF (distributed Cisco Express Forwarding)
MSFC (Multilayer Switch Function Card)
PFC (Policy Feature Card)
DFC (Distributed Feature Card)
SFM (Switch Fabric Module)
FWSM (Firewall Services Module) – security module
CSM (Content Switching Module) – load-balancing
NAM (Network Analysis Module) – monitoring
IDSM (Intrusion Detection System Module)
CMM (Communication Media Module) – VoIP connectivity
VMS (VPN/Security Management Solution)
MARS (Monitoring, Analysis, and Response System)

NEBS (Network Equipment Building System)


1. 6500e (enhanced) chassis Power:

a. 6000-watt AC power supply requires 2 power outlets per supply => 4 outlets per chassis

b. 8700-watt AC power supply requires 3 power outlets per supply => 6 outlets per chassis

c. The power supplies can be configured in a failover mode or a combined mode to allow more power for hungry modules.

2. Modules:

a. Most of the modules are hot-swappable, but some modules must be shutdown before being removed.

b. Modules communicate with each other over the backplane, thus they have faster speed than the  standalone counterparts.

=> FWSM is capable of more than 4Gbps throughput, but the fastest standalone PIX is capable of only 1.5 Gbps.

3. Architecture:

a. 6000-series has 32 Gbps backplane bus

b. 6500-series has fabric bus (or crossbar switching bus) allows backplane speeds to be boosted up to 720 Gbps.

c. SFM is a 16-port switch that connects each of the fabric-enabled modules via the fabric bus.

1) SFM could only reside in certain slots.
2) Sup-720 includes the SFM’s functionality, it must reside in the SFM’s slots.
3) For 6509, Sup-720 modules must reside in slots 5 and 6.

d. Buses:

1) D bus (data bus):

1.1) 32 Gbps
1.2) D bus is shared like a traditional Ethernet network, in that all modules receive all frames that are placed on the bus.

2) R bus (result bus):

2.1) 4 Gbps
2.2) handles communication b/w the modules and the switching logic on the supervisors.

3) C bus (control bus), EOBC (Ethernet Out-of-Band Channel):

3.1) 100 Mbps half-duplex
3.2) is used for communication b/w the line cards and the network management processors on the supervisors.

4) Crossbar fabric bus:

4.1) “Fabric” is used to describe the mesh of connections.
4.2) Crossbar Fabric is a type of switching technology – each node is connected to every other node
4.3) Fully Interconnected Fabric – each port is directly connected to every other port

switch fabric examples

4.4) The crossbar fabric bus, in combination with a Sup-2 and a SFM, is capable of 256 Gbps and 30 Mpps (million packet per second).

4.5) With the addition of a dCEF, this combination is capable of 210 Mpps.
4.6) With a Sup-720 module, crossbar fabric supports up to 720 Gbps.
4.7) When using dCEF interface module, a Sup-720 is capable of 400 Mpps.
4.8) SFM provides the actual switch fabric b/w all the fabric-enabled modules. SFM’s functionality is included in the Sup-720 already.

e. 6509 backplanes:

6509 backplanes

1) Two backplane circuit boards separated by a vertical space.
2) 6506-chassis doesn’t have slots 7,8, and 9.
3) 6513-chassis has Sup-720 in slot 7 and 8.

e. Enhanced Chassis:

1) 6500e is designed to allow more power to be drawn to the line cards. i.e. PoE line cards.
2) It uses high-speed fans to cool these power-hungry modules.
3) it provides a redesgined backplane – allows for a total of 80 Gbps of throughput per slot. (standard 6500 has 40 Gbps of throughput per slot)
4) The new architecture will allow eight 10 Gbps ports per blade with no oversubsciption.

f. Supervisors:

1) Chassis-based switches don’t have processors built into them. Instead, the processor is on a module: Supervisor.

2) MSFC:

2.1) Supervisors offer L2 processing capabilities with an add-on daughter card, MSFC, supports L3 and higher functionality.
2.2) MSFC3 is part of the Sup-720.

3) PFC:

3.1) A daughter card supports QoS, no direct configuration of the PFC is required.
3.2) PFC3 is part of the Sup720.

4) Sup-720:

4.1) Capable of 400 Mpps (million packet per second) and 720 Gbps
4.2) It’s designed for bandwidth-hungry installation
4.3) It includes PFC3 and MSFC3, a new accelerated CEF and dCEF capabilities
4.4) Fabric-only modules are capable of 40 Gbps throughput with a Sup-720.
4.5) Sup-720 has two CompactFlash Type II slots. The keywords for the slots on the active Sup-720 are disk0: and disk1:.
4.6) The CompactFlash Type II slots support CompactFlash Type II Flash PC cards sold by Cisco.
4.7) Sup-720 port 1 has a SFP connector w/o unique configuration options.
4.8) Sup-720 port 2 has a RJ-45 connector and an SFP connector (default).

To configure port 2 with RJ-45:

R1# int gi5/2
R1(config-if)# media-type rj45  

To configure port 2 with SFP:

R1# int gi5/2
R1(config-if)# media-type sfp

4.9)

5) Forwarding Deciscions for L3 Traffic:

PFC3 or DFC3 makes the forwarding deciscion for L3 traffic:

5.1) PFC3 makes all forwarding decisions for each packet that enters the switch through a module without a DFC3.
5.2) DFC3 makes all forwarding decisions for each packet that enters the switch on a DFC3-enabled module in 3 situations:

5.2.1) If the egress port is on the same module as the ingress port, the DFC3 forwards the packet locally (the packet never leaves the module).
5.2.2) If the egress port is on a different fabric-enabled module, the DFC3 sends the packet to the egress module, which sends it out the egress port.
5.2.3) If the egress port is on a different nonfabric-enabled module, the DFC3 sends the packet to the Sup-720. The Sup-720 fabric interface transfers the packet to the 32-Gbps switching bus where it is received by the egress module and is sent out the egress port.

g. Modules:

1) Nonfabric-enabled module: A module doesn’t support crossbar fabric

=>It only has connectors on one sides, for connection to the D bus.

2) Fabric-enabled module: A module that supports the 32 Gbps D bus and fabric bus

=> It has two connectors on the back of the blade: one for the D bus, and one for the crossbar fabric bus.

3) Fabric-only module: a module that uses only the fabric bus

=> It has a single connector on the fabric side, with no connector on the D bus side.

4) Sup-720 is operating in dCEF mode, which allows forwarding at up to 720 Gbps:

R1#sh mod
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
 1    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE      SAD192803ZN
 2    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE      SAL190415QR
 3   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SAD101205F1
 5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B       SAL1201GSDZ

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
 1  0014.1c6b.d87d to 0014.1c6b.d87e   2.2   12.2(14r)S5  12.2(33)SXI  Ok
 2  0013.1a23.216a to 0013.1a23.216b   2.2   12.2(14r)S5  12.2(33)SXI  Ok
 3  0015.f91d.d50c to 0015.f91d.d5db   2.3   12.2(14r)S5  12.2(33)SXI  Ok
 5  0016.9de6.7ae1 to 0016.9de6.7ae3   5.7   8.5(2)       12.2(33)SXI  Ok

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
 1  Distributed Forwarding Card WS-F6700-DFC3B     SAD0939021M  4.2    Ok
 2  Distributed Forwarding Card WS-F6700-DFC3B     SAD093803VY  4.2    Ok
 3  Centralized Forwarding Card WS-F6700-CFC       SAD100402PG  2.0    Ok
 5  Policy Feature Card 3       WS-F6K-PFC3B       SAL1208GK44  2.4    Ok
 5  MSFC3 Daughterboard         WS-SUP720          SAL1208GHM6  3.2    Ok

Mod  Online Diag Status
---- -------------------
 1  Pass
 2  Pass
 3  Pass
 5  Pass

R1#sh fabric switching-mode
Global switching mode is Compact
dCEF mode is not enforced for system to operate
Fabric module is not  required for system to operate
Modules are allowed to operate in bus mode
Truncated mode is allowed, due to presence of DFC, CEF720 module

Module Slot     Switching Mode
 1                     dCEF
 2                     dCEF
 3                 Crossbar
 5                     dCEF

5) Each of the fabric-only modules has two 20 Gbps connections to the crossbar fabric bus:

R1#sh fabric util
slot    channel    speed    Ingress %     Egress %
1          0        20G            0            3
1          1        20G            2            0
2          0        20G            0            3
2          1        20G            0            0
3          0        20G            0            0
3          1        20G            0            0
5          0        20G            0            0

6) Module Types:

Modules are generally divided into line cards and service modules: Line card offers connectivity, such as copper or fiber Ethernet. Service Modules offer functionality.

6.1) Ethernet modules:

6.1.1) Connectivity options: RJ-45, GBIC, small-form-factor GBIC, Amphenol connectors for direct connection to path panels.

ethernet module connectivity options
6.1.2) Port density: 4-port 10 Gbps XENPAK-based modules, 48-port 1Gbps RJ-45 modules, 96-port RJ-21 connector modules support 10/100 Mbps.

ethernet module port density range
6.1.3) Capability: PoE and dCEF

6.2) FWSM:

6.2.1) It’s as a PIX, the difference is that all connections are internal to the switch, resulting in very high throughput.
6.2.2) the interfaces are SVIs, so the FWSM is not limited to physical connections.
6.2.3) FWSM is capable of over 4 Gbps of throughput, comparing with 1.7 Gbps on the PIX 535.
6.2.4) FWSM is a separate device in the chassis. To login:

R1# session slot 8 proc 1
The default escape character is Ctrol-^, then x.
You can also type 'exit' at the remote prompt to end the session
Trying 127.0.0.81 ... Open

User Access Verification

Password:
Type help or '?' for a list of available commands.
R1> en
Password: ********

6.2.5) If FWSM is running in single-context mode, you’ll be able to run all PIX commands. If FWSM is running in multiple-context mode, you’ll need to change to the proper context to make changes.

R1# sho context
Context Name          Class        Interfaces            URL
 admin                default                            disk:/admin.cfg
*EComm                default      vlan20,30             disk:/Ecomm.cfg
R1# changeto context EComm
R1/EComm# sho int
Interface Vlan20 "outside", is up, line protocol is up
        MAC address 0008.4cff.b403, MTU 1500
        IP address 10.1.1.1, subnet mask 255.255.255.0
                Received 90083941155 packets, 6909049206185 bytes
                Transmitted 3710031826 packets, 1371444635 bytes
                Dropped 156162887 packets
Interface Vlan30 "inside", is up, line protocol is up
        MAC address 0008.4cff.b403, MTU 1500
        Transmitted 2954364369 packets, 7023125736 bytes
        Dropped 14255735 packets

6.3) CSM:

6.3.1) CSM is capable of 4Gbps of throughput.
6.3.2) All of the CSM commands are included in the switch’s CLI. Command for CSM are included under command:

R1 (config)# mod csm 9
R1 (config-module-csm)#

6.3.3) CSM is not fabric-enabled, it’s a 32 Gbps blade. Insert it into a switch that is using the fabric backplane will cause the supervisor to revert to bus mode instead of aster modes such as dCEF.
=> A switch with a Sup-720, fabric-only Ethernet modules, and a CSM will not run at 720 Gbps because of the CSM’s limited backplane connections.

6.3.4) CSM blades will operate in a stateful failover design. A pair of CSMs can synced with the command:

R1# hw-module csm 9 standby config-sync
R1 #
May  5 17:21:14: %CSM_SLB-6-REDUNDANCY_INFO: Module 9 FT info: Active: Bulk sync started
May  5 17:21:17  %CSM_SLB-4-REDUNDANCY_WARN: Module 9 FT warning: FT configuration might be out of sync.
May  5 17:21:24: %CSM_SLB-4-REDUNDANCY_WARN: Module 9 FT warning: FT configuration back in sync
May  5 17:21:26: %CSM_SLB-6-REDUNDANCY_INFO: Module 9 FT info: Active: Manual bulk sync completed

6.4) NAM:

6.4.1) NAM is a remote monitorying (RMON) probe and packet-capture device that controlled through a web browser with no extra software required.
6.4.2) NAM is able to capture more than one session at a time.
6.4.3) With the ability to capture from RSPAN sources, the NAM blade can be used to analyze traffic on any switch on the network.

6.5) IDSM: It’s a preconfigured Linux server that reside on a blade which connected to the crossar fabric bus.

6.6) FlexWAN module:

6.6.1) It allows the connection of WAN links, such as T1, DS3, OC3.
6.6.2) Two types of FlexAN modules: FlexWAN and Enhanced FlexWAN.
6.6.3) Difference b/w the two versions: CPU speed, memory capacity, and connection to the crossbar fabric bus.

6.7) CMM:

6.7.1) It provides telephony integration into 6500-series switches.
6.7.2) It’s fabric-enabled module has 3 slots which accept different port adapters.
6.7.3) A 6500 chassis can be filled with CMMs and a supervisor to provide large port density for VoIP connectivity.

h.  Switch Fabric Functionality Switching Modes:

1) Compact mode:

The switch uses this mode for all traffic when only fabric-enabled modules are installed. In this mode, a compact version of the D Bus header is forwarded over the switch fabric channel, which provides the best possible performance.

2) Truncated mode:

The switch uses this mode for traffic between fabric-enabled modules when there are both fabric-enabled and nonfabric-enabled modules installed. In this mode, the switch sends a truncated version of the traffic (the first 64 bytes of the frame) over the switch fabric channel.

3) Bus mode:

The switch uses this mode for traffic between nonfabric-enabled modules and for traffic between a nonfabric-enabled module and a fabric-enabled module. In this mode, all traffic passes between the local bus and the supervisor engine bus.

4) To allow use of nonfabric-enabled modules or to allow fabric-enabled modules to use bus mode:

R1(config)# fabric switching-mode allow bus-mode

To prevent use of nonfabric-enabled modules or to prevent fabric-enabled modules from using bus mode:

R1(config)# no fabric switching-mode allow bus-mode

=> power will be removed from any nonfabric-enabled modules installed in the switch.

6) To allow fabric-enabled modules to use truncated mode:

R1(config)# fabric switching-mode allow truncated

To prevent fabric-enabled modules from using truncated mode:

R1(config)# no fabric switching-mode allow truncated

7) Displaying switch fabric functionality modes:

R1# sh fabric active
Active fabric card in slot 5
No backup fabric card in the system

R1# show fabric switching-mode module 5
Module Slot     Switching Mode
 5                     dCEF

R1# show fabric status 5
 slot  channel speed module   fabric   hotStandby  Standby  Standby
                     status   status      support  module   fabric
 5        0      20G     OK       OK   Y(not-hot)

R1# show fabric utilization 5
 slot    channel      speed    Ingress %     Egress %
 5          0           20G            0            0

R1# show fabric errors
Module errors:
 slot    channel     crc      hbeat       sync   DDR sync
 1          0          0          0          0          0
 1          1          0          0          0          0
 2          0          0          0          0          0
 2          1          0          0          0          0
 3          0          0          0          0          0
 3          1          0          0          0          0
 5          0          0          0          0          0

Fabric errors:
 slot    channel    sync     buffer    timeout
 1          0          0          0          0
 1          1          0          0          0
 2          0          0          0          0
 2          1          0          0          0
 3          0          0          0          0
 3          1          0          0          0
 5          0          0          0          0

August 14, 2009

Switching Algorithms/Paths

Filed under: Information, IOS — Tags: — Jaycee @ 4:17 am

A. Overview:

1. Switching – the process of moving packets from one interface to another whinin a router.

2. Routing – the process of choosing paths and forwarding packets to destinations outside of the physical router.

3. Switching Algorithm – a valuable way to increase or decrease a router’s performance.

4. RIB (Routing Information Base) –

1) is built by L3 routing protocols
2) is essentially the routing table
3) The decisions about how to move packets from one interface to another are based on the RIB.

5. Steps of the process of switching a packet:

1) Determine whether the packet’s destination is reachable

2) Determine the next hop to the destination, and to which interface the packet should be switched to

3) Rewrite the MAC header on the packet to reach its destination

6. Requirements of router switching:

a. Interfaces have access to input/output memory. When a packet comes into an interface, the router must decide to which interface the packet should be sent. Once the decision is made, the packet’s MAC header are rewritten, and the packet is sent on its way.

b. Packets must get from one interface to another.

c. How the router decides which interface to switch the packet to – is based on the switching path in use.

d. Routing table contains all the necessary information to determine the correct interface, but process switching must be used to retrieve data from the routing table.

B. Process Switching:

1. It’s the original method of determining which interface to forward a packet to.

2. The processor calls a process that accesses the RIB, and waiting for the next scheduled execution of that process to run.

3. Steps for Process Switching:

process switching

1) The interface processor detects a packet and moves the packet to the input/output memory.

2) Interface processor generates a receive interrupt.

a. CPU(Central processor) determines the packet type (IP), and copies it to the processor memory if necessary.

b. Then the processor places the packet on the appropriate process’s input queue and releases the interrupt.

c. The process for IP packets is titled ip_input.

3) When the scheduler next runs, it notices the presence of a packet in the input queue for the ip_input process, then schedules the process for execution.

4) When the ip_input process runs, it looks up the next hop and output interface information in the RIB. Then it consults the ARP cache to retrieve the L2 address for the next hop.

5) The process rewrites the packet’s MAC header with the appropriate addresses, then places the packet on the output queue of the appropriate interface.

6) The packet is moved from the output queue of the outbound interface to the transmit queue of the outbound interface.

=> then Outbound QoS

7) The output interface processor notices the packet in its queue, and transfers the packet to the network media.

4. Slowness happens at:

slowness on process switching

a. The processor waits for the next scheduled execution of the ip_input process.

b. ip_input process references the RIB when it runs

1) ip_input process is at the same priority level as other processes on the router, such as routing protocol and HTTP web server interface.

2) Packets sourced from or destined to the router itself are always process-switched, such as SNMP traps from the router and telnet packets destined for the router.

C. Interrupt Context Switching:

1. The processor interrupts the current process to switch the packet.

interrupt context switching

2. It’s faster than process switching since ip_input process is rarely called. Interrupt Context Switching usually bypasses the RIB, and works with parallel tables, which are built more efficiently.

3. Steps for Interrupt Context Switching:

1) The interface processor detects a packet and moves the packet into input/output memory.

2) The interface processor generates a receive interrupt. During this time, the CPU determines the packet type (IP) and begins to switch the packet.

3) The processor searches the route cache for: destination reach-ability,  output interface, next hop, MAC conversion. Then the processor uses this information to rewrite the packet’s MAC header.

4) The packet is copied to either the transmit or the output queue of the outbound interface. The receive interrupt is ended, and the originally running process continues.

5) The output interface processor notices the packet in its queue, and transfers the packet to the network media.

4. RIB is by passed entirely in this model. The necessary information is retrieved from “route cache“. Each switching path has its own means of determining, storing, and retrieving this information. There are 3 different methods:

a. Fast Switching:

fast-switching binary tree

1)  uses binary tree format for recording/retrieving information in the route cache.

2) The information of the next hop and MAC address changes is stored within each node.

3) It’s fast compared with searching the RIB since the tree is very deterministic.

4) Drawbacks:

4.1) The data for each address is stored within the  nodes, the size of the data is not static. Each node may be a different size, the table can be inefficient.

4.2) Route cache is updated only when packets are process-switched. The route cache is updated only when the 1st packet to a destination is switched. To keep the data in the route cache current, 1/20th of the entire route cache is aged out (discarded) every minute. This table must be rebuilt using process switching.

4.3) ARP table is not directly related to the contents of the route cache. Process switching must be used when ARP changes.

b. Optimum switching:

optimum-switching multiway tree

1) uses a multiway tree instead of a binary tree for recording/retrieving information in the route cache

2) This pattern continues for 4 levels – one for each octet.

3) The information of each route (prefix) or IP address is stored within the final node.

4) The size of the table can be variable since each node may or may not contain information.

5) Drawbacks:

5.1) Searching the tree is not as efficient as it might be if every node were of a known static size.

5.2) The relevant data is stored in the nodes and has no direct relationship to the RIB or ARP cache, entries are aged and rebuilt through process switching.

c. Cisco Express Forwarding (CEF):

CEF forwarding and adjacency tables

1) CEF is the default switching path on all modern routers.

2) The data is not stored within the nodes. Each node becomes a pointer to another table, which contains the data.

3) Each node is the is the same static size w/o data but the position of the node is a reference to adjacency table.

4) Adjacency table stores the pertinent data, such as MAC header substitution and next hop information for the nodes.

5) Advantages:

5.1) Both forwarding table and adjacency table are built w/o process switching

5.2) Forwarding table is built separately from the adjacency table, an error in one table doesn’t cause the other to become stale.

5.3) When the ARP cache changes, only the adjacency table changes, so aging or invalidation of the forwarding table is not required.

5.4) CEF supports load balancing over equal-cost paths.

D. Configuring and Managing Switching Algorithm (or Paths):

1. Process Switching:

R0# sh ip int vlan 301 | i switching
 IP fast switching is enabled
 IP fast switching on the same interface is disabled
 IP Flow switching is enabled
 IP CEF switching is enabled
 IP Selective flow switching turbo vector
 IP Flow CEF switching turbo vector
 IP multicast fast switching is enabled
 IP multicast distributed fast switching is disabled
 IP multicast multilayer switching is disabled

a. To disable all Interrupt Context Switching Paths, use command:

R0(config-if)# no ip route-cache
R0#sh ip int vlan 301 | i switching
 IP fast switching is disabled
 IP fast switching on the same interface is disabled
 IP Flow switching is disabled
 IP CEF switching is disabled
 IP Selective flow switching turbo vector
 IP Flow CEF switching turbo vector
 IP multicast fast switching is disabled
 IP multicast distributed fast switching is disabled
 IP multicast multilayer switching is disabled

b. When a router is process switching most of its IP packets, the top process will always be ip_input. You can verify this by the command:

R0# sh proc cpu sorted | e 0.00
CPU utilization for five seconds: 49%/26%; one minute: 45%; five minutes: 45%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
281   3118803922583781382          0 26.95% 24.53% 21.42%   0 IP Input
178     2276332   5264619        432  0.15%  0.08%  0.03%   0 SNMP ENGINE

2. Fast Switching:

To enable fast switching:

R0(config-if)# ip route-cache
R0#sh ip int vlan 301 | i swi
 IP fast switching is enabled
 IP fast switching on the same interface is enabled
 IP Flow switching is disabled
 IP CEF switching is disabled
 IP Selective flow switching turbo vector
 IP Flow CEF switching turbo vector
 IP multicast fast switching is enabled
 IP multicast distributed fast switching is disabled
 IP multicast multilayer switching is disabled

=> Turning on fast switching is NOT enabling CEF.

3. CEF:

a. CEF is enabled by default.

b. There are 2 places that it con be configured:

R0(config)# ip cef
R0(config-if)# ip route-cache cef

c. CEF will load-balance packets based on a per-destination by default. => A single destination will use the same link

d. CEF allows you to configure load balancing on a per-packet basis. => VoIP cannot tolerate per-packet load balancing because packets may arrive out of order. When using usch protocols, always ensure that load balancing is performed per-destination, or use a higher-level protocol such as Multilink-PPP.

R0(config-if)# ip load-sharing per-packet
R0(config-if)# ip load-sharing per-destination

e. To show CEF tables:

R0# sh ip cef
Prefix              Next Hop             Interface
0.0.0.0/0           192.168.4.14          Vlan301
0.0.0.0/32          receive
127.0.0.0/8         attached             EOBC0/0
127.0.0.0/32        receive
127.0.0.51/32       receive
127.255.255.255/32  receive
192.168.4.0/28       attached             Vlan301
192.168.4.0/32       receive
192.168.4.1/32       receive
192.168.4.12/32      192.168.4.12          Vlan301
192.168.4.13/32      192.168.4.13          Vlan301
192.168.4.14/32      192.168.4.14          Vlan301
192.168.4.15/32      receive
224.0.0.0/4         drop
224.0.0.0/24        receive
255.255.255.255/32  receive

June 26, 2009

JUNOS Commands for IOS Users

Filed under: IOS, Junos — Tags: , — Jaycee @ 11:15 pm

A. Basic CLI and Systems Management Commands:

IOS Command JUNOS Command
clock set set date
reload request system reboot
send request message
show clock show system uptime
show environment show chassis environment
show history show cli history
show ip traffic show system statistics
show logging show log
show log file name
show processes show system processes
show running config show configuration
show tech-support request support information
show users show system users
show version show version
show chassis hardware
terminal length set cli screen-length
terminal width set cli screen-width
trace traceroute

B. Switching Commands:

IOS Command JUNOS Command
none show ethernet-switching interfaces
show spanning-tree show spanning-tree bridge
show mac address-table show ethernet-switching table

C. Interface Commands:

IOS Command JUNOS Command
clear counters clear interface statistics
show interfaces show interfaces
show interfaces detail
show interfaces extensive
show ip interface brief show interfaces terse

D. Routing Protocol-Independent Commands:

IOS Command JUNOS Command
clear arp-cache clear arp
show arp show arp
show ip route show route
show ip route summary show route summary
show route-map show policy
show policy policy-name
show tcp show system connections

1. OSPF Commands:

IOS Command JUNOS Command
show ip ospf database show ospf database
show ip ospf interface show ospf interface
show ip ospf neighbor show ospf neighbor

2. BGP Commands:

IOS Command JUNOS Command
clear ip bgp clear bgp neighbor
clear ip bgp dampening clear bgp damping
show ip bgp show route protocol bgp
show ip bgp community show route community
show ip bgp dampened paths show route damping decayed
show ip bgp neighbors show bgp neighbor
show ip bgp neighbors address advertised-routes show route advertising-protocol bgp address
show ip bgp neighbors address received-routes show route receive-protocol bgp address
show ip bgp peer-group show bgp group
show ip bgp regexp show route aspath-regex
show ip bgp summary show bgp summary

May 17, 2009

Basic BGP Configuration – IOS

Filed under: BGP, IOS — Tags: , — Jaycee @ 4:19 pm

A. Basic BGP Commands:

router bgp 64512
 no synchronization
 bgp dampening
 network 10.10.2.0 mask 255.255.254.0
 neighbor 192.168.1.5 remote-as 64513
 neighbor 192.168.1.5 next-hop-self
 neighbor 192.168.1.5 default-originate
 no auto-summary

1. “network” command: BGP assumes the old classful addressing scheme when a mask isn’t provided explicitly.

2. “neighbor” command: Use it only to specify our peers. If BGP neighbors aren’t communicating, make sure they can actually reach each other. BGP neighbors will not peer if they can’t reach each other.

3. Local-AS numbers: AS numbers reserved for local use range from 64512 to 65535.

4. Synchronization: a BGP router is not allowed to advertise a route that is learned from another BGP peer until the router knows about the route via an IGP. Synchronization can be disabled safely under either of two conditions:

a. If your network doesn’t pass traffic from one AS to another (i.e. other networks don’t route their traffic through you)

b. If all your border routers are running BGP.

5. “no auto-summary” disables automatic summarization.

6. “default-originatecauses the BGP router to advertise a default route to other BGP routers, even if it doesn’t have a default route defined for itself.

7. “next-hope-self” tells thr router to rewrite the route’s next hop as itself.

8. “bgp dampening” command: Route dampening controls the effect that a flapping route has on the network. Route flapping occurs when a route changes state repeatedly. BGP handles route flapping with the bgp dampening command.

a. When this feature is activated, the router tolerates only a certain number of state changes for a route within a certain amount of time.

b. If the state-change threshold (tolerance) is reached, the route is placed in a hold-down (ignored) state for a period.

c. After the hold-down time passes, the route is again allowed into the routing table to see if it behaves.

Dampening doesn’t stop the route from receiving unstable routes. It prevents the routing from forwarding what it considers to be unstable routes.

B. iBGP Checklist:

There are 2 ways to get iBGP to work correctly.

1. Redistribute all external routes into all of your iBGP routers. (<= not a good idea)

Problem: Routing table might be large, and some of the routers may not be able to handle it.

2. Full Mesh:

a. Disable synchronization.

b. Make sure all iBGP routers are fully meshed.

c. Make sure all networks and subnets that connect iBGP routers are known. That is, a route exists between all of your routers and and your interior routing protocol is doing its job and distributing those routes. If the routers cannot talk to one another, they wont be able to peer.

C. Simple BGP Configuration:

a simple bgp network

office-r1:

interface Ethernet0
 ip address 192.168.1.1 255.255.255.0
interface Serial0
 ip address 172.16.1.2 255.255.255.0
interface Serial1
 ip address 192.168.3.1 255.255.255.0
!
router bgp 3000
 no synchronization
 network 192.168.3.0
 network 192.168.1.0
 neighbor 172.16.1.1 remote-as 100
 neighbor 192.168.3.2 remote-as 3000
 neighbor 192.168.3.2 next-hop-self
 neighbor 192.168.3.2 default-originate
!
ip route 0.0.0.0 0.0.0.0 172.16.1.1

office-r2:

interface Ethernet0
 ip address 192.168.2.1 255.255.255.0
interface Serial0
 ip address 192.168.3.2 255.255.255.0
!
router bgp 3000
 no synchronization
 network 192.168.2.0
 neighbor 192.168.3.1 remote-as 3000

ISP:

interface Ethernet0
 ip address 10.1.1.1 255.255.255.0
interface Serial1
 ip address 172.16.1.1 255.255.255.0
 clockrate 64000
!
router bgp 100
 network 172.16.0.0
 neighbor 10.1.1.2 remote-as 200
 neighbor 172.16.1.2 remote-as 3000

Verify:

office-r2#show ip route
Gateway of last resort is 192.168.3.1 to network 0.0.0.0

B    172.16.0.0/16 [200/0] via 192.168.3.1, 00:03:10
B    172.16.1.0/24 [200/0] via 192.168.3.1, 00:03:15
C    192.168.2.0/24 is directly connected, Ethernet0
C    192.168.3.0/24 is directly connected, Serial0
B*   0.0.0.0/0 [200/0] via 192.168.3.1, 00:03:16

1. The gateway of last resort is set because we have “default-originate” set on the office-r1 router (192.168.3.1).

2. The route for 172.16.0.0/16 is via 192.168.3.1 because we used the “next-hop-self” option. If we hadn’t put that command in, the route would have looked like this:

B    172.16.0.0/16 [200/0] via 172.16.1.1, 00:00:17

In this configuration, this route would work as well as the route to 192.168.3.2 because the default route tells our router how to get to that address. If we didn’t have the default route, we would have to add an extra network statement, defining 172.16.0.0, to office-r1‘s configuration.

office-r2#show ip bpg
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network      Next Hop       Metric  LocPrf  Weight  Path
*>i0.0.0.0      192.168.3.1               100       0  i
*>i172.16.0.0   192.168.3.1         0     100       0  100 i
*>i192.168.1.0  192.168.3.1         0     100       0  i
*> 192.168.2.0  0.0.0.0             0          32768   i
*>i192.168.3.0  192.168.3.1         0     100       0  i

3. “i” means the route was learned through an interior protocol and therefore doesn’t cross autonomous system boundaries.

4. 172.16.0.0 network is in another autonomous system (AS 100). For this route to reach office-r1, BGP must learn the route from some sort of interior protocol. Therefore, the path for this network is 100 i.

5. If there is a network 172.30.0.0 attached to the ISP router and has an AS number of 200. The route might look like this:

office-r2#show ip bgp

  Network       Next Hop       Metric  LocPrf  Weight  Path
...
*>i172.30.0.0   192.168.3.1         0     100       0  100 200 i
...

6. This path shows that to reach 172.30.0.0, you must cross AS 100, then enter AS 200, which learned the route through an interior protocol such as RIP. Therefore, you don’t need to cross any more AS boundaries.

D. Neighbor Authentication:

1. BGP authentication are using an MD5 message digest.

2. As the example above, we can enable password authentication between office-r1 and office-r2.

office-r1:

router bgp 3000
neighbor 192.168.3.2 remote-as 3000
neighbor 192.168.3.2 password letmein

office-r2:

router bgp 3000
neighbor 192.168.3.1 remote-as 3000
neighbor 192.168.3.1 password letmein

E. Peer Groups:

1. Peer groups eliminate redundant configuration lines by allowing you to define a group and then make each neighbor a part of that group.

2. For example, assume you have a route map that enforces some routing policy. Instead of applying that route map separately on each neighbor, you can add all the neighbors to a peer group and then apply the route map for the group as a whole.

ibgp network with peer-group configuration

R1:

router bgp 500
 neighbor policy1 peer-group
 neighbor policy1 remote-as 500
 neighbor policy1 next-hop-self
 neighbor policy1 route-map map1 in
!
neighbor 10.10.2.1 peer-group policy1
neighbor 10.10.3.1 peer-group policy1

F. Route Reflectors:

1. BGP does NOT advertise a route learned from one iBGP router to another.

2. A router is advertised via iBGP ONLY IF it’s learned from the iBGP router that first advertised it.

3. An iBGP router cannot advertise a route it learned from another iBGP router to a third iBGP router. (Because of this restriction, if you have multiple routers connected to different AS networks, all of the routers must be fully meshed.)

4. One solution is to use router reflectors.

5. Route reflectors ease the advertisement restriction by allowing a BGP router to reflect BGP routes it learns about to a third BGP router.

route-reflectors

6. As the graph above, let’s setup a route reflector on R1 that propagates iBGP routes between R2 and R3.

R1:

router bgp 500
 neighbor 10.10.2.1 remote-as 500
 neighbor 10.10.2.1 route-reflector-client
 neighbor 10.10.3.1 remote-as 500
 neighbor 10.10.3.1 route-reflector-client

7. With the above configuration, R1 can advertise R2’s iBGP routes to R3, and R3’s routes to R2.

G. BGP Confederacies:

1. Confederacies allow you to divide an AS into smaller, more manageable pieces.

2. Inside each little AS, all the iBGP oruters are fully meshed.

3. Outside, all the little ASes are fully meshed to each other.

BGP confederacies

4. In above example, problem with using route reflectors: we would need more than one reflector, and managing them could easily get out of control.

R1:

router bgp 10000
 bgp confederation identifier 500
 bgp confederation peers 10010 10020
 neighbor 10.10.2.1 remote-as 10010
 neighbor 10.10.3.1 remote-as 10020
 neighbor 10.11.1.1 remote-as 600

R2:

router bgp 10010
 bgp confederation identifier 500
 bgp confederation peers 10000 10020
 neighbor 10.10.1.1 remote-as 10000
 neighbor 10.10.3.1 remote-as 10020
 neighbor 10.12.1.1 remote-as 700

R3:

router bgp 10020
 bgp confederation identifier 500
 bgp confederation peers 10000 10010
 neighbor 10.10.1.1 remote-as 10000
 neighbor 10.10.2.1 remote-as 10010
 neighbor 10.13.1.1 remote-as 800

H. BGP TTL Security:

1. It’s possible for a rogue router to hijack a BGP peer connection and inject bogus routes.

2. To prevent this, you can use TTL checking between peers.

3. It’s extremely difficult or impossible to forge TTL counts, we can apply a rule that only accepts IP packets with a TTL count that is equal to our configured hop-count. (TTL can be considered a hop-count).

4. If the BGP peer was directly connected, we could set the hop-count (TTL) to 2, and our BGP process accepts only packets with that hop-count from that neighbor’s IP address.

neighbor 10.10.1.1 ttl-security hops 2

5. With this seting, if the hop-count is less than 253, the packet is dropped. (You get 253 by subtracting our hop-count of 2 from 255). The only TTL values that will be accepted are 254 and 253.

6. This command is NOT support for iBGP peers. It applies ONLY to eBGP peers.

May 11, 2009

Spanning Tree

Filed under: IOS — Tags: — Jaycee @ 12:46 am

A. Preventing Loops with Spanning Tree:

1. Spanning tree is designed to prevent loops among bridges. (A bridge is a device that connects multiple segments within a single collision domain: Hubs and switches are both bridges.)

a. Broadcast Storms: Switch is expending most of its processing power forwarding broadcasts through the loop. “show process cpu history” is useful command to troubleshoot a broadcast storm.

sh proc cpu his

b. MAC Address Table Instability: Another problem caused by a lopped environment is MAC address table being constantly updated. (A switch examines each packet that arrives on a port and assigns the packet’s source MAC address to that port in its MAC address table. )

2. Spanning-tree is on by default. It’s a protocol designed to discover network loops and break them before they can cause any damage. It should always be enabled on any network.

3. Having more than one link b/w switches is a good idea in terms of redundancy: the trick is to have only one link active at a time.


B. Designing Spanning Tree:

1. Spanning tree elects a root bridge (switch) in the network. All other bridges need to reach via the shortest path possible.

2. Spanning tree calculates the cost for each path from each bridge in the network to the root bridge.

3. Spanning tree breaks paths by putting ports into a blocking state.

4. Every bridge that supports spanning tree sends out frames called BPDU (bridge protocol data units) every 2 seconds. These frames contains the information to perform the following functions:

a. Elect a root bridge:

(1) Every bridge has a bridge ID which is a combination of the bridge priority and the bridge’s MAC address. Bridge ID = bridge priority + bridge MAC.
(2) When a switch boots, it assumes it’s the root bridge, and sets the root ID to the local bridge ID.
(3) Root ID = root priority + root MAC. The root priority is configured with a value of 32768 (0x8000) by default.

b. Determine the best path to the root bridge: the lowest path cost

c. Determine the root port on each bridge:

(1) on the switch that has the shortest path to the root bridge.
(2) The root bridge doesn’t have root ports, and it only has designated ports.

d. Determine the designated port on each segment

(1) on the segment that has the shortest path to the root bridge.
(2) On segments that are directly connected to the root bridge, the root bridge’s ports are the designated ports.

e. Elect a designated bridge on each segment

(1) The root bridge is the designated bridge for all directly connected segments.
(2) 2 bridges on a segment have root ports, the bridge with the lowest bridge ID becomes the designated bridge.

f. Block nonforwarding ports: still send and receive BPDUs.

5. Always configure a switch to be the root bridge. (Should NOT let networking devices make critical decisions using default values.) The root bridge should generally be one of the core switches in your design.

6. Spanning tree states:

Initializing -> Blocking -> Listeing -> Learning -> Forwarding

a. Blocking: the port receives and processes BPDUs.
b. Listening: BPDUs are sent as well as received.

7. By default, all VLANs will inherit the same values for all spanning tree configurations. Each VLAN can be configured differently. So each VLAN may have a different spanning tree root bridge.

C. PVST (Per-VLAN Spanning Tree) and PVST+ (Per-VLAN Spanning Tree Plus):

1. PVST allows for a spanning tree instance for each VLAN when used with ISL trunks.

2. PVST+ allows for a spanning tree instance for each VLAN when used with 802.1Q trunks.

D. Managing Spanning Tree:

1. Show spanning tree status:

sh spanning-tree

2. Show a summary of spanning tree:

sh spanning-tree sum
Picture 11

3. Shows the information regarding the root bridge for every VLAN:

sh spanning-tree root

E. Additional Features:

1. PortFast:

IOS(config-if)# spanning-tree portfast

a. It allows a port to bypass all of the other spanning tree states and proceed directluy to the forwarding state.
b. It takes about 30 seconds to put a normal port into the forwarding state, which can cause systems using DHCP to time out and not get an IP.

2. BPDU Guard:

IOS(config-if)# spanning-tree bpduguard enable

a. Ports configured for PortFast should never receive BPDUs. BPDU Guard automatically disables a port configured for PortFast in the even that it receives a BPDU and put it into the ErrDisable state.
b. The interface must be reset if this happens.

3. UplinkFast:

IOS(config)# spanning-tree uplinkfast

a. UplinkFast should be configured ONLY on access-layer switches.

b. Allows a blocked uplink port to bypass the listening and learning states when the designated port fails. This allows the network to recover in 5 seconds or less. (Normally takes up to 45 seconds.)

c. This feature affetcs all VLANs on the switch. It also sets the bridge priority to 49,152 to all but ensure that the switch will NOT become the root bridge.

4. BackboneFast:

IOS(config)# spanning-tree backbonefast

a. If the switch stops receiving BPDUs for the better root bridge, it’ll continue to believe that that bridge is the best bridge until the max_age timeout is exceeded. (max_age defaults to 20 seconds.)

b. BackboneFast detects indirect link failures. It actively discovers paths to the root by sending out root link query BPDUs after a link failure. When it discovers a path, it sets the max_age timer to 0.

F. Common Problems:

1. Duplex Mismatch:

a. If a port in the blocking state stops receiving BPDUs, the bridge no longer considers the port to be a path to the root bridge. In this case the port should no longer be blocked, so the bridge puts the port into the forwarding state.

b. When a port is in half-duplex mode, it listens for collisions before transmitting. After a collision, the port will perform the back-off algorithm, and wait to resend the packet that collided. When the data rate gets high, the collision problem gets worse, resulting in frames being dropped, including BPDUs.

c. Always make sure that both sides of an Ethernet link are configured the same way regarding speed and duplex.

2. Unidirectional Links:

a. A link is able to transmit in one direction but not another. It’s most often seen when using fiber. One fiber strand can end up on a different port or switch from the other strand in the pair.

b. In this case, rebooting will not resolve the issue. When shutting down the link, the proof of the unidirectional link is often lost.

c. This problem can be difficult to uncover and it’d cause outage  very quickly because the CPU utilizaoin on network devices can quickly reach 100 percent.

d. With the latest versions of IOS, unidirectional link problems are handled by a protocol called UDLD (Unidiretional Link Detection). UDLD is on by default and it should be left ON.

G. Prevent Spanning Tree Problems:

1. Always suspect that something physical is wrong when diagnosing connectivity problems.

2. Dont assume that it works today just because it worked yesterday. It doesn’t take much for someone to crush a fiber strand when closing a cabinet door.

3. ALWAYS CONFIGURE the ROOT BRIDGE!

May 10, 2009

EtherChannel

Filed under: Information, IOS — Tags: , — Jaycee @ 8:17 pm

A. EtherChannel :

1. A Cisco term for the technology that enables the bonding of up to 8 physical Ethernet links into a single logical link. However, the bandwidth is not truly the aggregate of the physical link speeds in all situations. (an EtherChannel composed of 4 1-Gbps links, each conversation will still be limited to 1 Gbps by default.

2. By default, the physical link used for each packet is determined by the packet’s destination MAC address. This algorithm is Cicso-proprietary. The packets with the same destination MAC address will always travel over the same physical link. => It ensures that packets sent to a single destination MAC address never arrive out of order.

3. If one workstation talks to one server over an EtherChannel, only one of the physical links will be used. All of the traffic destinated for that server will traverse a single physical link in the EtherChannel. => A single user will only ever get 1 Gbps from the EtherChannel at a time.

4. Solaris uses “Trunk” for this technology term.

B. Load Balancing:

1. Hashing algorithm takes the destination MAC address and hashes that value to a number in the range of 0-7.

2. The only possible way to distribute traffic equally across all links in an EtherChannel is to design one with 8, 4, or 2 physical links.

3. The method the switch uses to determine which path to assign can be changed:

a. MAC address:

(1) source MAC
(2) destination MAC (default)
(3) source and destination MAC

b. IP address:

(1) source IP
(2) destination IP
(3) source and destination IP

c. Ports:

(1) source port
(2) destination port
(3) source and destination ports

4.In the case of one server (i.e. email server) receiving the lion’s share of the traffic, destination MAC address load balancing doesn’t make sense. Give this scenario, balancing with the source MAC address makes more sense as the example below:

EtherChannel load-balancing factors

a. Load-balancing method is only applied to packets being transmitted over the EtherChannel. This is not a 2-way function.

b. When packets are being returned from the email server, the source MAC address is that of the email server itself.

c. Thus, the soluction would be to have source MAC address load balancing on Switch A, and destination load balancing on Switch B.

5. For a switch like 6509, changing the load-balancing algorithm is done on a chassis-wide basis, so with all the devices connected to a single switch as below:

Single server to single NAS

Problem: the bandwidth required between the server and the NAS device is in excess of 2 Gbps.

a. Solution 1: change the server and/or NAS device so that each link has its own MAC adddress => the packets ill still be source from and destined for only one of those addresses.

b. Solution 2: Spliting the link into 4 x 1-Gbps links, each with its own IP network and mounting different filesystems on each link will solve the problem.

c. Solution 3: get a faster physical link, wush as 10Gbps Ethernet.

C. EtherChannel Protocols:

EtherChannel protocols and their modes

1. LACP (Link Aggregation Control Protocol) is IEEE standard.

2. PAgP (Port Aggregation Control Protocol) is Cisco-proprietary.

3. NetApp NAS devices dont negotiate with the other sides of the links, so Cisco side of the EtherChannel should set to “on“.

D. EtherChannel Configuration:

1. Creat a port-channel virtual interface:

EtherChannel configuration

2. Shows the status of an EtherChannel:

sh etherchannel sum

3. Shows the number of bits used in the hash algorithm for each physical interface:

sh etherchannel 1 port-channel

Older Posts »

Create a free website or blog at WordPress.com.