OSPFEIGRP Supports CIDR and VLSM, rapid convergence, partial updates, neighbour discovery Supports CIDR and VLSM, rapid convergence, partial updates, neighbour discovery Administrator can define route summarization Automatic route-summarization and user defined route summaries Open standard; multivendor support Proprietary; Cisco routers only Scalable; administratively defined “areas” provide manageable hierarchy Scalable, but no hierarchical design Difficult to implementEasy to implement Equal-cost load balancing Unequal-cost load balancing
Default constant values:- K1=1, K2=0, K3=1, K4=0, K5=0 Metric = [K1 x bandwidth (min) + K3 x delay (cumulative)] The default K values can be changed with the EIGRP router command: R2(config-router)# metric weights tos k1 k2 k3 k4 k5 Metric = 256*([K 1 *Bw + K 2 *Bw/(256-Load) + K 3 *Delay]*[K 5 /(Reliability + K 4 )]).
S0/0/0S0/0/1 DCE R2 R1 S0/0/0 DCE S0/0/1 192.168.10.8/30 172.16.2.0/24 192.168.1.0/24 R3 172.16.1.0/24 Fa0/0 172.16.3.0/220.127.116.11.10.1 S0/0/1.5 192.168.10.4/30 S0/0/0 DCE.6 64 kbps1024 kbps 1544 kbps ISP Loopback 10.1.1.1/30 R2 Slowest Interface = S0/0/1 link at 1024kbps 10,000,000 / 1024 = 9765.625 9765 x 256 =2,499,840 Round Down = 9765 Bandwidth = (10,000,000 / BW in kbps) x 256
Equal-cost load balancing is the ability of a router to distribute traffic over all its network ports that are the same metric from the destination address. EIGRP automatically load balances across equal cost paths. Load balancing increases the use of network segments and increases effective network bandwidth. Cisco IOS software by default will install up to four equal-cost paths in the routing table for most routing protocols. The maximum-paths command in can be used to allow up to six equal-cost paths.
Routing LoopsUnequal cost paths How will R1 route packets to R2’s loopback interface? Issues if R1 uses both direct path and and indirect path using R3?
The spoke routers are remotes sites, and they have two connections for redundancy, not so they can transit traffic between Router A and Router B. Router A should never use the spokes as a path to anything reachable through Router B, so there’s no reason to learn about, or query for, routes through these spokes. BA 10.1.1.0/24 Not Designed to Transit Traffic Hub Network Spoke 1 Spoke 2 Spoke 3 Spoke 4 Router A Router B
The EIGRP Stub Routing feature: ◦ Improves network stability ◦ Reduces resource utilization and ◦ Simplifies remote router (spoke) configuration Stub routing is commonly used in hub-and-spoke topology. Stub router sends a special peer information packet to all neighboring routers to report its status as a stub router. Any neighbor that receives a packet informing it of the stub status does not query the stub router for any routes.
BA 10.1.1.0/24 Hub Network Spoke 1 Spoke 2 Spoke 3 Spoke 4 Router A Router B Spoke1(config)router eigrp 100 Spoke1(config-router)#eigrp stub To inform Routers A & B B that the paths through the spokes should not be used for transit traffic, the spoke routers can be configured as stubs: Query Reply
Can you identify problems with reudundancy in the network
Several solutions to problem in the last slide: Add a redundant Ethernet link between routers A and B to contain the backbone traffic to the hub site Use some level of route summarization to limit the extents of the EIGRP QUERY mechanism. Configure a distribute-list to limit the networks advertised by the spoke routers. Best Solution: is to control traffic flows and limit query depth using EIGRP Stub Router functionality
receive-only: Prevents the stub from sending any type of route. connected: Permits stub to send connected routes (may still need to redistribute). static: Permits stub to send static routes (must still redistribute). summary: Permits stub to send summary routes. Default is connected and summary. Eigrp stub configuration need only be entered on the spoke routers. Router(config-router)#eigrp stub [receive-only|connected|static|summary]
EIGRP automatically summarises routes at the classful boundary—the boundary where the network address ends as defined by class-based addressing. In most cases, auto summarisation is beneficial, because it keeps the routing tables as compact as possible. Auto summarisation causes problems when two subnets are discontiguous. C –18.104.22.168/8 Subnet 22.214.171.124/24 C – 126.96.36.199/8 Subnet 188.8.131.52/24 Update: C- 184.108.40.206/8
EIGRP automatically includes a null0 summary route as a child route whenever both of following conditions exist: 1.There is at least one subnet that was learned via EIGRP. 2.Automatic summarisation is enabled.
EIGRP uses the Null0 interface to discard any packets that match the parent route but do not match any of the child routes. Even with classless routing behavior configured, where the route lookup process will check for supernets and default routes, EIGRP will use the Null0 summary route and discard the packet because this route will match any packets of the parent that do not have a child route.
By default, EIGRP may use up to 50 % of the bandwidth of an interface or sub-interface for routing traffic. EIGRP uses the bandwidth specified with the bandwidth command, or the default bandwidth of the link if none is configured, when calculating how much bandwidth to use. EIGRP bandwidth usage can be adjusted as follows: R1(config)#interface s0/0/0 R1(config-if)#bandwidth 128 R1(config-if)#ip bandwidth-percentage eigrp 1 25 AS %
Simple password authentication: ◦ Router sends packet and key. ◦ Neighbor checks if received key matches its key. ◦ Not secure. MD5 authentication ◦ Configure a “key” (password) and key-id; router generates a message digest, or hash, of the key, key-id and message. ◦ Message digest is sent with packet; key is not sent. ◦ Secure.
R1(config)#interface Serial0/0/1 R1(config-if)#bandwidth 64 R1(config-if)# ip address 192.168.1.101 255.255.255.224 R1(config-if)# ip authentication mode eigrp 100 md5 R1(config-if)# ip authentication key-chain eigrp 100 R1chain R1(config)# key chain R1chain R1(config-keychain)#key 1 R1(config-keychain-key)#key-string firstkey R1(config-keychain-key)# accept-lifetime 04:00:00 Jan 1 2006 infinite R1(config-keychain-key)# send-lifetime 04:00:00 Jan 1 2006 04:30:00 Jan 1 2006 R1(config-keychain)# key 2 R1(config-keychain-key)#key-string secondkey R1(config-keychain-key)#accept-lifetime 04:00:00 Jan 1 2006 infinite R1(config-keychain-key)#send-lifetime 04:29:00 Jan 1 2006 infinite