Skip to content

Network Ninja

The Long Road to Cisco

  • Home
  • About
  • Legal Disclaimer
  • Archives

Less
More
Trim
Untrim
« Older
Home
Loading
Newer »

Archive for the 'Bandwidth' Category

Enhanced Interior Gateway Routing Protocol – Scalable EIGRP – ip bandwidth-percent

Published
by
Deon Botha
on September 5, 2008
in BSCI, BSCI Questions, Bandwidth, CIR, Certification and Cisco Systems
. 0 Comments

Working from the my last couple of EIGRP posts I am going to try and crystallize some of the material found by working through questions found in Stewart, B,D., Gough, C (2008). CCNP BSCI Official Exam Certification Guide, Fourth Edition. Indianapolis: Cisco Press.

Explain the meaning of the command ip bandwidth-percent eigrp 63 100?

The purpose of the command ip bandwidth-percent eigrp 63 100 is when one has many Virtual Circuits (VCs) and there is not enough bandwidth at the access speed to support the aggregate bandwidth. The subinterfaces must be configured with a much lower speed than the real speed of the circuit.

For example on multiple Frame Relay links, lets say 5 in all, all with 64 kbps guaranteed (CIR) you know you can “garauntee” this aggregate 128 kbps bandwidth but , but when the sun shines, the wind blows in the right direction and everyone exhales at once in the office you might get more or less than 2 Mbits meaning aggregate bandwidth of 10 Mbits.

In this case we use ip bandwidth-percent eigrp 63 100 to indicate to the EIGRP process that it can still function, by adjusting it from the default 50% bandwidth to use 100% of the bandwidth (so EIGRP can use 256 kbps) for Autonomous-System 63 on the interface which it is configured. This is done because chances are very high that we are in most cases going to receive somewhere between 384 kbps and 512 kbps rather than our CIR of 128 kbps.

One uses this command because the bandwidth command does not reflect the true speed of the link.

Resources:

Stewart, B,D., Gough, C (2008). CCNP BSCI Official Exam Certification Guide, Fourth Edition. Indianapolis: Cisco Press.

Notes and Notices:

This is a part of my personal BSCI notes and research to assist myself in learning and understanding the concepts and theory for the BSCI exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BSCI Certification.

Enhanced Interior Gateway Routing Protocol – Optional Configuration Commands for EIGRP – Tuning EIGRP

Published
by
Deon Botha
on September 2, 2008
in BSCI, BSCI Notes, Bandwidth, Certification, Cisco Systems and Hold Timer
. 0 Comments

Some South African/Anglo-African humour that is making me smile:

“Tune” to talk, especially to talk nonsense (“Are you tuning me?”)

But back to the topic at hand;

One can fine tune the EIGRP process in many ways. The most important of tuning methods would be the summarization of routes and load balancing. Other techniques however do exist and these include the frequency of the hello and hold timers and setting bandwidth.

The trade off to playing with timers would be that by decreasing hello traffic the network will take longer to  notice failures, which in turn will delays convergence.

To go over some stuff from previous posts; EIGRP only sends updates when a new route is advertised or an existing route is withdrawn (changes state to down). A Link failure causes an interface to change state without delay (duh). But when a failed neighbour is not directly connected (on the other side of a Ethernet switch for example), the only way to notice failure would be that no hellos are received. The idea and concept of Neighbourship is important in EIGRP because it alerts the router to topology changes and because the router is responsible to the rest of the network to publicize the lost routes.

When fiddling with timers think about the wider ramifications. In most cases defaults are there for a reason. Instead of improving performance the opposite will most probably happen. (I.E. timers are changed per interface and changing timers on one side of a link and not the other side creates problems with neighbourship that forms and dissolves periodically).

Timer Values are based on the speed of the interface. Because the timers are assumed to be based on this speed, they will usually be the same (Timers are not communicated between neighbours and are not a requirement for neighbourship).

If Router A has a hello interval of 5 seconds and a hold time of 15 seconds (3x hello) and Router B has a hello interval of 30 seconds and a hold time of 90 seconds (3x hello), then the two routers will be neighbours for 15 seconds and then down for 15 seconds.

The Hello Timer

Tuning the Hello Timer directly affect the ability of the EIGRP Process to notice a change in the state of a neighbour. Only after a router’s interface is recognized as being down, or a router has failed to hear from a neighbour after a certain amount of time, does the router declare the neighbour dead and take action to update the Routing Table and neighbours.

For the above stated reasons, use of the

Router(config-if)#ip hello-interval eigrp autonomous-system-number seconds

command is typically used to decrease (AND NOT INCREASE) the amount of time between Hellos to ensure that the network converges QUICKER and not SLOWER (which would be done by INCREASING THE TIME). This however means MORE traffic devoted to EIGRP and more space used by EIGRP.

The defaults are as follows:

  • High Bandwidth links (every 5 seconds)
    • Broadcast Media (Ethernet, Token Ring, FDDI)
    • Point-to-Point Serial Links (PPP or HDLC Leased Circuits, Frame Relay Point-to-Point subinterfaces, and ATM)
    • Point-to-point subinterfaces
    • High Bandwidth (T1/E1 and greater) multipoint circuits (ISDN PRI and Frame Relay)
  • Lower Bandwidth Links (every 60 seconds)
    • Multipoint Circuits (T1/E1 and slower, Frame Relay Multipoint interfaces, ATM multipoint interfaces, and ATM)
    • Switched Virtual Circuits and ISDN BRIs

The Command to set how often hellos are sent to neighbours is applied to an interface and does not affect the ENTIRE EIGRP process:

Router(config)#interface serial 0/0
Router(config-if)#ip hello-interval eigrp autonomous-system-number seconds

To use this in an example we can change the hello timer of a WAN link, that is running on EIGRP AS 1. Doing so will not affect other interfaces running EIGRP AS 1 only this particular WAN link.

Router(config)#interface serial 0/0
Router(config-if)#ip hello-interval eigrp 1 10

The Hold Timer

The Hold Time as talked about here and is how long a router will wait for a hello before pronouncing the neighbour unavailable/dead. By Default the hold time is 3 times the hello time. TAKE NOTE that by changing the hello interval does not automatically change the hold time.

The hold timer for an interface must be changed manually using the following command:

Router(config-if)#ip hold-time eigrp autonomous-system-number seconds

Using this in the same example as above for the Hello time:

Router(config)#interface serial 0/0
Router(config-if)#ip hold-time eigrp 1 30

Authentication

EIGRP support two kinds of Authentication, simple passwords and MD5 hashes.

  • Simple passwords are sent as plain-text and matched to the key on the receiver. Simple passwords are not secure, because any listener can see this traffic and read the key value.
  • Hash keys, sent as MD5 values, are secure because the listener cannot use the value in one transmission to compute the key.

Using MD5 authentication, the router generates a had value for every EIGRP transmission and checks the hash of every received EIGRP packet.

To specify MD5 Authentication:

Router(config)#interface serial 0/0
Router(config-if)#ip authentication mode eigrp autonomous system md5

Once the MD5 authentication is set now comes the key:

Router(config-if)#ip authentication key-chain eigrp autonomous system chain-name

Then the key-chain is configured and the key is specified:

Router(config-if)#key chain chain-name
Router(config-if)#key my-chain
Router(config-keychain-if)#key-string key

An example using the WAN interface from above:

Router(config)#interface serial 0/0
Hello Interval Set
Router(config-if)#ip hello-interval eigrp 1
10
Hold Interval Set
Router(config-if)#ip hold-time eigrp 1 30
MD5 Authentication Set
Router(config-if)#ip authentication mode eigrp 1 md5
MD5 Key Set
Router(config-if)#ip authentication key-chain eigrp 1 My-Chain
MD5 key-chain Set
Router(config-if)#key chain My-Chain
Router(config-if)#key 1
Router(config-keychain-if)#key-string cisco

Authentication results are not shown under show commands. A successful neighbourship means it works. You can however check command process using debug eigrp packets

Optional EIGRP Commands Over a WAN

EIGRP has some design and configuration issues when it comes to the WAN environment. In the WAN one must deal with limited capacity to a greater degree than at other points of the network (For example the LAN). EIGRP is limited in that it restricts its use of bandwidth to NO MORE than 1/2 the link capacity. This is superior to the considerations made by other protocols. Although EIGRP by default is usually sufficient, one might need to make small adjustments at times.

EIGRP Defaults in Bandwidth Utilization
Routers understand link capacity most of the time (MOST being important here). Serial interfaces are however problematic (and the exception to the rule) because they usually attach to a DSU. The router therefore assumes a default speed of 1544 kbps (which is in most cases on the WAN not true).

If the link is actually 56 kbps, then EIGRP would calculate incorrectly and -even limiting itself to 722 kbps -could saturate the link. This could result in dropped EIGRP and data packets because of congestion and dropped data.

The show interface command will allow you to check that the interface bandwidth is accurate. The output shows the configured bandwidth of the link.

Show Interface x

The set bandwidth does not actually affect the speed of the link, but this value is used for routing protocol calculations and load calculations. Using the following command you can set the bandwidth:

Router(config)#interface serial 0/0
Router(config-if)#bandwidth speed-of-line

Configuring Bandwidth over an Non-Broadcast Multi-access (NBMA) Cloud

EIGRP plays well over WANs, including point-to-point and NBMA environments like Frame Relay and ATM. The NBMA topology can include either point-to-point subinterfaces or multipoint interfaces.

Cisco IDs three rules when configuring EIGRP over an NBMA cloud:

  • EIGRP traffic should not exceed the committed information rate (CIR) capacity of the virtual circuit (VC).
  • EIGRP aggregated traffic over all the VCs should not exceed the access line speed of the interface.
  • The bandwidth allocated to EIGRP on each VC must be the in the same directions.

Configuring Bandwidth over a Multipoint Network

In addition to being used in the EIGRP metric, the bandwidth command influences how EIGRP uses NBMA VCs. If a serial line has many VCs in a multipoint configuration, EIGRP will assume that each VC has an even share of the bandwidth. EIGRP will confine itself to using half that share for itself. This won’t work if a 56 kbps link has bandwidth set to 128 kbps because EIGRP will assume 64 kbps is for it’s own use.

The bandwidth command should reflect the access-link speed into the Frame Relay cloud. Your company might have five PVCs from your routers serial interface, each carrying 56 kbps. The access link will need a capacity of 5 * 56 kbps (280 kbps).

Configuring Bandwidth over a Hybrid Multipoint Network

If the multipoint network has different speeds allocated to the VCs, a more complex solution is needed.

  • Take the lowest CIR and multiply it by the total number of circuits. Apply the product (total) as the bandwidth of the physical interface. The problem with this configuration is that EIGRP will underutilize higher bandwidth links.
  • If possible, it is muse easier to configure and manage an environment that has used subinterfaces, where a VC is logically treated as a separate interface. The bandwidth command can be configured on each subinterface, which will allow different speeds on each VC. In this solution, subinterfaces are configured for each VC and the CIR is configured as the bandwidth. This is the preferred solution.

Configuring a Pure Point-to-Point Network

If there are many VCs, there might not be enough bandwidth at the access speed of the interface to support the aggregate EIGRP traffic. The subinterfaces should be configured with a bandwidth that is much lower than the real speed of the circuit. In this case, it is necessary to use the bandwidth-percent command that indicates to EIGRP that it can still function.

The ip bandwidth-percent eigrp command adjusts the percentage of capacity that EIGRP may use FROM THE default 50%. You would use the command because the bandwidth command does not reflect the TRUE speed of the link (The bandwidth command might have been altered to manipulate the routing metric and path selection of a routing protocol).

Router(config)#interface serial 0/0
Router(config-if)#ip bandwidth-percent eigrp autonomous-system-number percent

Software Study Resources:

The Command Memorizer was originally developed by a CCIE Candidate (David Bombal) for his own use and is now available to anyone who wants to use it.Command Memorizer helped him pass the CCIE Lab on the first attempt, and although I am not a CCIE candidate “officially” I have fiddling with it and finding it useful to test my command line retention and overall progress towards CCIE readiness as I do my current CCNP.The proof will be in the pudding as the Command Memorizer boasts 1000s of commands and hundreds of scenarios to test command line knowledge and retention. It has a section for EIGRP and I also like knowing where I am on my long road to Cisco.

Like most study aids / study tools this tool / aid has a specific focus. The Command Memorizer only works when used in conjunction with theoretical backing because you need to know what a command does and how it relates to the technology area. IOW You need to make the connection before you can start drilling actual commands repetitively to get them to start flowing and become second nature.

For a disclosure statement on my relationship with Configure Terminal.

Cisco Press Resources:

Stewart, B,D., Gough, C (2008). CCNP BSCI Official Exam Certification Guide, Fourth Edition. Indianapolis: Cisco Press.

Internetworking Technology Handbook – Intro to the Wan

Notes and Notices:

This is a part of my personal BSCI notes and research to assist myself in learning and understanding the concepts and theory for the BSCI exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BSCI Certification.


Search

About

You are currently browsing the Network Ninja weblog archives for the Bandwidth category.

Latest

RSS
  • Digital Growth with your Job
  • Open Shortest Path First – OSPF Fundamentals – Scenario
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 13
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 12
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 11
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 10
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 9
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 8
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 7
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 6

Archives

  • June 2009
  • April 2009
  • March 2009
  • February 2009
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008

Categories

  • 802.11 (7)
  • 802.1Q (1)
  • 802.1X (1)
  • AAA (1)
  • Access Point (7)
  • ACL (4)
  • Addressing (3)
  • Asides (31)
  • auto-summary (3)
  • AutoQoS (1)
  • Bandwidth (2)
  • BCMSN (55)
  • BDR (2)
  • BGP (1)
  • BPDU Filtering (1)
  • BPDU Guard (2)
  • BPDU Root Guard (1)
  • BSCI (67)
  • BSCI Notes (18)
  • BSCI Questions (48)
  • Business (1)
  • Cabling and Equiptment (3)
  • CAM (1)
  • CCDA (1)
  • CDP (1)
  • CEF (1)
  • Certification (123)
  • CIDR (2)
  • CIR (2)
  • Cisco Systems (144)
  • Concepts and Constructs (76)
  • CoS (1)
  • Cost (3)
  • DAI (1)
  • DDNS (1)
  • Debug (2)
  • DHCP Snooping (1)
  • DHCP Spoofing (1)
  • DR (3)
  • DUAL (1)
  • Dynamic ARP Inspection (1)
  • ECNM (5)
  • EIGRP (5)
  • Enterprise Architecture (7)
  • EtherChannel (1)
  • GLBP (1)
  • Hello Timer (2)
  • Hold Timer (2)
  • Hot Standby Router Protocol (1)
  • HSRP (1)
  • IGRP (1)
  • IIN (2)
  • Inter-Vlan Routing (1)
  • Interconnection Technologies (2)
  • IP Source Guard (1)
  • IS-IS (1)
  • ISL (1)
  • LACP (1)
  • Link State Advertisements (2)
  • Load Balancing (2)
  • Loop Guard (1)
  • MAC Address Flooding (1)
  • MLS (1)
  • MSTP (1)
  • NBAR (1)
  • NBMA (1)
  • Off-Topic (12)
  • OSPF (18)
  • PAgP (1)
  • passive-interface (1)
  • PoE (1)
  • Port Security (1)
  • Priority (2)
  • Proxy ARP (1)
  • PVC (1)
  • QoS (2)
  • RIP (1)
  • RIPv2 (1)
  • Root Guard (1)
  • RSTP (1)
  • Show (6)
  • Software (1)
  • SONA (2)
  • SSH (2)
  • STP (5)
  • Stub Router (3)
  • summary-address (1)
  • Support (4)
  • Switch Spoofing (1)
  • TCAM (1)
  • Telnet (2)
  • Troubleshooting (1)
  • Trunk (6)
  • Unidirectional Link Detection (1)
  • VACL (3)
  • VC (1)
  • Vine (20)
  • VLAN (11)
  • VLAN Hopping (1)
  • VLSM (1)
  • VoIP (1)
  • VRRP (1)
  • VTP (4)
  • VTY (1)
  • Wireless (7)


Styled with Sawchuk

Powered by WordPressabc and K21.0-RC7

Entries Feed and Comments Feed

42 queries. 1.0870 seconds.