tag:blogger.com,1999:blog-62403793342407126272024-03-13T11:45:38.742+00:00Subnetting Made Easy And Other Cisco TidbitsChris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.comBlogger37125tag:blogger.com,1999:blog-6240379334240712627.post-15333947573432166682011-10-12T12:21:00.000+01:002011-10-12T12:23:19.276+01:00The 95th Percentile - How ISPs chargeHi all,<br />
<br />
I've finally got my head around how ISPs charge customers for their traffic. Generally speaking ISPs charge on a flow basis rather than volume. What does this mean? It means that an ISP will charge a customer based on the number of bits passing through their pipes at any particular moment in time (commonly Megabits per second) as opposed to the total volume of traffic the ISP moves for the customer. Why do ISPs prefer a flow? Simply because it protects them from bursty traffic and unpredictable performance. If you was to charge by volume then theoretically you could send little or no data over a period of say 29 days then on the last billing day of the month send all of your traffic in one go. How would ISPs cope?<br />
<br />
Interestingly some companies try to negotiate with ISPs a price based on volume. They come up with a suitably large figure, say 800 Megabytes per month and then try and command a lower price-per-megabit. If you do the calculations to convert this to Megabits per second we get (800 x 8 / 30 / 24 / 60 / 60) = 0.0025Mbps which in reality is not much at all.<br />
<br />
We've now established why ISPs use a flow-based calculation. Now we need to understand how ISPs charge.<br />
<br />
ISPs generally take traffic statistics every 5 minutes in both the inbound and outbound directions. This means over a billing month of 30 days there are (60/5 * 24 * 30) = 8640 lines of statistics per customer interface.<br />
<br />
What the ISP does is arrange the 8640 lines in order of size, that is, from highest Mbps to lowest Mbps. The ISP then removes the top 5% of the lines and bills the customer for the next line which is the 95th percentile. This is done for both inbound and outbound traffic and whichever is highest the ISP chooses as the charge point. Those that are savvy may realise that the customer is actually allowed to burst for a period of time without penalty. If we say the top 5% of statistics are not taken into account (8640 * 0.05 = 432), and each statistic is 5 minutes, then the customer has effectively 432 * 5 = 2160 minutes or 36 hours in which to burst until their hearts are content.<br />
<br />
For those customers with multiple connections (not in a bundle) then there are two chargeable models; cumulative and aggregate.<br />
<br />
Cumulative charging takes the above example and repeats it for each individual connection, a simple A + B approach. Let's say that the 95th percentile of circuit A is 500Mbps and for B it is 800Mbps and the price per Megabit is £1 then the customer will be charged (£1 x 500) + (£1 x 800) = £1300.<br />
<br />
Aggregate charging differs slightly. For each of the 8640 lines of statistics for each connection, those lines are added together to give one set of statistics for all connections. The 95th percentile operation is carried out on this set to give the charge point.<br />
<br />
Which model you choose is down to how bursty your traffic is, whether you are using back-up links etc. I would say that if there isn't much correlation between your connections (i.e. they're not a backup connection to another) and your traffic is predictable then a cumulative model would suit best. However, if your traffic is bursty in nature and you are using a backup connection with the same ISP then an aggregated model is better suited. If you had a backup connection that has been unused for the majority of the month and on the last week of the billing month the primary connection fails you could be bursting beyond your 36 hours grace period on the backup connection and then if using the cumulative model be charged for very high data rate when over the course of the billing period the link was mostly idle.<br />
<br />
Some customers tend to ask for an average calculation to be done. For those that burst under their free 36 hours per month then the 95th percentile works better for you as the burst period is removed from the calculation. If using the average calculation in this case the customer will be charged more. Where the average works in the customer's favour is with those that burst over their free 36 hours as the ISP can then charge at the higher price point, however, ISPs tend not to do this as they wish to protect themselves from the bursty nature of some customer's traffic and provide more predictable behaviour.<br />
<br />
I hope this helps you understand the 95th percentile and why it is used.Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com3tag:blogger.com,1999:blog-6240379334240712627.post-85682227519950991632011-05-03T16:59:00.004+01:002011-05-04T19:58:22.485+01:00CCIE - Warm Up Phase - MulticastSome general notes from the ATC - <br /><br />(*,G) = I know what group I want to join but I don't know who is sourcing that traffic<br /><br />Shared Tree uses shortest path to the RP and all traffic passes through the RP<br /><br />Source tree uses shortest path to the source and traffic may or may not pass through the RP<br /><br />Bi-directional PIM uses Shared Trees only<br /><br />Multicast Source Discovery Protocol (MSDP) is a logical peering between RPs in order to exchange Source Active (SA) information. RPF checks are used to prevent loops. Additionally, able to limit or filter SAs. Specifiy the MSDP peer using "ip msdp peer <ip_address>"<br /><br />Anycast RP - RPs use same IP address. The IGP determines which RP is "closest". If one RP fails, the other RP will be used once IGP reconverges. Used in conjunction with MSDP for exchanging information.<br /><br />Useful commands:<br /><br />show ip pim neighbor<br />show ip pim interface<br />show ip pim rp mapping<br />show ip mroute<br />debug ip mpacket (may need to use "no ip mroute-cache" to see thru-traffic)<br />debug ip pim<br /><br />Auto-RP, by default, will not work in a pure Sparse Mode domain as router will not join 224.0.1.39 and 224.0.1.40 as it doesn't know of an RP. However, without joining those groups it won't know what the RP is. There are three workarounds:<br /><br />a. Default RP assignment where you assign a static RP for 224.0.1.39 and 224.0.1.40 but this defeats the purpose of Auto-RP<br /><br />b. Configure sparse-dense-mode. This acts as dense mode for those groups with no RP (e.g. 224.0.1.39 and 224.0.1.40).<br /><br />c. Configure ip pim autorp listener which automatically goes in dense mode for 224.0.1.39 and 224.0.1.40.<br /><br />Sample Network<br />--------------<br /><br />R1--R2--R3--R4--R5--R6<br /><br />R3 is RP on Lo0 interface. All devices configured with "ip pim rp-address 150.1.3.3" including R3 itself.<br /><br />All interfaces connected to another router confogured for PIM Sparse Mode.<br /><br />On R1 configure "ip igmp join-group 224.101.101.101".<br /><br />R3 should now have a (*,224.101.101.101) as will all routers in the path between R1 and R3. <br /><br />On R6 try pinging 224.101.101.101 which effectively makes R6 a source for the 224.101.101.101 group. <br /><br />R3 should now have a (S,G) entry (assume R6 interface is 155.1.146.6) the entry will be (155,1,146,6, 224.101.101.101).<br /><br />You could use the "ip igmp static-group" command but this will not respond t pings, however, traffic is still processed the normal way and you ought to be able to see the (*,G) and (S,G) entries associated with the static group.<br /><br /><br /><br />8.1 - A 3560 requires "ip multicast-routing distributed" to be configured.<br /><br />To test a configuration make an interface join a group and try to ping that group from another router. that interface must also be configured for PIM. What happens here is the interface acts as a host which is listening to a multicast group and the router that is pinging that group address is acting as the multicast source. Example:<br /><br />int lo0<br /> ip pim dense-mode<br /> ip igmp join-group 224.10.10.10<br /><br />8.2 If the RPF check fails (i.e. the IGP prefers a path to a source via a different interface, maybe because PIM is not enabled on that interface) then you could always add a static route to the mroute table.<br /><br />ip mroute 155.1.146.0 255.255.255.0 155.1.0.4<br /><br />In this example on R5, the IGP preferred a route in EIGRP via the point-to-point serial link to R4. However, PIM was not enabled on that interface but instead on the frame Relay cloud between R4 and R5. Hence, multicast traffic was attempting to go over the Frame Relay cloud but was failing the RPF check (e.g. 155.1.146.6 is meant to be reachable via the point-to-point link and not the Frame Realy cloud).<br /><br />To change how often a router checks RPF use the "ip multicast rpf interval" command.<br /><br />To configure a router to perform triggered RPF checks after a topology change and specify a maximum delay use "ip multicast rpf backoff <min-delay> <max-delay>"<br /><br />8.3 - There is a nother RPF failure but that is because R5's Lo0 interface was being advertised as a /32 by OSPF and therefore was the longest match when compared to the /24 advertised by EIGRP. By changing the OSPF network type to point-to-point under the Lo0 interface of R5, the RPF check passed and traffic flowed. <br /><br />To specify a traffic limit when the Shortest Path Tree (SPT) is used (switched over to) use the "ip pim spt-threshold" command.<br /><br />8.4 - note that Dense Mode uses (*,G) tuples and Sparse Mode uses (S,G) tuples. to specify which groups an RP can be an RP for, create an access-list and apply that to the rp-address command:<br /><br />ip access-list standard ACL_ALLOWED_GROUPS<br /> permit 224.0.0.0 0.0.0.255<br />!<br />ip pim rp-address 150.1.5.5 ACL_ALLOWED_GROUPS<br /><br />8.5 - the PIM Assert message tells a shared segment which router should be forwarding on that segment for that particular group. The tiebreak on this is the administrative distance used to reach the source. So, for example, you had a device using EIGRP and one using OSPF, the one using EIGRP would win the assertion due to the lower AD (90 versus 110). To change this you would need to alter the AD of the routing protocol.<br /><br />8.6 - The Accept RP tells a router to only accept specific groups from trying to join an RP.<br /><br />For example, if R5 Lo0 is the RP (150.1.5.5) and you only wanted groups 224.10.10.10 and 224.110.110.110 to be able to reach that RP use the following:<br /><br />ip access-list standard ACL_ACCEPT_RP<br /> permit 224.10.10.10<br /> permit 224.110.110.110<br />!<br />ip pim accept-rp 150.1.5.5 ACL_ACCEPT_RP<br /><br />8.7 - The PIM DR Election process is pre-emptive, unlike OSPF DR election. The winner is the router with the highest priority (default of 1) and if they are tied then the router with the highest IP address will be the PIM DR.<br /><br />ip pim dr-priority <value><br /><br />The "show ip pim interface <interface_name> detail" command will tell you whether the interface is PIM DR.<br /><br />8.8. The PIM Accept Register is configured on a RP and tells the RP which sources can register with it. If a source tries to register with the RP that is not on the register you will see Register-Stop messages (assuming "debug ip pim" is configured).<br /><br />8.9 Multicast tunnelling is straightforward. Try using ip unnumbered on the tunnel as its IP address. Must ensure PIM is configured on tunnel interface and make the tunnel interface passive under the routing process. May also need a static mroute to ensure that the RPF checks do not fail.Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-81101128373755721052011-04-26T08:52:00.003+01:002011-05-04T19:53:11.010+01:00CCIE - Warm-Up Phase - BGPHi,<br /><br />I am pretty happy with BGP but still there are a few things that I need to get into my head.<br /><br />7.5 - Disable Connected Check - this allows eBGP peers to use an IP address to peer that is not directly connected to the neighbor (e.g. a loopback interface). The difference between this and ebgp-multihop is that the TTL is not adjusted for disable-connected-check and that eBGP sessions will not form over transit routers.<br /><br />7.8 - The bgp cluster-id is applied to the route reflector only.<br /><br />7.9 - The confederation AS is used in the "router bgp" command and the bgp-confederation identifier refers to the proper AS. You must also specify bgp confederation peers otherwise the adjacency won't come up. In addition, confederation peers are treated as eBGP neighbors and should use directly connected interfaces, otherwise need to use things like update-source and ebgp-multihop.<br /><br />7.11 - Instead of using next-hop-self you can create a route-map to "set ip next-hop" and apply that to the neighbor (e.g. neighbor 1.2.3.4 route-map ROUTE_MAP_NAME in/out"<br /><br />7.12 - iBGP synchronization - Do not advertise a BGP route unless it is also learned by the IGP running in the network. In essence this requires the edge router to redistribute the eBGP routes into the IGP in order for iBGP to advertise the routes. Be careful when redistributing routes into IGP. Use an AS PATH access-list:<br /><br />ip as-path access-list 1 permit ^_54<br />!<br />route-map MATCH_AS_PATH permit 10<br /> match as-path 1<br />!<br />router eigrp 100<br /> redistribute bgp 100 metric 100000 1000 255 1 1500 route-map MATCH_AS_PATHChris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-28342627017815131332011-04-20T16:58:00.002+01:002011-04-20T18:11:26.207+01:00CCIE - Warm-Up Phase - OSPFThis is in relation to INE Workbook 1 and their 48 week program to get up to speed with passing the CCIE exam.<br /><br />What have I learned?<br /><br />6.1 - A network statement of "network 0.0.0.0 0.0.0.0 area 0" gets changed to "network 0.0.0.0 255.255.255.255 area 0" which is basically a single network statement that covers all interfaces.<br /><br />6.2 - By default Frame Relay defaults to an OSPF network type of non-broadcast. This means that a DR/BDR is elected, however, hellos are sent as UNICASTS therefore you must configure static neighbor commands. This needs to be done only on one end of the link but it may be best practice to configure it at both ends for clarity. In addition, as a DR is elected it does not change the next-hop value when it sends out Type 2 LSAs hence spoke routers need a path to the next-hop value via the PVC to the hub (e.g. frame-relay map ip 155.1.0.4 105 -- this will send traffic to 155.1.0.4 via DLCI 105 which is the PVC to R5 which is the hub for this network).<br /><br />6.4 - Point-to-point uses multicast hellos and no need for DR/BDR election or neighbor statements.<br /><br />6.5 - Point-to-multipoint. As this is over Frame Relay and the initial Frame Relay maps did not include the "broadcast" keyword no adjacencies formed. Point-to-multipoint uses multicast hellos so you have to specify the "broadcast" keyword. There are also no DR/BDR elections so the hub (R5 in this case) changes the next-hop to itself (155.1.0.5). As each router (R1 to R4) has a Frame Relay map to R5 full-reachability is made. <br /><br />6.6 - Point-to-multipoint non-broadcast. The only difference here is that it sends hellos as unicast and requires a neighbor statement.<br /><br />6.7 - Changing the network type on Loopback interfaces to point-to-point advertises the network with its correct mask (in this example /24) rather than the default Loopback type which advertises them as a stub with a /32 even if they are not configured as /32.<br /><br />6.8 - The reference bandwidth is configured in Mbps. <br /><br />6.10 - OSPF Path selection with Bandwidth - Change the bandwidth on an interface that RECEIVES the LSA and that is downstream from the device you wish to be affected (e.g. this example requires R6 to route via R1 so change the bandwidth value on R1 Se0/0 to a greater value to affect the overall cost. Note that R1, R4, and R6 share an Ethernet segment)<br /><br />6.11 - Changing the cost per neighbor. To find out what cost OSPF would assign a bandwidth value change the bandwidth on an interface and use "show ip ospf interface <interface_name> | inc Cost" to find out that value. Assign that value to the neighbor using "neighbor <a.b.c.d> cost <cost_value>". Don't forget to change the bandwidth back to the correct value!<br /><br />6.12 - If a router connects two areas together and neither of those areas are Area 0 then the ABR will not act as an ordinary ABR and will not forward Inter-Area routes as all Inter_Area routes must be advertised via Area 0. Therefore you need to use a Virtual Link.<br /><br />6.13 - OSPF Path Selection with Non-Backbone Transit Areas. After the virtual link was formed and I adjusted some costs on R4, routes to SW2 were being routed via Area 1 (specifically, via R4) and not to R1 even though that link is effectively Area 0 as it is a virtual link. To allow the use of the virtual link you must use "no capability transit" command at BOTH ends of the virtual link.<br /><br />6.14 - OSPF virtual links will not come up if the cost used to reach the other end of the virtual link is 65535 which is the maximum cost associated with an interface. You must therefore change the OSPF cost at BOTH ENDS of the virtual link.Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-52368977941909629992011-04-09T07:56:00.003+01:002011-04-09T08:04:41.962+01:00RIP - Adjusting default timersIn my last post about RIP I mentioned quite a few different bits of RIP. Here I just want to focus on changing the timers and how to override the timers.<br /><br />You can adjust your timers using the <span style="font-weight:bold;">timers basic <span style="font-style:italic;">update invalid holddown flush</span></span> under the routing process:<br /><br />router rip<br />version 2<br />timers basic 30 90 120 120 <br /><br />This will set the update to 30 secs, invalid to 90 secs, holddown to 120 secs, and flush to 120 secs.<br /><br />What would happen if you need to change that behaviour on just one link? Well, we can configure the update timer under the interface:<br /><br />interface fa0/0<br /> ip rip advertise 30<br /><br />This then changes the advertise time to 30 seconds but note that this doesn't change the other timers, only the advertise time!Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-83039794696605751672011-03-21T14:17:00.005+00:002011-03-21T20:09:11.031+00:00PPP Authentication - Using AAAHere we'll try to authenticate a session between two routers. One side of the router will use RADIUS while the other will use TACACS+. The side using RADIUS will be configured using a AAA server group. The TACACS+ server will be globally configured. Both RADIUS and TACACS+ use "cisco" as the password.<br /><br /><strong>Router 1</strong><br /><br />1. Configure a new AAA model<br /><br />aaa new-model<br /><br />2. By default, the "aaa new-model" command will require local authentication on the console port. To override this, and save us from locking ourselves out, we must configure specific console authentication and the easiest way to do that is by using "none".<br /><br />aaa authentication login CONSOLE none<br />!<br />line vty 0 4<br /> login authentication CONSOLE<br /><br />3. Configure a RADIUS server group called MY_RADIUS_GROUP and ensure that the RADIUS server at 192.168.1.1 only applies to this group.<br /><br />aaa group server radius MY_RADIUS_GROUP<br /> server-private 192.168.1.1 key cisco<br /><br />4. Configure AAA to authenticate PPP sessions against the RADIUS server group and if that fails it should try the local database.<br /><br />aaa authentication ppp PPP_AUTH group MY_RADIUS_GROUP local<br /><br />5. Configure the phyiscal interface to use the AAA authentication session<br /><br />interface s0/0<br /> ppp authentication PPP_AUTH<br /><br /><strong>Router 2</strong><br /><br />1. Configure a new AAA model<br /><br />aaa new-model<br /><br />2. By default, the "aaa new-model" command will require local authentication on the console port. To override this, and save us from locking ourselves out, we must configure specific console authentication and the easiest way to do that is by using "none".<br /><br />aaa authentication login CONSOLE none<br />!<br />line vty 0 4<br /> login authentication CONSOLE<br /><br />3. Configure a TACACS+ server group globally at 192.168.1.2<br /><br />tacacs-server host 192.168.1.2 key cisco<br /><br />4. Configure AAA to authenticate PPP sessions against the TACACS+ server and if that fails it should try the local database.<br /><br />aaa authentication ppp default group tacacs local<br /><br />5. Configure the phyiscal interface to use the AAA authentication session<br /><br />interface s0/0<br /> ppp authentication PPP_AUTHChris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com1tag:blogger.com,1999:blog-6240379334240712627.post-25681481619862578572011-03-20T08:31:00.002+00:002011-03-20T08:34:29.919+00:00When to use access-lists or prefix-listsHere's a great a bit of info that I pulled from INE's own Brian McGahan that is is worth remembering. Thanks Brian!<br /><br />Some applications you can use both access-lists and prefix-lists. In general, anytime you are matching a route, like with a route-map for redistribution, a route-map for BGP, or a distribute-list, you should use a prefix-list. This is what they were designed for. An access-list should be used any time you’re trying to match traffic, or with other non-routing related applications.<br /><br />Source: http://ieoc.com/forums/t/15006.aspxChris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-48661828110171707812011-03-19T14:34:00.004+00:002011-03-21T20:09:23.128+00:00PPPoE Server and ClientI've done a load of Cisco 877 configurations in the past on ADSL lines and wondered how all of the virtual template stuff works so here's a lesson as to how to configure PPPoE Server and Client with the Server providing the Client with an IP address using DHCP.<br /><br />We will also get the Server to authenticate the Client using CHAP and the Server will rate-limit the Client to a maximum of 10 sessions per minute over a period of 5 minutes. <br /><br />Let's start with the Client as it is the least amount of work.<br /><br />Client Tasks<br /><br />1. Configure a Dialer interface <br /> a. It should receive the IP address from the Server<br /> b. Have PPP configured<br /> c. Be part of a Dialer Pool<br /> d. Set the CHAP hostname<br /> e. Set the CHAP password<br /><br />interface Dialer1<br /> ip address dhcp<br /> encapsulation ppp<br /> dialer pool 1<br /> ppp chap hostname Router1<br /> ppp chap password cisco <br /><br />2. Tie the Dialer to a physical interface<br /> a. Remove any IP address from the interface<br /> b. Enable PPPoE<br /> c. Configure PPPoE to match the Dialer Pool<br /><br />interface FastEthernet0/1<br /> no ip address<br /> pppoe enable<br /> pppoe-client dial-pool-number 1<br /><br />Server Tasks<br /><br />1. Configure a Virtual Template interface<br /> a. Apply an IP address<br /> b. Apply PPP encapsulation<br /> c. Enable CHAP authentication<br /><br />interface Virtual-Template1<br /> ip address 192.168.1.1 255.255.255.0<br /> encapsulation ppp<br /> ppp authentication chap<br /><br />2. Create a Broadband Aggregation Group<br /> a. Give the group a name<br /> b. Tie the Virtual-Template to the group<br /> c. Throttle the client to 10 sessions per minute over a period of 5 minutes.<br /><br />bba-group pppoe MY_BBA_GROUP<br /> virtual-template 1<br /> sessions per-mac throttle 10 60 300 <br /><br />3. Configure the physical interface connected to the client<br /> a. Tie the physical interface to the BBA group<br /><br />interface FastEthernet0/1<br /> pppoe enable group MY_BBA_GROUP<br /><br />4. Create a DHCP pool for the client<br /> a. Exclude the IP address assigned to the Virtual Template interface<br /><br />ip dhcp excluded-address 192.168.1.1<br />ip dhcp pool MY_PPPoE_POOL<br /> network 192.168.1.0<br /><br />5. Create a username/password pair for Router1 for authentication<br /><br />username Router1 password cisco<br /><br />That's it. It takes a little while for it to kick in but worth trying to lab.<br /><br />Cheers,<br /><br />ChrisChris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com1tag:blogger.com,1999:blog-6240379334240712627.post-26374912843288373222011-03-18T13:16:00.006+00:002011-03-21T20:15:12.669+00:00PPP Authentication - PAP and CHAPI don't really use serial interfaces in my day-to-day job so when it comes to lab questions regarding PPP, HDLC, and Frame Relay I am immediately horrified.<br /><br />Here's the question given:<br /><br />1. Enable PPP encapsulation for the Serial link connecting R4 and R5 and use the IP subnet 155.1.45.0/24 for this link.<br /><br />2. R4 should attempt to authenticate R5 using PAP and then CHAP. R5 should refuse PAP authentication and use CHAP.<br /><br />3. Make sure R4 uses an alternate CHAP hostname R4CHAP.<br /><br />4. Use the name R5CHAP and the password of CISCO to accomplish this.<br /><br />5. R5 should authenticate R4 using PAP only. R4 should use the name R4PPP and the password of CISCO.<br /><br />Let's say that s0/0 is the interface at either end and R4 is the DCE.<br /><br />Step 1:<br /><br />Apply PPP, clock rate on R4, and IP address.<br /><br />R4:<br /><br />interface s0/0<br /><strong> encapsulation ppp<br /> clock rate 64000<br /> ip address 155.1.45.4 255.255.255.0</strong><br /><br />R5:<br /><br />interface s0/0<br /><strong> encapsulation ppp<br /> ip address 155.1.45.5 255.255.255.0</strong><br /><br />Step 2:<br /><br />R4 needs to authenticate R5 using PAP, and if it is refused, should use CHAP. R5 will be configured to refuse PAP authentication from R4.<br /><br />R4:<br /><br />interface s0/0<br /> encapsulation ppp<br /> clock rate 64000<br /> ip address 155.1.45.4 255.255.255.0<br /><strong> ppp authentication pap chap</strong><br /><br />R5:<br /><br />interface s0/0<br /> encapsulation ppp<br /> ip address 155.1.45.5 255.255.255.0<br /> <strong>ppp pap refuse</strong><br /><br />Step 3:<br /><br />R4 needs to specify a CHAP hostname of R4CHAP. If this wasn't specified then the CHAP hostname would be set as the hostname of the router (in this case, R4).<br /><br />R4:<br /><br />interface s0/0<br /> encapsulation ppp<br /> clock rate 64000<br /> ip address 155.1.45.4 255.255.255.0<br /> ppp authentication pap chap<br /> <strong>ppp chap hostname R4CHAP</strong><br /><br />R5:<br /><br />interface s0/0<br /> encapsulation ppp<br /> ip address 155.1.45.5 255.255.255.0<br /> ppp pap refuse<br /><br />Step 4: <br /><br />R5 should respond with a CHAP hostname of R5CHAP and a CHAP password of CISCO. Therefore on R4 we must configure a username/password pair for R5's details. What isn't obvious is that R5 needs a username/password pair for R4's details. In this case the R4 CHAP hostname is R4CHAP and the password must match R5's CHAP password which is CISCO.<br /><br />R4:<br /><br /><strong>username R5CHAP password CISCO</strong><br />!<br />interface s0/0<br /> encapsulation ppp<br /> clock rate 64000<br /> ip address 155.1.45.4 255.255.255.0<br /> ppp authentication pap chap<br /> ppp chap hostname R4CHAP<br /><br />R5:<br /><br /><strong>username R4CHAP password CISCO</strong><br />!<br />interface s0/0<br /> encapsulation ppp<br /> ip address 155.1.45.5 255.255.255.0<br /> ppp pap refuse<br /><strong> ppp chap hostname R5CHAP</strong><br /><br />Step 5:<br /><br />R5 wants to authenticate R4 using PAP and R4 responds with a PAP username of R4PPP and a PAP password of CISCO.<br /><br />R4:<br /><br />username R5CHAP password CISCO<br />!<br />interface s0/0<br /> encapsulation ppp<br /> clock rate 64000<br /> ip address 155.1.45.4 255.255.255.0<br /> ppp authentication pap chap<br /> ppp chap hostname R4CHAP<br /><strong> ppp pap sent-username R4PPP password CISCO</strong><br /><br />R5:<br /><br />username R4CHAP password CISCO<br />!<br />interface s0/0<br /> encapsulation ppp<br /> ip address 155.1.45.5 255.255.255.0<br /> ppp pap refuse<br /> ppp chap hostname R5CHAP<br /><strong> ppp authentication pap</strong><br /><br />That's it. Not too bad but worth working through to see how it all fits together.Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-79478522981264555742011-03-16T11:06:00.002+00:002011-03-16T11:14:22.114+00:00Multicast RPFRight then, I'm happy with RPF as a principle and that the router checks the interface on which it receives multicast traffic and consults its routing table to see if that interface would be used to reach the multicast source. <br /><br />What I didn't know (or at least I hadn't remembered) until now is that when there are equal-cost paths to the multicast source (e.g. OSPF, EIGRP etc) the router must pick one of them for Multicast RPF. Which one does it pick? It picks the one with highest neighbouring router ID.<br /><br />For example, let's say that the multicast RP is located on 192.168.1.0/24 network. You downstream router receives two equal-cost routes for that subnet, one from R1 with a router-id of 1.1.1.1 and the other from R2 with a router-id of 2.2.2.2. The router will pick the interface connected to R2 as it has the highest router-id.<br /><br />You can frig this by using tunnelling but that is a whole new ball game and one I'm not going into right now.Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-57494564623955472172011-02-22T18:37:00.007+00:002011-02-22T20:21:32.593+00:00CCIE Study - Written v4 Chapters 1 to 3 - 22/02/10Well I've learned lots actually, or more accurately put, I remembered lots of stuff that I had forgotten. Stupid stuff that I should have known right off the bat but slipped the mind.<br /><br /><span style="font-weight:bold;">Etherchannel</span><br />Cisco recommends for PAgP that both ends of the link be configured as Desirable.<br /><br /><span style="font-weight:bold;">Ethernet Basics</span><br />802.3ab defines GigabitEthernet over UTP whereas 802.3z defines GigabitEthernet over Fibre. 802.3u defines FastEthernet.<br /><br />MAC addresses are in canonical format which means that the most significant bit is on the right. Take the first two hexidecimal values from a MAC address and convert them to binary to give you an 8-bit string. The Individual/Group bit (I/G) is the right-most bit (i.e. the most signficant bit). If that is set to 0 then the MAC address is a unicast. If it is set to 1 then the MAC address is a broadcast or multicast. The second right-most bit is the Universal/Local bit (U/L). If this is set to 0 then the MAC address has been assigned by the vendor. If it is set to 1 then the MAC address has been administratively assigned.<br /><br /><span style="font-weight:bold;">Q-in-Q</span><br />VPLS and EoMPLS offer alternatives to Q-in-Q.<br /><br /><span style="font-weight:bold;">Spanning Tree</span><br />If a switch does not have any trunks configured at boot time but has the "spanning-tree root primary" command issued the priority of the switch will go to 24576 which is 8192 less than the default priority of 32768. If a trunk link is then formed and a switch has a higher priority then it will become the root and not the one with the root primary macro.<br /><br />If you want to configure BPDUGuard at interface level you must take off any interface-level PortFast configuration first.<br /><br />If running 802.1D and the root port does not receive any BPDUs the switch will wait for the Max Age timer to expire (default 20 seconds) before using another port.<br /><br />Port priority and port number when used as a tiebreaker are those on the advertising switch and not on the switch that receives the BPDU.<br /><br />If a root port fails then switchover to an alternative port is almost immediate.<br /><br /><span style="font-weight:bold;">SPAN/RSPAN</span><br />Destination ports do not forward Layer 2 protocols such as CDP, DTP, VTP, and STP.<br /><br />Up to 64 destination ports may be configured.<br /><br />The monitor session number can range between 1 and 66.<br /><br /><span style="font-weight:bold;">VLANs</span><br />The only VLANs that can be pruned are VLANs 2-1001. VLANs 1, and 1002-1005 are not prune eligible and can never be deleted.Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-285264507694228152011-02-19T14:27:00.003+00:002011-02-20T20:25:24.295+00:00Frame Relay - BECN/FECNBECN - Backward Explicit Congestion Notification is a bit in the Frame Relay header that is set by the destination and sent BACK to the originator indicating congestion in the path and to slow down transmission of data.<br /><br />FECN - Forward Explicit Congestion Notification is a bit in the Frame Relay header that is set by the sender and is FORWARDED to the destination to indicate congestion in the path and to slow down requests for data.<br /><br />Note that these are set by a Frame Relay switch in general so are received by a router rather than sent by a router.Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-8825603615116485032011-02-17T20:48:00.004+00:002013-03-25T20:02:40.801+00:00How to calculate multicast MAC addressHi,<br />
<br />
It's been a while but here's a quick post on how to calculate a multicast MAC address from an IP address. <br />
<br />
The first half of a multicast MAC address is 01-00-5E so we need to work out the second half.<br />
<br />
To do this we need to convert the last 23 bits of the IP address in question. If you think about this we are not using the high order bit in the second octet which carries a value of 128. Therefore it must follow that a value of 6 in the second octet must be the same as 134 in the second octet as the high-order bit (i.e. a value of 128) is ignored.<br />
<br />
So this leads to a simple method. Let us try and convert 192.168.35.1 to a multicast MAC address<br />
<br />
1. Start with a half-filled multicast MAC address of 01-00-5E-XX-YY-ZZ<br />
<br />
2. To calculate the value of XX take the second octet. If the value of the second octet is greater than 128 then subtract 128 from the second octet. In this example, the value of 168 is greater than 128 so we subtract 128 from 168 to give us a value of 40. Convert this value to hexadecimal. Decimal 40 = 0x28. Our multicast MAC address is now 01-00-5E-28-YY-ZZ<br />
<br />
3. To calculate the value of YY take the third octet and convert it to hex. In this example the value is 35 which equals 0x23. Our multicast MAC address is now 01-00-5E-28-23-ZZ<br />
<br />
4. To calculate the value of ZZ take the fourth octet and convert it to hex. In this example the value is 1 which equals 0x01. Our multicast MAC address is now 01-00-5E-28-23-01<br />
<br />
So 192.168.35.1 has a multicast MAC address of 01-00-5E-28-23-01.<br />
<br />
Can you spot an issue here? Hopefully you can. Basically any IP address with 40.35.1 or 168.35.1 as the last three octets carry the same multicast MAC address so you have potentially 32 addresses with the same multicast MAC address!<br />
<br />
Back to the books for me!<br />
<br />
Good luck with your studies.Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com2tag:blogger.com,1999:blog-6240379334240712627.post-20275025256261617522010-11-21T13:11:00.004+00:002010-11-21T13:23:23.036+00:00CCNP Training in the UK with Networks IncGuys,<div><br /></div><div>As I obviously have oodles of time on my hands I have become a Senior Instructor at Networks Inc here in the UK. We offer weekend CCNP courses from the new v6 track with the emphasis very much on hands-on practice. There is no equipment sharing - you will have your own kit to work on exclusively!</div><div><br /></div><div>And do you know what really rocks? You'll get to meet me of course! :-B</div><div><br /></div><div>For further details please see <a href="http://www.networksinc.co.uk/CCNP_boot_camp.htm">http://www.networksinc.co.uk/CCNP_boot_camp.htm</a></div><div><br /></div><div>I look forward to meeting some of you!</div><div><br /></div><div>Chris</div>Chris Bloomfieldhttp://www.blogger.com/profile/05456433782746614889noreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-81201663329212993742010-06-12T09:34:00.004+01:002010-06-12T10:26:21.655+01:00QoS - Bandwidth, Bandwidth Percent, Bandwidth Remaining PercentOK, I need to get this firmly lodged in my brain. What exactly are the differences in all of the bandwidth statements when using Modular QoS CLI (MQC)?<div><br /></div><div>Let's start with two values:</div><div><br /></div><div>The actual total bandwidth of the interface which we'll call <b>int-bw.</b></div><div><b><br /></b></div><div>The maximum bandwidth that can be reserved on an interface (default 75%) which we'll call<b> max-resv-bw. </b></div><div><b><br /></b></div><div>There are 3 bandwidth statements that can be used in MQC but note that you must only use <b>one</b> type of bandwidth statement per policy map (e.g. you cannot use bandwidth and bandwidth percent in the same policy map).</div><div><br /></div><div>The first statement is simply <b>bandwidth</b> <i>[<b>kbps]</b> </i>which reserves the value specified from the actual total bandwidth, <b>int-bw. </b>Remember that the total value of all of the <b>bandwidth</b> statements cannot exceed the maximum bandwidth that can be reserved <b>max-resv-bw. </b></div><div><br /></div><div><b></b>The second statement is <b>bandwidth percent <i>[percent] <span class="Apple-style-span" style="font-style: normal;"><span class="Apple-style-span" style="font-weight: normal;">which reserves the specified percentage of the actual total bandwidth,</span></span></i> int-bw. </b>Remember that the total value of all of the <b>bandwidth percent</b> statements cannot exceed the maximum bandwidth that can be reserved <b>max-resv-bw. </b></div><div><b><br /></b></div><div>The third statement is <b>bandwidth remaining percent <i>[percent] </i><span class="Apple-style-span" style="font-weight: normal;">which reserves the specified percentage of the remaining maximum reservable bandwidth. </span></b>Remember that the total value of all of the <b>bandwidth remaining percent</b> statements cannot exceed the maximum bandwidth that can be reserved <b>max-resv-bw. </b></div><div><b><br /></b></div><div>This is probably all better served with an example. Let's say that we have a policy-map with two classes in there, <i>class1 </i>and <i>class2, </i>applied to an interface whose bandwidth is 256kbps. We have the following two values:</div><div><br /></div><div><b>int-bw </b>= 256kbps</div><div><b>max-resv-bw</b> = 256kbps * 0.75 = 192kbps </div><div><br /></div><div>Note 0.75 in the max-resv-bw calculation as by default max-resv-bw is 75% of int-bw.</div><div><br /></div><div>Let's see how the <b>bandwidth </b>statement affects the policy map:</div><div><br /></div><div>class class1</div><div> bandwidth 64</div><div>class class2</div><div> bandwidth 32</div><div><br /></div><div>Quite simply, class1 will be reserved a minimum of 64kbps and class2 will be reserved a minimum of 32kbps. However, if the total of all of the <b>bandwidth</b> statements exceeded the <b>max-resv-bw </b>of the interface (192kbps in this case) Cisco IOS would not allow the policy-map to be applied to the interface. In the example above the total of all of the <b>bandwidth</b> statements is 96kbps which is less than the <b>max-resv-bw </b>of 192kbps.</div><div><br /></div><div><div>Let's see how the <b>bandwidth percent </b>statement affects the policy map:</div><div><br /></div><div>class class1</div><div> bandwidth percent 20</div><div>class class2</div><div> bandwidth percent 10</div><div><br /></div><div>In this case, class1 will be reserved a minimum of 20% of <b>int-bw</b> which is 52kbps in this example and class2 will be reserved a minimum of 10% of <b>int-bw </b>which is 25.6kbps. However, if the total of all of the <b>bandwidth percent</b> statements exceeded the <b>max-resv-bw </b>of the interface (192kbps in this case) Cisco IOS would not allow the policy-map to be applied to the interface. In the example above the total of all of the <b>bandwidth</b> statements is 77.6kbps which is less than the <b>max-resv-bw </b>of 192kbps.</div></div><div><br /></div><div><div>Let's see how the <b>bandwidth remaining percent </b>statement affects the policy map:</div><div><br /></div><div>class class1</div><div> bandwidth remaining percent 20</div><div>class class2</div><div> bandwidth remaining percent 10</div><div><br /></div><div>In this case, class1 will be reserved a minimum of 20% of <b>max-resv-bw</b> which is 38.4kbps in this example and class2 will be reserved a minimum of 10% of <b>max-resv-bw </b>which is 19.2kbps. However, if the total of all of the <b>bandwidth remaining percent</b> statements exceeded the <b>max-resv-bw </b>of the interface (192kbps in this case) Cisco IOS would not allow the policy-map to be applied to the interface. In the example above the total of all of the <b>bandwidth</b> statements is 57.6kbps which is less than the <b>max-resv-bw </b>of 192kbps.</div></div><div><br /></div><div>In essence the following formulas hold true:</div><div><br /></div><div><b>Bandwidth </b>- Reserves value specified. Total of all statements in same policy map cannot exceed <b>max-resv-bw.</b></div><div><b><br /></b></div><div><b>Bandwidth Percent - </b>Reserves specified percentage of <b>int-bw. </b>Total of all statements in same policy-map cannot exceed <b>max-resv-bw.</b></div><div><b><br /></b></div><div><b>Bandwidth Remaining Percent - </b>Reserves specified percentage of <b>max-resv-bw. </b>Total of all statements in same policy-map cannot exceed<b> max-resv-bw.</b></div><div><b><br /></b></div><div>Finally, you can change the value of<b> max-resv-bw <span class="Apple-style-span" style="font-weight: normal;">at </span></b>the interface level. However, Cisco does not recommend that you do this as to allow for control traffic. To do this use the <b><i>max-reserved-bandwidth [percent] </i><span class="Apple-style-span" style="font-weight: normal;">command. For example, if I wanted to be able to reserve 85% of Serial 0/0 bandwidth I would do the following:</span></b></div><div><b><span class="Apple-style-span" style="font-weight: normal;"><br /></span></b></div><div><b><span class="Apple-style-span" style="font-weight: normal;">interface Serial0/0</span></b></div><div><b><span class="Apple-style-span" style="font-weight: normal;"> max-reserved-bandwidth 85</span></b></div><div><b><span class="Apple-style-span" style="font-weight: normal;"><br /></span></b></div><div><b><span class="Apple-style-span" style="font-weight: normal;">I hope this has helped you as much as it has helped me bt typing it out.</span></b></div><div><b><span class="Apple-style-span" style="font-weight: normal;"><br /></span></b></div><div><b><span class="Apple-style-span" style="font-weight: normal;">Good luck with your studies!</span></b></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-38121190998184242492010-04-27T10:23:00.003+01:002010-05-18T20:16:08.247+01:00MPLS Command Memorizer ReviewSome time ago I purchased the CCIE Command Memorizer from <a href="http://www.configureterminal.com">http://www.configureterminal.com</a> which bundled in the MPLS Command Memorizer. For those of you that give a damn, I am currently taking my CCIP due to the CCIE v4 blueprint change which focuses more on MPLS. I'm halfway there with MPLS slated for 18th May leaving QoS which I aim to complete by the Summer.<br /><br />UPDATE: Passed with 987 in no small part to the MPLS Command Memorizer :-)<br /><br />I've played a lot with the MPLS Command Memoriser and have found it to be a wonderful tool to exercise fingers and mind and a couple of typos in the correct answers actually showed me that I knew more about the commands than I thought. Perhaps this has deliberately been put in by David ;-)<br /><br />It covers a wide range of topics including basic setting up of an MPLS network through to the various IGPs that can be used between CE and PE. There were also some useful exercises on those commands that may slip out of your mind such as "no ip mpls propagate-ttl forwarded" and conditional label advertisement. You have to type the commands in full as well so for me that is a great way of remembering the commands.<br /><br />My only recommendation for this product would be to include an AToM link and most definitely for me a section on MPLS Traffic Engineering - that would be real boon.<br /><br />Overall though I cannot recommend the Command Memorisers highly enough and would like to thank David Bombal for a terrific application which is not only a great standalone product but perfectly complements all other training materials such as books and labbing. I would also like to thank David for his support while I have been going through PCs like no tomorrow :-)Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-8925118247565692792009-08-18T15:33:00.002+01:002009-08-18T15:35:53.152+01:00Frame Relay - CIR, Bc, TcVery quick post. For whatever reason this formula does not stick in my head although it should be fairly straightforward to second guess.<br /><br />CIR = Bc/Tc<br /><br />Tc can never be smaller than 10ms!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-84275684109579286062009-06-28T20:07:00.008+01:002009-07-06T20:54:15.768+01:00Enhanced Interior Gateway Routing Protocol (EIGRP)Here is the next installment of my CCIE studies, the Cisco proprietary EIGRP. I know a fair bit about EIGRP but there are still bits I tend to forget so here goes at trying to condense EIGRP into a single blog posting!<br /><br />For detailed information please refer to the Cisco documentation on EIGRP <a href="http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_cfg_eigrp_ps6350_TSD_Products_Configuration_Guide_Chapter.html">here</a><br /><br /><b><u>Key Points</u></b><br /><br />Uses IP protocol 88<br />Uses Reliable Transport Protocol (RTP) for reliable exchanging of data (does not use UDP or TCP)<br />Default metric is bandwidth and delay<br />Normally multicasts hellos and updates to 224.0.0.10<br />Uses Diffusing Update Algorithm (DUAL) in order to find best routes<br />Best routes are called Successors<br />Supports Feasible Successors which are back-up routes to a Successor route<br />Sends full updates with new neighbours and partial updates thereafter<br />Supports MD5 authentication only<br />Auto-summarisation on by default<br />Supports VLSM by turning off auto-summarisation<br />Manual summarisation supported anywhere in the EIGRP network<br />Routes redistributed into EIGRP can be tagged<br />Different next-hop router can be defined<br />Multiprotocol - it can support IPX and AppleTalk by use of PDMs<br /><br /><b><u>Timers</u></b><br /><br /><b>Hello Timer</b> - The Hello interval is the rate at which EIGRP sends hello packets. The command <span style="font-weight: bold;">ip hello-interval eigrp</span> can be used to set the Hello interval time manually. The Hello interval defaults to 5 seconds for high-speed networks and 60 seconds for low-speed networks (i.e. less than 1.544Mbps).<br /><br /><b>Hold Timer</b> - This is the amount of time that a router will consider a neighbor alive without receiving hello packets. The hold time is <span style="font-weight: bold;">typically three times the hello interval</span>. You can adjust the hold time with the <span style="font-weight: bold;">ip hold-time eigrp</span> command.<br /><br />Unlike OSPF <span style="font-weight: bold;">changing the hello timer does not automatically adjust the hold down time</span>r.<br /><br /><b>Active Timer</b> - This timer controls the time the router waits after sending a query before declaring the route stuck in active (SIA) and resetting the neighbor relationship. To avoid this neighbor resetting you can temporary increase the active timer until you solve the problem by eliminating the cause. The <span style="font-weight: bold;">timers active-time [time-in-minutes]</span> command under the EIGRP process can be used to adjust the active timer or be completely disabled by issuing the <b>timers active-time disabled</b> command. The default is 3 minutes.<br /><br />There are some interesting points to be aware of with EIGRP timers:<br /><br />1. The Hello mechanism works independently in each direction. Hellos from router R1 to router R2 do not necessarily have to use the same parameters as Hellos from R2 to R1.<br /><br />2. The Hold timer is transmitted to the neighbor in the hello packet. R2 does not use its locally configured hold-time, but uses the value that R1 tells it to use.<br /><br />This second point warrants an explanation. Let's say R1 has a Hello timer of 3 seconds and Hold timer of 10 seconds and R2 has a Hello timer of 20 seconds and a Hold Timer of 90 seconds (these figures are completely arbitrary and in no way would I recommend you use these figures).<br /><br />Instinct would tell us that R1 may see R2 up initially but as R2's Hellos are longer than R1's Hold timer (20 seconds versus 10 seconds), R1 would believe that R2 is down. However, what point 2 says is that R1 will ignore its locally configured timers and use those advertised by R2 for the neighbour relationship with R2. Hence, R2 would only appear down to R1 if R1 does not receive a Hello from R2 within 90 seconds.<br /><br />This leads us nicely on to how EIGRP neighbours are formed.<br /><br /><b><u>Forming a neighbour relationship</u></b><u></u><br /><br />There are 4 things that potential EIGRP neighbours must agree on before they can be confirmed as neighbours:<br /><br />1. Authentication password must match assuming authentication is used<br />2. The autonomous system (AS) number must match<br />3. K values must match<br />4. Source IP address of a received Hello must be in the same subnet as the <b>primary</b> IP address configured on the interface that received the Hello.<br /><br />Note that timers do not need to match like other protocols!<br /><br />Point 4 may need explaining but it is pretty straightforward. What is says is that EIGRP neighbours will not form on secondary IP addresses. Let's take a look at an example:<br /><br />R1 and R2 are connected on their fa0/0 interfaces. R1 has the following configuration on its fa0/0 interface:<br /><br />#R1<br />int fa0/0<br /> ip address 192.168.1.1 255.255.255.0 <br /><br />R1 will expect the source address of a received Hello on fa0/0 to be in the 192.168.1.0/24 subnet. Let's say R2 is figured like this:<br /><br />#R2<br />int fa0/0<br /> ip address 192.168.2.1 255.255.255.0<br /> ip address 192.168.1.2 255.255.255.0 secondary<br /><br />The neighbour relationship will not form as R2 will source its Hellos from its primary IP address and that is not in the same subnet as R1's primary subnet on fa0/0.<br /><br />Another thing to bear in mind is that the subnet masks do not have to match in order for the neighbour relationship to be formed. Taking the same example as above with R1 and R2 let's configure them with different subnet masks:<br /><br />#R1<br />int fa0/0<br /> ip address 192.168.1.1 255.255.255.0<br /><br />#R2<br />int fa0/0<br /> ip address 192.168.1.2 255.255.255.128<br /><br />R1 will be expecting a received Hello to be sourced from an IP address in its primary subnet configured on fa0/0. Therefore it will expect an address in the range of 192.168.1.2 to 192.168.1.254. On R2 the IP address is indeed within that range and hence the neighbour relationship forms.<br /><br />The other 3 factors that must pass in order for a neighbour relationship to be formed are covered in more detail in other sections within this post.<br /><br /><b><u>Metrics - K values</u></b><u></u><br /><br />EIGRP uses a composite metric in order to calculate the cost to reach a subnet. By default it uses Path Bandwidth Value and Cumulative Interface Delay to give it its fancy name. They are more generally referred to as Bandwidth and Delay. There are five options in all with the other three being Reliability, Load, and Maximum Transmission Unit (MTU).<br /><br />To set the EIGRP metrics you issue the <b>metric weights <i>tos k1 k2 k3 k4 k5</i></b> command under the EIGRP process. It's worth noting what each K value refers to:<br /><br />k1 = Bandwidth (measured in kbps. Smallest/slowest bandwidth between the source and destination)<br />k2 = Load<br />k3 = Delay (Cumulative. Measured in 10s of microseconds AND DON'T YOU FORGET IT!)<br />k4 = Reliability<br />k5 = MTU<br /><br />Each value is either switched on (binary 1) or off (binary 0). Therefore the K values usually look like 10100. How I remember this is by saying that 10100 has a value of 20 in binary.<br /><br />Let's say I just want to use bandwidth as my metric. I would have to issue the following (assuming EIGRP uses AS 100).<br /><br />router eigrp 100<br /> metric weights 0 1 0 0 0 0<br /><br />Assuming we go back to the default settings of using bandwidth and delay the calculation of a metric is achieved by using the following formula:<br /><br />Metric = 256(10<sup>7</sup>/bandwidth) + 256(delay)<br /><br />Let's use an example to show how this works by assuming routers R1 and R2 are connected together using a T1 connection. R1 also has a LAN connection at 100Mbps.<br /><br /><b>R1:</b><br /><br />LAN interface delay = 100. As this is in 10s of microseconds a delay of 100 is 1000 microseconds which is 1 millisecond (1ms).<br />LAN interface bandwidth = 10000. Bandwidth is in kbps so 100Mbps is 10000kbps<br /><br />Putting those values in the above formula gives us a metric of 281600.<br /><br />256(10<sup>7</sup>/10000) + 256(100)<br /><br />R2 will therefore receive this metric. R2 now has to calculate its metric based on the received metric. R2 receives the metric on its T1 interface hence the bandwidth used in the calculation will be 1544kbps. Now comes the bit that most people tend to miss. remember that fancy name given to Delay? That's right, Cumulative Interface Delay. Let's say R2 has a delay of 1000 (i.e. 10ms). The Delay used in R2s metric calculation will be the 1000 local delay <b>PLUS</b> the delay upstream which in this case is the delay of 100 on R1. Hence, the delay on R2 will be 1100.<br /><br />The metric on R2 would therefore be:<br /><br />256(10<sup>7</sup>/1544) + 256(1100) = 1939631<br /><br />The word "cumulative" in Cumulative Interface Delay just refers to the addition of the upstream delay to the local delay.<br /><br /><b><u>EIGRP Packets</u></b><u></u><br /><br /><b>Hello</b> - Identifies neighbours, exchanges parameters, and is sent periodically as akeepalive function (every 5 seconds on interfaces above 1544kbps, every 60 seconds for speeds of 1544kbps and below). Sent to multicast address 224.0.0.10.<br /><br /><b>Update</b> - Sent as a multicast initially. If no acknowledgement received from specific neighbour then sent as unicast to that neighbour. Initially, full updates are sent, including all routes except those omitted due to split horizon. Once all routes have been exchanged, updates cease. Future partial updates occur when one or more routes change. If neighbours fail and recover, or new neighbour adjacencies are formed, full updates are sent.<br /><br /><b>Ack</b> - Acknowledges Update, Query, and Response packets.<br /><br /><b>Query</b> - Asks neighbouring routers to verify their route to a particular subnet. Reliable multicast.<br /><br /><b>Reply</b> - Sent by neighbours in reply to a Query packet. Reliable unicast.<br /><br /><b>Goodbye</b> - Used by a router to notify its neighbours when the router is gracefully shutting down due to removal of EIGRP process or the removal of a network statement under the routing process (e.g. no network 10.0.0.0). This is actually sent in a Hello packet with all K values set to 255.<br /><br /><b><u>EIGRP Updates</u></b><u></u><br /><br />Once routers are adjacent, they can exchange routes using EIGRP Update messages. The process follows this general sequence:<br /><br />1. Initially, full updates are sent, including all routes except those omitted due to split horizon.<br />2. Once all routes have been exchanged, updates cease.<br />3. Future partial updates occur when one or more routes change.<br />4. If neighbours fail and recover, or new neighbour adjacencies are formed, full updates are sent.<br /><br />EIGRP uses the <b>Reliable Transport Protocol (RTP - not to be confused with Real Time Protocol)</b> to send the multicast EIGRP updates. EIGRP sends updates, waiting on a <b>unicast ACK</b> message from each recipient. RTP allows the Update packet to be sent as a multicast. If any neighbours fail to acknowledge receipt of the Update packet, RTP sends a unicast Update to those neighbours.<br /><br />Let's look at an example where R1 sends an update and R2 fails to respond:<br /><br />1. R1 starts a <b>Retransmission Timout (RTO)</b> timer for each neighbour when it sends a reliable messgae like an Update packet. Cisco IOS actually calculates a <b>Smoothed Round-Trip Time (SRTT)</b> to each neighbour from which the RTO is derived. These values can vary over time.<br />2. R1 sends a multicast Update packet<br />3. R1 notes which neighbour it receives an ACK packet from<br />4. RTO expires before R2 responds with an ACK packet<br />5. R1 resends the Update packet, this time as a unicast, to R2.<br /><br />EIGRP and RTP use a simple acknowledgement process with a window size of one message. Each Update packet has a sequence number, with the returned ACK packet confirming receipt of the Update by listing the same sequence number.<br /><br />RTO, SRTT, and Sequence Number can all be viewed using the <b>show ip eigrp neighbor</b> command.<br /><br /><b><u>Basic Configuration</u></b><u></u><br />EIGRP uses a concept of an <b>autonomous system (AS)</b> which defines an area covered by a routing protocol and if you want to form a neighbour relationship with another router you have to be in the same AS. Back in the days of yore you had to advertise the classful network so if you wanted to advertise 10.1.2.0 you only needed to specify 10.0.0.0 in the network command.<br /><br />conf t<br />router eigrp 100<br /> network 10.0.0.0 <br /> no auto-summary <--turn off automatic summarisation (I do this as a matter of course) <br /><br />What does the <b>network</b> command tell the router to do? In EIGRP it tells the router to do two things:<br /><br />1. Advertise all networks that form part of the subnet specified<br />2. It tells the router to try and form an EIGRP neighbour relationship on the interfaces with IP addresses in that configured subnet.<br /><br />What happens if we only want one interface in the 10.0.0.0 network to try and form a relationship? We could certainly use the <b>passive-interface</b> command (covered in more detail later) but even better we can now specify a wildcard mask in our <b>network</b> statement to match particular interfaces. Let's say I have two interfaces in the 10.0.0.0/8 network and only want to form a neighbour relationship on fa0/0:<br /><br />int fa0/0<br /> ip address 10.1.0.1 255.255.255.0<br />int fa0/1<br /> ip address 10.1.1.1 255.255.255.0<br /><br />With the original behaviour of EIGRP we would have to do the following:<br /><br />router eigrp 100<br /> network 10.0.0.0<br /> passive-interface fa0/1<br /><br />Instead, just like OSPF, we can specify a wildcard mask:<br /><br />router eigrp 100<br /> network 10.1.0.0 0.0.0.255<br /><br />Or if we really want to just exactly that interface's IP address only:<br /><br />router eigrp 100<br /> network 10.1.0.1 0.0.0.0<br /><br /><b><u>Choosing the best route</u></b><u></u><br /><br />There are a few terms that one should know when it comes to calculating the best route to a particular subnet.<br /><br />Reported Distance (RD) - The metric received from a neighbour about a particular subnet<br />Advertised Distance (AD) - The metric advertised by a router about a particular subnet<br />Feasible Distance (FD) - The metric used by a router to reach a particular subnet<br />Successor Route - The route with the <b>lowest FD</b> to a particular subnet. This is promoted to the routing table.<br />Feasible Successor Route - A backup route to a Successor Route. For a route to considered a Feasible Successor it must have an <b>AD less than the FD</b>.<br /><br />Let's say R1 has a Successor Route to 192.168.1.0/24 with an FD of 100 via R2 (assume R2 has an AD of 85 and our RD to R2 is 15). R3 also tells R1 that it can get to 192.168.1.0/24 with an AD of 150 and R4 can also get to 192.168.1.0/24 with an AD of 90. Do we have a Feasible Successor route? The answer is Yes. R4s AD is less than the FD of the Successor Route (i.e. 100) so it will be considered a Feasible Successor route. Note that R3's AD is 150 which is greater than the FD of 100 so it will not be considered a Feasible Successor route.<br /><br />If, for example, R2 was to fail, R1 can simply promote the Feasible Successor route via R4 to the routing table thereby drastically reducing any network convergence time.<br /><br />How do we view feasible successors? We simply use the <b>show ip eigrp topology</b> to view EIGRP's Topology table (this will show Successor and Feasible Successor routes only. If you want to view all routes use the <b>show ip eigrp topology all-links</b> command). I will now show a snippet of an entry to show how we identify a Feasible Successor.<br /><br />R1# show ip eigrp topology<br />[output omitted]<br />P 172.31.24.0/30, 1 successors, FD is 768<br /> via 172.31.11.2 (768/512), FastEthernet0/0<br /> via 172.31.14.2 (1024/512), Serial0/0.4<br /><br />That snippet shows that the route to 172.31.24.0/30 has <span style="font-weight: bold;">one successor route which is always the first route underneath</span> (in this case via FastEthernet0/0). Note the second entry via Serial0/0.4 and the contents of the brackets (1024/512). The 1024 denotes this router's Feasible Distance to reach the 172.31.24.0/30 subnet via Serial0/0.4. The Feasible Distance via FastEthernet0/0 is 768 which makes it better than 1024 and hence become the successor route. The second figure in the brackets is 512 which is the Reported Distance to the 172.31.24.0/30 subnet on Serial0/0.4. If this figure is less than the Feasible Distance of the Successor Route then it can be considered a Feasible Successor. In this case 512 is less than 768 so it can be considered a Feasible Successor. Let's bolden the text in the snippet above to help illustrate that point:<br /><br />R1# show ip eigrp topology<br />[output omitted]<br />P 172.31.24.0/30, 1 successors, FD is <b>768 - FEASIBLE DISTANCE OF SUCCESSOR ROUTE</b><br /> via 172.31.11.2 (768/512), FastEthernet0/0<br /> via 172.31.14.2 (1024/<b>512 - MUST BE LESS THAN FD OF SUCCESSOR ROUTE</b>), Serial0/0.4<br /><br />EIGRP can now support up to 16 equal-cost paths to a destination (not 6 as most books would have you know). This simply means that R1 could have 16 Successor Routes to a destination and would load balance across all 16 routes.<br /><br /><b><u>Load Balancing and Unequal Cost Load Balancing</u></b><u></u><br /><br />I've already alluded to the fact that EIGRP can now support up to 16 equal-cost paths to a destination (not 6 as most books would have you know). Remember that this simply means that R1 could have 16 Successor Routes to a destination and would be able to load balance across all 16 routes.<br /><br />You can configure this using the <b>maximum-paths</b> command under the EIGRP process. For example:<br /><br />router eigrp 100<br /> maximum-paths 6 <--sets the maximum number of Successor Routes to 6 <br /><br />A neat feature of EIGRP is to be able to load balance across paths that have different costs. In fact I was asked to configure this just the other day. It uses the concept of a multiplier called <b>variance</b>. This multiplies the FD of a route by the configured figure (let's call this value FDnew). Any <b>Feasible Successor</b> routes that have a value less than FDnew are considered to be equal to the original Successor Route and are promoted to the routing table.<br /><br />To configure the variance we simply use the <b>variance</b> command under the EIGRP process:<br /><br />router eigrp 100<br /> variance 2 <--would multiply the FD of all Successor Routes by 2 <br /><br />Let's look at an example. R1 has a Successor Route to 192.168.1.0/24 via R2 with a FD of 100. R1 also has a Feasible Successor route via R3 with an AD of 90 and a total FD of 190. R1 also has a Feasible Successor route via R4 with an AD of 95 and a total FD of 205. R1 has <b>variance 2</b> configured under its EIGRP process. The FD of the Successor Route is now 100 * 2 = 200. We now look at the FD of each Feasible Successor to see if it is less than 200. In the case of R3 this is true, and with R4 it is false. Therefore the routing table would contain two routes to 192.168.1.0/24 - the original route via R2 and the route via R3.<br /><br />You can configure how EIGRP shares traffic across links. By default it will balance evenly across routes, ignoring EIGRP metrics. The folliwng can be configured under the EIGRP process:<br /><br /><b>traffic-share balanced</b> - The router balances across the routes, giving more packets to lower-metric routes<br /><br /><b>traffic-share min</b> - Although multiple routes are installed in the routing table, the router sends traffic using only the lowest-metric route<br /><br /><b>traffic-share balanced across-interfaces</b> - If more routes exist than are allowed with the <b>maximum-paths</b> setting, the router chooses routes with different outgoing interfaces, for better balancing. <br /><br /><b><u>Going active on a route</u></b><u></u><br /><br />There will inevitably be occasions when a route to a particular subnet goes down for some reason. If there is no feasible successor for that route the router will go <b>active</b> on that route. Conversely, if the route is up it is said to be <b>passive</b>.<br /><br />So what does going active actually mean? Basically the router will query (remember that EIGRP Query packets are sent as a reliable multicast and will expect an Ack to be sent back) all of its neighbours asking them if they know of a route to the subnet in question. The router will then expect all of its neighbours to reply, using a reliable unicast EIGRP Reply packet, before calculating a new route and sending an Ack back.<br /><br />Neighbours that are queried can do one of three things:<br /><br />1. Send a Reply packet back stating that they do not have a route<br />2. Send a Reply packet back with details of their route<br />3. Go Active themselves if 1 or 2 are not satisfied and withholds its response until it has received all of its replies from the neighbours it is querying.<br /><br />Hopefully you can see a pitfall here. If R1 went active on a route causing R2 to go active, it may mean R3 goes active too, etc. If a router stays active on a route for too long (<b>default is 3 minutes</b>) it is said to be <b>stuck-in-active</b> on that route and brings down the neighbour relationship to the router it has not received a reply from as it thinks that that router is having some problems. However, that router may be fine and it is downstream where the issue lies. This is clearly an undesirable state.<br /><br />You can turn off the active timer by issuing the <b>timers active-timer disabled</b> command under the EIGRP process in order to combat a route from being stuck-in-active, however, there are more elegant solutions which revolve around limiting the query scope which we will discuss in the next section.<br /><br /><b><u>Limiting the Query Scope</u></b><u></u> <br /><br />Two methods can be used to limit the query scope in an EIGRP network. The first method that can be used is summarisation. When a Query reaches a router that has a summarised route, but not the specific route in the Query, the router immediately replies that it does not have that route. Put simply, if my router had a summarised route of 192.168.1.0/24 and it received a Query about network 192.168.1.16/28, it will send a Reply saying that it doesn't have a route to 192.168.1.16/28.<br /><br />The second method for limiting the query scope involves the use of <b>stub</b> routers. Stub routers should not be used as transit routers and <b>non-stub routers do not query stub routers</b>. An ideal candidate for being configured as a stub router is a spoke site router in a hub-and-spoke topology. EIGRP stub routers are very easy to configure:<br /><br />router eigrp 100<br /> eigrp stub <-- makes this an EIGRP stub router <br /><br />By default, the <b>eigrp stub</b> command will cause the router that it is issued on to advertise <b>connected</b> and <b>summary</b> routes only and indeed when you issue a <b>show run</b> you will see the following:<br /><br />router eigrp 100<br /> eigrp stub connected summary<br /><br />There are other options that can be specified, some of which are not compatible with others. The following describes these options:<br /><br />eigrp stub <b>connected</b> - Advertise connected routes, but only for interfaces matched with a <b>network</b> command.<br />eigrp stub <b>summary</b> - Advertise auto-summarised or statically configured summary routes.<br />eigrp stub <b>static</b> - Advertise static routes, assuming the <b>redistribute static</b> command is configured.<br />eigrp stub <b>redistributed</b> - Advertise redistributed routes, assuming redistribution is configured.<br />eigrp stub <b>receive-only</b> - Does not advertise any routes. <b>This option cannot be used with any other option.</b><br /><br /><b>Authentication</b><br /><br />As I mentioned earlier in this piece, EIGRP can have authentication configured so that EIGRP communication can be secured. Unlike other routing protocols EIGRP supports <b>MD5 authentication only</b>. If authentication is configured a pair of routers must be able to pass the authentication procedure if they are to successfully become neighbours. As you would expect, the <span style="font-weight: bold;">passwords on both sides must match</span> in order for the EIGRP neighbour relationship and subsequent updates to be successful.<br /><br />You configure the passwords in global configuration mode using <b>key-chains</b> which are made up of <b>keys</b> which in turn have the password configured on them with optional send and receive lifetimes. Let's configure a basic key-chain (more advanced configuration can be seen <a href="http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_ip_prot_indep.html#wp1056961">here</a>):<br /><br />key-chain MyKeyChain<br /> key 1<br /> key MyPassword<br /><br />To turn EIGRP authentication on you must configure it under the interface which will be sending the updates:<br /><br />int fa0/0<br /> ip authentication mode eigrp <span style="font-style: italic;">autonomous-system-number</span> md5<br /> ip authentication key-chain eigrp <span style="font-style: italic;">autonomous-system-number key-chain-name</span><br /><br />So if I was to use AS 100 my configuration would look like:<br /><br />int fa0/0<br /> ip authentication mode eigrp 100 md5<br /> ip authentication key-chain eigrp 100 MyKeyChain<br /><br /><b><u>EIGRP Summarisation</u></b><u></u><br />EIGRP supports classless routing but is classful in nature by default. What this means in very simple terms is that EIGRP can be configured to send subnet masks supports Variable Length Subnet Masks. If a router running EIGRP has a different class of address on two interfaces (e.g. a Class A address on one interface and a Class B address on another interface) an update going out of the Class B interface will automatically summarise the Class A networks in that update to the default mask of /8. For example, the router may have learned about 10.1.2.0/24 on one interface but because it is advertising that network out of an interface with a different class of address it would advertise it as 10.0.0.0/8. This doesn't happen if you issue the <b>no auto-summary</b> command under the EIGRP routing process and the router will advertise 10.128.1.0/24. This is especially important when it comes to <b>discontiguous networks</b> which is a fancy name for a class of network that has another class of network in between, for example:<br /><br />(Class A)<span style="font-weight: bold;">R1</span>(Class B)-->(Class B)<span style="font-weight: bold;">R2</span>(Class B)-->(Class B)<span style="font-weight: bold;">R3</span>(Class A)<br /><br />Here R2 could learn a route to 10.0.0.0/8 from both R1 and R3 as both R1 and R3 would have automatically summarised the Class A address to a /8.<br /><br />EIGRP also supports <b>summarisation anywhere in the network</b> by configuring a summary address on an interface:<br /><br />int fa0/0<br /> ip summary-address eigrp <span style="font-style: italic;">as-number ip-address mask</span> [admin-distance] [leak-map name]<br /><br />The <span style="font-weight: bold;">ip summary-address eigrp</span> command is used to configure interface-level address summarization. <span style="font-weight: bold;">EIGRP summary routes are given an administrative distance value of 5.</span> The administrative distance metric is used to advertise a summary without installing it in the routing table.<br /><br />By default, EIGRP summarizes subnet routes to the network level. The no auto-summary command can be entered to configure subnet level summarization.<br /><br /><b>EIGRP Support for Leaking Routes</b> - Configuring the <span style="font-weight: bold;">leak-map</span> keyword allows the advertisement of a component route that would otherwise be suppressed by the manual summary. Any component subset of the summary can be leaked. A route map and access list must be defined to source the leaked route.<br /><br />The following is default behavior if an incomplete configuration is entered:<br /><br />If the leak-map keyword is configured to reference a nonexistent route map, the configuration of this keyword has no effect. The summary address is advertised but all component routes are suppressed.<br /><br />If the leak-map keyword is configured but the access-list does not exist or the route map does not reference the access list, the summary address and all component routes are sent.<br /><br />Let's have a look at some examples:<br /><br />The following example configures an administrative distance of 95 on interface FastEthernet0/0 for the 192.168.0.0/16 summary address:<br /><br />router eigrp 100<br /> no auto-summary<br /><br />interface fa0/0<br /> ip summary-address eigrp 100 192.168.0.0 255.255.0.0 95<br /><br />The following example configures the 10.1.1.0/24 subnet to be leaked through the 10.0.0.0 summary address:<br /><br />router eigrp 100<br /><br />access-list 1 permit 10.1.1.0 0.0.0.255<br />route-map LEAK-10-1-1 permit 10<br /> match ip address 1<br /><br />interface fa0/0<br /> ip summary-address eigrp 1 10.0.0.0 255.0.0.0 leak-map LEAK-10-1-1<br /><br /><b><u>Split Horizon</u></b><u></u><br /><br />Split Horizon stops a network being advertised out of an interface in which it has been learned. For example, if a router learned about network 192.168.1.0/24 on fa0/0 an EIGRP routing update out of fa0/0 would not contain 192.168.1.0/24. This is to prevent routing loops from occurring. Split Horizon is enabled by default on all interfaces except Frame Relay interfaces where the IP address is configured on the physical interface. You can turn off Split Horizon on an interface by issuing the <b>no ip split-horizon eigrp <i>autonomous-system-number</i></b> command under an interface:<br /><br />interface FastEthernet0/0<br /> no ip split-horizon eigrp 100<br /><br /><b><u>Passive Interface</u></b><br /><br />Unlike RIP where the <b>passive-interface</b> command tells a router's interface to stop sending updates out of that interface, that <b>same command under the EIGRP process actually prevents a neighbour relationship from forming.</b><br /><br />router eigrp 100<br /> network 10.0.0.0<br /> no auto-summary<br /> passive-interface FastEthernet0/0 <--stops EIGRP forming neighbour relationship on fa0/0 <br /><br />Be aware that you can make all interfaces passive by issuing the <b>passive-interface default</b> command. This might be desirable when you want all interfaces except one from forming a neighbour relationship. For example, you may only want a router connected to fa0/0 to form a neighbour relationship with your router so you make every interface passive by default and then issue the <b>no passive-interface [interface]</b> command:<br /><br />router eigrp 100<br /> network 10.0.0.0<br /> no auto-summary<br /> passive-interface default <--stops EIGRP forming neighbour relationships on all interfaces <br /> no passive-interface FastEthernet0/0 <--allows EIGRP to form a neighbour relationship on fa0/0 <br /><br /><b><u>Route Filtering</u></b><u></u><br /><br />In order to prevent updates about certain networks from being received or sent you should use something called a <b>distribute-list</b>. A distribute-list filters out routes from entering the routing table or being sent by referencing a pre-configured access-list or prefix-list.<br /><br />For example, let's create an access-list:<br /><br />access-list 1 permit 192.168.1.0 0.0.0.255<br /><br />The syntax of a distribute-list when using an access-list is as follows and is configured under the routing process:<br /><br />distribute-list [access-list-number_or_access-list-name] [in | out] [interface]<br /><br />If there is a match in the access-list then that route is <b>filtered out</b> of the routing update. If you look at my access-list you will see that I am filtering out the 192.168.1.0/24 network.<br /><br />In the following example I will use a distribute-list to stop updates being received on fa0/0 about 192.168.1.0/24<br /><br />access-list 1 permit 192.168.1.0 0.0.0.255<br /><br />router eigrp 100<br /> network 192.168.1.0<br /> no auto-summary<br /> distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1 <br /><br />The next example shows you how to stop routes being advertised by changing the direction in the distribute-list command. <br /><br />access-list 1 permit 192.168.1.0 0.0.0.255 <br /><br />router eigrp 100 <br /> network 192.168.1.0 <br /> no auto-summary <br /> distribute-list 1 out FastEthernet0/0 <--prevents updates out of fa0/0 as specified by ACL 1 <br /><br /><b><u>Using Offset Lists to change EIGRP's metric for a particular route</u></b><br /><br />You change the metric received or advertised in EIGRP by using an offset-list. This is very similar in configuration to distribute-lists where you reference an access-list. The access-list will be checked against sent or received updates and the specified offset added to the metric. The basic syntax is:<br /><br />offset-list [access-list-number_or_access-list-name] [in | out] [specified-offset] [interface]<br /><br />Let's look at an example:<br /><br />R1 has a route for 192.168.1.0/24 with a metric of 1544. We want to advertise that route to R2 with a metric of 1600. Let's configure our offset-list:<br /><br />access-list 1 permit 192.168.1.0 0.0.0.255<br /><br />router eigrp 100<br /> offset-list 1 out 56 FastEthernet0/0<br /><br />Here <b>offset-list 1</b> specifies ACL 1 which will match 192.168.1.0/24. This is applied outbound as specified by <b>out</b>. We add 56 to the metric of all routes matched by our access-list as specified by the <b>1</b> after the <b>out</b> keyword. Finally we specify the interface out of which our offset-list is applied.<br /><br />Offset lists are more applicable to RIPv1 and RIPv2 than EIGRP has RIP has such a limited metric range. With EIGRPs complex metric it is very doubtful that you would want to change the metric in this way.<br /><br /><b><u>Clearing EIGRP routes from the routing table</u></b><u></u><br /><br />The <b>clear ip route *</b> command from privileged mode will not affect EIGRP routes as the routers are in the topology table and will simply go straight back in to the routing table. In the case of EIGRP you have to tear down the neighbour adjacency:<br /><br /><b>clear ip eigrp neighbor</b> - clears all neighbour adjacencies<br /><b>clear ip eigrp neighbor <i>ip-address</i></b> - clears specified neighbour adjacency<br /><b>clear ip eigrp neighbor <i>interface</i></b> - clears neighbour adjacencies on specified interface<br /><br /><b><u>Conclusion</u></b><br /><br />If you're at ICND2 and above you need to know the majority of what I've written but as with my RIP posting I've tried to be as brief as possible as I don't see the point of reinventing the wheel as there are so many quality papers on EIGRP. I hope I've got enough detail in here for you to understand the basic operation of EIGRP and some of the extras that can be configured.<br /><br />As always, if you have any questions about this topic please feel free to leave a comment and/or email me using the Contact Me tab at the top of the screen.<br /><br />Good luck with your studies!Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-6240379334240712627.post-87569524974534470212009-06-09T14:25:00.004+01:002009-06-09T14:39:07.375+01:00"ip classless" versus "no ip classless"This often has me confused but the article below, rejigged slightly from the original article <a href="http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094823.shtml#classless">here</a> seems to have cleared the fog from my mind and hopefully yours too.<br /><br />Where the <span style="font-weight:bold;">ip classless</span> configuration command falls within the routing and forwarding processes is often confusing. In reality, IP classless only affects the operation of the forwarding processes in IOS; it doesn't affect the way the routing table is built. If IP classless isn't configured (using the <span style="font-weight:bold;">no ip classless</span> command), the router won't forward packets to supernets. As an example, let's place three routes in a routing table and route packets through the router.<br /><br />Note: If the supernet or default route is learned via IS-IS or OSPF, the no ip classless configuration command is ignored. In this case, packet switching behavior works as though ip classless were configured.<br /><br /> router# show ip route<br /> ....<br /> 172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks<br /> D 172.30.32.0/20 [90/4879540] via 10.1.1.2<br /> D 172.30.32.0/24 [90/25789217] via 10.1.1.1<br /> S* 0.0.0.0/0 [1/0] via 10.1.1.3 <br /><br />Remembering that the 172.30.32.0/24 network includes the addresses 172.30.32.0 through 172.30.32.255, and the 172.30.32.0/20 network includes the addresses 172.30.32.0 through 172.30.47.255, we can then try switching three packets through this routing table and see what the results are.<br /><br />A packet destined to 172.30.32.1 is forwarded to 10.1.1.1, since this is the longest prefix match.<br /><br />A packet destined to 172.30.33.1 is forwarded to 10.1.1.2, since this is the longest prefix match.<br /><br />A packet destined to 192.168.10.1 is forwarded to 10.1.1.3; since this network doesn't exist in the routing table, this packet is forwarded to the default route.<br /><br />A packet destined to 172.30.254.1 is <span style="font-weight:bold;">dropped</span>.<br /><br />The surprising answer out of these four is the last packet, which is dropped. <span style="font-weight:bold;">It's dropped because its destination, 172.30.254.1, is within a known major network, 172.30.0.0/16, but the router doesn't know about this particular subnet within that major network.</span><br /><br /><b><u>This is the essence of classful routing:</b></u> If one part of a major network is known, but the subnet toward which the packet is destined within that major network is unknown, the packet is dropped.<br /><br />The most confusing aspect of this rule is that <span style="font-weight:bold;">the router only uses the default route if the destination major network doesn't exist in the routing table at all.</span> However, if <b>ip classless</b> was configured the default route would have been used.<br /><br />So there you have it. The fundamental difference between the configuration of <b>ip classless</b> and <b>no ip classless</b> is whether the default route would be used.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-6240379334240712627.post-70173945096925880362009-06-09T13:48:00.004+01:002009-06-09T14:22:32.357+01:00Summary Route to Null0 - Routing Loop PreventionWhy is that when we summarise networks we see a static summary route automatically generated to Null0?<br /><br />Let's assume for a minute that we didn't have this static route automatically generated for us and consider the following example.<br /><br />I have a router R1 that has subnets 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24, and 192.168.5.0/24 and I decide that R1 should advertise these routes in one summary route to its neighbour at R2 via R1s Serial0/0 interface. As I am using one summary route I could summarise them down to 192.168.0.0/21 which covers 192.168.0.0 to 192.168.7.255. I also have a default route configured on R1 which points all unmatched traffic out of Serial0/0 (ip route 0.0.0.0 0.0.0.0 Serial0/0).<br /><br />Now let's say that R2 receives a packet destined for 192.168.6.1/24. It will look into its routing table and see that there is a route to 192.168.0.0/16 via R1 which is the summary route sent by R1. R2 forwards this packet to R1 and then what happens? R1 has entries for 192.168.1.0 - 192.168.5.0 in its routing table but no entry for 192.168.6.0/24. So then what does it do? Remember there is a default route configured on R1 pointing to R2 so it will forward the packet back to R2. R2 will look into its routing table and forward it back to R1 ad infinitum. What we have here is a routing loop.<br /><br />This is why we have the automatically generated summary route to Null0. In our example above the IOS would have generated the following entry in our routing table:<br /><br />192.168.0.0/21 is a summary, 00:00:05, Null0<br /><br />Now there is a route for 192.168.6.0 to 192.168.7.255 which will go to Null0 (i.e. be dropped) instead of following the default route, and in this example, creating a routing loop. All of this could be avoided by not oversummarising.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-6240379334240712627.post-35879112339340939922009-06-09T13:41:00.017+01:002011-10-12T12:25:22.566+01:00IndexFollow the links below to find the main articles on this site:<br />
<br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/10/95th-percentile-how-isps-charge.html">95th Percentile - How ISPs charge</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/03/when-to-use-access-lists-or-prefix.html">Access Lists vs Prefix Lists</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2007/11/ccna-connecting-devices.html">Cabling Cisco devices</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/02/how-to-calculate-multicast-mac-address.html">Calculate Multicast MAC Address</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/04/ccie-warm-up-phase-bgp.html">CCIE - Warm-Up Phase - BGP</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/05/ccie-warm-up-phase-multicast.html">CCIE - Warm-Up Phase - Multicast</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/04/ccie-warm-up-phase-ospf.html">CCIE - Warm-Up Phase - OSPF</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2010/11/ccnp-training-in-uk-with-networks-inc.html">CCNP Training in the UK</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2009/06/enhanced-interior-gateway-routing.html">Enhanced Interior Gateway Protocol (EIGRP)</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2009/08/frame-relay-cir-bc-tc.html">Frame Relay - CIR, Bc, Tc</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/02/frame-relay-becnfecn.html">Frame Relay - BECN/FECN</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2008/12/gns3-configuration-guide-linux-fedora-9.html">GNS3 Configuration Guide (Linux)</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2007/12/gns-configuration-guide.html">GNS3 Configuration Guide (Windows)</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2008/04/gns3-pemu-configuration-guide-latest.html">GNS3 PEMU Configuration Guide</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2008/06/adding-hostspcs-to-gns3-vpcs.html">GNS3 VPCS Configuration Guide</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2007/12/how-to-calculate-wildcard-mask.html">How to calculate a wildcard mask</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2009/06/ip-classless-versus-no-ip-classless.html">"ip classless" versus "no ip classless"</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2010/04/mpls-command-memorizer-review.html">MPLS Command Memoriser Review</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/03/multicast-rpf.html">Multicast RPF</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2007/11/nat-in-nutshell.html">NAT In A Nutshell</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2007/11/ospf-and-nbma-networks.html">OSPF and Frame Relay</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/03/ppp-authentication-using-aaa.html">PPP Authentication - AAA</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/03/ppp-authentication.html">PPP Authentication - PAP and CHAP</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/03/pppoe-server-and-client.html">PPPoE Server and Client</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2010/06/qos-bandwidth-bandwidth-percent.html">QoS - Bandwidth, Bandwidth Percent, Bandwidth Remaining Percent</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2009/06/rip-routing-information-protocol.html">RIP - Routing Information Protocol</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2011/04/rip-adjusting-default-timers.html">RIP - Adjusting timers</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2009/06/route-maps-and-access-lists.html">Route Maps and Access Lists</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2007/11/router-summarization.html">Route Summarization - Easy Networks</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2008/04/complex-route-summarization.html">Route Summarization - Complex Networks</a><br />
<a href="http://subnettingmadeeasy.blogspot.com/2009/06/summary-route-to-null0-routing-loop.html">Summary Route to Null 0 - Routing Loop Prevention</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2007/11/subnetting-made-easy-lesson.html">Subnetting Made Easy - Critically Acclaimed!</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2007/12/vlan-trunking-remembering-which.html">VLAN Trunking - Which combination forms a trunk?</a><br />
<a href="http://www.subnettingmadeeasy.blogspot.com/2008/12/vyatta-on-vm-workstation.html">Vyatta on VM Workstation</a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6240379334240712627.post-88098603972244492602009-06-08T19:07:00.018+01:002010-05-14T21:33:15.063+01:00RIP - Routing Information ProtocolWhether you are taking ICND1, CCNA, CCNP, CCDA, CCIE etc you should all know about RIP. It is very rare for me to come across RIP in my day-to-day work hence I tend to forget some of the nuances behind it. I will focus on RIPv2 but will touch upon RIPv1 in terms of comparison.<br /><br /><b><u>Metric</u></b><u></u><br /><br />RIP is a distance vector protocol which uses the notion of hop counts as its metric with any one router up to a maximum of 15 hops away from another router. What this means is that if there is a network that is 16 hops or more away from your RIP router and your entire routing domain is running RIP you won't be able to reach that network. It therefore means that RIP is not suitable for large networks. RIPv1 and v2 both use the same maximum hop count as their metric.<br /><br /><b><u>Classful and Classless behaviour</u></b><u></u><br /><br />RIPv1 is classful and RIPv2 is classless. What this means in very simple terms is that RIPv1 does not send the subnet mask in its routing updates whereas RIPv2 does and as such RIPv2 supports Variable Length Subnet Masks. If a router running RIPv1 has a different class of address on two interfaces (e.g. a Class A address on one interface and a Class B address on another interface) an update going out of the Class B interface will automatically summarise the Class A networks in that update to the default mask of /8. For example, the router may have learned about 10.1.2.0/24 on one interface but because it is advertising that network out of an interface with a different class of address it would advertise it as 10.0.0.0/8. This doesn't happen with RIPv2 as you can issue the <b>no auto-summary</b> command under the routing process and the router will advertise 10.128.1.0/24. This is especially important when it comes to <b>discontiguous networks</b> which is a fancy name for a class of network that has another class of network in between, for example:<br /><br />(Class A)<span style="font-weight: bold;">R1</span>(Class B)-->(Class B)<span style="font-weight: bold;">R2</span>(Class B)-->(Class B)<span style="font-weight: bold;">R3</span>(Class A)<br /><br />Here R2 could learn a route to 10.0.0.0/8 from both R1 and R3 as both R1 and R3 would have automatically summarised the Class A address to a /8.<br /><br />A point that is often overlooked with RIP is the behaviour when the same class of address is used throughout. If my router had an interface with a Class A address but with a non-Class A subnet mask (e.g. 10.1.2.0/24) and I received an update about 10.1.3.0/24 through that interface, the RIP router would assume that it should apply the mask configured on that interface (i.e. a /24) and not the default Class A mask of /8.<br /><br /><b><u>Basic Configuration</b></u><br /><br />Always advertise the classful network so if you want to advertise 10.1.2.0 you only need to specify 10.0.0.0 in the network command.<br /><br />conf t<br />router rip<br />version 2 <--RIPv2 enabled <br />network 10.0.0.0 <br />no auto-summary <--turn off automatic summarisation (I do this as a matter of course) <br /><br />What does the <b>network</b> command tell the router to do? In RIP it tells the router to do three things:<br /><br />1. Advertise all networks that form part of the subnet specified<br />2. It tells the router to listen to RIP updates on the interfaces with IP addresses in that configured subnet.<br />3. It tells the router to send RIP updates out of the interfaces with IP addresses in that configured subnet.<br /><br /><b><u>Passive Interface</u></b><br /><br />The <b>passive-interface</b> command tells a router's interface to stop sending updates out of that interface. Note here that the interface will still receive RIP updates because it never forms neighbour adjacencies, and just receives information from other RIP routers.<br /><br />router rip<br />version 2<br />network 10.0.0.0<br />no auto-summary<br />passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0 <br /><br />Be aware that you can make all interfaces passive by issuing the <b>passive-interface default</b> command. This might be desirable when you want all interfaces except one from sending updates. For example, you may only want fa0/0 sending RIP updates so you make every interface passive by default and then issue the <b>no passive-interface [interface]</b> command:<br /><br />router rip<br />version 2<br />network 10.0.0.0<br />no auto-summary<br />passive-interface default <--stops RIP updates from being sent out of all interfaces <br />no passive-interface FastEthernet0/0 <--allows RIP updates to be sent out of that interface <br /><br /><b><u>How do we stop updates from being received?</u></b><br /><br />As we have seen the <b>passive-interface</b> command tells our router to not send RIP updates out of the specified interface but that same interface can still receive RIP updates. In order to prevent updates from being received you should use something called a <b>distribute-list</b>. A distribute-list filters out routes from entering the routing table by referencing a pre-configured access-list or prefix-list.<br /><br />For example, let's create an access-list:<br /><br />access-list 1 permit any<br /><br />The syntax of a distribute-list when using an access-list is as follows and is configured under the routing process:<br /><br />distribute-list [access-list-number_or_access-list-name] [in | out] [interface]<br /><br />If there is a match with a deny statement in the access-list then that route is <b>filtered out</b> of the routing update. If you look at my access-list you will see that I am, in effect, matching everything in my access-list so all routes should be filtered out.<br /><br />Using the earlier configuration example, I will use a distribute-list to stop updates being received on fa0/0 and passive-interface from sending updates out of fa0/0.<br /><br />access-list 1 deny any<br /><br />router rip<br />version 2<br />network 10.0.0.0<br />no auto-summary<br />passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0 <br />distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1 <br /><br />You could replace the passive-interface command with a distribute-list. To do this make sure your access-list permits everything as in my preconfigured ACL 1 and apply it outbound on the outgoing interface: <br /><br />access-list 1 permit any <br />router rip<br /> version 2 <br /> network 10.0.0.0 <br /> no auto-summary <br /> distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1 <br /> distribute-list 1 out FastEthernet0/0 <--filter outgoing updates on fa0/0 as specified by ACL 1 <br /><br /><b><u>Administrative Distance (AD)</u></b><br /><br />RIP has an AD of 120. Cisco uses AD as a measure of trustworthiness about a certain route. If there are two routes to the same network learnt by different routing protocols then the AD is used as a tiebreaker. The routing protocol with the <b>lowest AD</b> is considered to be more trustworthy and the route learned from that routing protocol will be installed into the routing table. Below are some of the ADs of static routing and routing protocols:<br /><br />Connected Interface = 0<br />Static route = 1<br />EIGRP Summary = 5<br />eBGP = 20<br />Internal EIGRP = 90<br />IGRP = 100<br />OSPF = 110<br />ISIS = 115<br />RIP = 120<br />EGP = 140<br />ODR = 160<br />External EIGRP = 170<br />iBGP = 200<br />Unknown = 255<br /><br />Looking at those ADs, RIP is not a terribly trusted protocol and equivalent routes learned by static, eBGP, Internal EIGRP, IGRP, OSPF, and ISIS would be installed in the routing table before a RIP route. Of course you can change the AD of a routing protocol by issuing the <b>distance</b> command under the routing process:<br /><br />router rip<br />version 2<br />distance 90<br /><br />Interestingly if you set the distance to 255 no routes learned by that routing protocol will be installed in the routing table.<br /><br /><b><u>Sending Updates</u></b><br /><br /><span style="font-weight: bold;">RIPv1 broadcasts</span> its routing updates to 255.255.255.255 whereas <span style="font-weight: bold;">RIPv2 multicasts</span> its updates to 224.0.0.9. Both use <span style="font-weight: bold;">UDP Port 520</span> at the Transport Layer. A router's <span style="font-weight: bold;">full routing table is sent every 30 seconds</span> to the IP address above depending on whether v1 or v2 is used. There are also <b>triggered updates</b> which are sent when a route in a router's routing table changes.<br /><br />When a router sends its update it adds 1 to the metric of each route it is advertising so that receiving routers know the metric to get to that route. For example, if a router had a route to 192.168.1.0/24 with a metric of 2 , it would advertise it with a metric of 3.<br /><br /><b><u>Sending and Receiving version on interfaces</u></b><br /><br />By default a RIP router will send only v1 updates out of an interface but receive both v1 and v2 updates. This allows for a mix of v1 and v2 capable routers. If your router is running RIPv2 it can only send and receive v2 updates only. You can configure it yourself under an interface:<br /><br />interface Fastethernet0/0<br />ip rip receive version [1 | 2 | 1 2]<br />ip rip send version [1 | 2 | 1 2]<br /><br /><b><u>Timers</u></b><br /><br />It is worth fully understanding how the timers in RIP work and what their default values are. They are:<br /><br />Update Timer = 30 seconds<br />Invalid Timer = 180 seconds<br />Holddown Timer = 180 seconds<br />Flush Timer = 240 seconds<br /><br />When a route is learned via RIP the Invalid and Flush timers are started for that route and are reset when that route is learned again. In normal operation this should be every 30 seconds as the router that has advertised this route should be sending their update every 30 seconds as dictated by the Update Timer. If there is a failure in the network that stops updates about this route from being received from the original advertising router, the Invalid and Flush timers will count up over 30 seconds towards 180 and 240 seconds respectively. If during that time our router learns the same route but from a different source and it has a worse metric (i.e. the hop count is greater than our current route) it won't install that update in its routing table until the original route is flushed. Once the Invalid Timer reaches 180 seconds the Holddown Timer starts counting down from 180 seconds with the Flush Timer only having 60 seconds left as it has already been running for 180 seconds. The route in the routing table will now show something like this:<br /><br />R 192.168.1.0/24 is possibly down<br /><br />Whichever is the first out of the Holddown and Flush timers to expire will cause the route to be removed/flushed from the routing table. By default this will always be the Flush timer as it has only 60 seconds left to elapse once the Invalid Timer reaches 180 seconds. Your router can now install previously heard updates that originally had a worse metric once those updates have been received again. You can quickly see why RIP has slow convergence time and would have to wait 240 seconds for the old route to be flushed and could wait for another 30 seconds to receive an update if one exists. That's 270 seconds, or three and a half minutes, which is bloody slow and it could be longer! You can adjust your timers using the <b>timers basic <i>update</i> <i>invalid</i> <i>holddown</i> <i>flush</i></b> under the routing process:<br /><br />router rip<br />version 2<br />timers basic 30 90 120 120<br /><br />This sets the Update Timer to 30 seconds, Invalid Timer to 90 seconds, and both the Flush and Holddown Timers to 120 seconds.<br /><br /><b><u>Neighbour relationship</u></b><br /><br />RIP has absolutely no concept of neighbours. It simply listens to updates from other routers and it never, ever, ever, sends Hellos, ok? This is what is meant when you hear the term "routing by rumour".<br /><br /><b><u>Split Horizon</u></b><br /><br />Split Horizon stops a network being advertised out of an interface in which it has been learned. For example, if a router learned about network 192.168.1.0/24 on fa0/0 a RIP routing update out of fa0/0 would not contain 192.168.1.0/24. This is to prevent routing loops from occurring. Split Horizon is enabled by default on all interfaces except Frame Relay interfaces where the IP address is configured on the physical interface. You can turn off Split Horizon on an interface by issuing the <b>no ip split-horizon</b> command under an interface:<br /><br />interface FastEthernet0/0<br />no ip split-horizon<br /><br />Interestingly there is a special case where Split Horizon is overridden and that is called <b>Poison Reverse</b>. This is where a router receives an update on an interface specifying that a route is down, as indicated by a hop count of 16 (known as <b>route poisoning</b>), and the receiving router sends that update back out of the same interface. If you run a debug on RIP (debug ip rip) you will see Poison Reverse in action with a line of:<br /><br />RIP: sending v2 flash update to 224.0.0.9<br /><br />These flash updates are also seen in triggered updates.<br /><br /><b><u>Authentication</u></b><br /><br />RIPv2 allows for passwords to be exchanged between RIP routers to secure updates and stop rogue RIP routers from being deployed in a network and disrupting it.<br /><br />By default, RIP passwords are sent in plain-text but you can configure it to use MD5 which I would highly recommend if your network is susceptible to eavesdropping. In fact I would do it as a matter of course. As you would expect, the <span style="font-weight: bold;">passwords on both sides must match</span> in order for the RIP updates to be successfully exchanged.<br /><br />You configure the passwords in global configuration mode using <b>key-chains</b> which are made up of <b>keys</b> which in turn have the password configured on them with optional send and receive lifetimes. Let's configure a basic key-chain (more advanced configuration can be seen <a href="http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_ip_prot_indep.html#wp1056961">here</a>):<br /><br />key-chain MyKeyChain<br />key 1<br /> key MyPassword<br /><br />To turn RIP authentication on you must configure it under the interface which will be sending the updates:<br /><br />int fa0/0<br />ip rip authentication key-chain [key-chain-name]<br /><br />So for my example it would be:<br /><br />int fa0/0<br />ip rip authentication key-chain MyKeyChain<br /><br />If you want to send your passwords in plain-text that is all there is to it as you remember RIP defaults to using plain-text passwords. You can specifically tell RIP to send passwords as plain-text by issuing the <b>ip rip authentication mode text</b> command under your outgoing interface as in:<br /><br />int fa0/0<br />ip rip authentication mode text<br />ip rip authentication key-chain MyKeyChain<br /><br />If you want to use MD5 instead then guess what one word needs to change in the example above? Yes, you've got it, replace the word "text" with "md5" as in:<br /><br />int fa0/0<br />ip rip authentication mode md5<br />ip rip authentication key-chain MyKeyChain<br /><br />Remember you have to explicitly set the authentication mode to MD5 as RIP defaults to using plain-text passwords.<br /><br /><b><u>Changing the next-hop router</b></u><br /><br />Did you know that a RIP router can send updates about a route and change the next-hop router? As you would imagine, if a router, say R1, was to learn a route from R2, R1 would use R2 as the next-hop. R2, however, could conceivably change the next-hop from itself to another router.<br /><br />In RIPv2, each RIP entry includes a space where an explicit IP address can be entered as the next hop router for datagrams intended for the network in that entry. This feature can help improve efficiency of routing by eliminating unnecessary extra hops for packets sent to certain destinations.<br /><br />One common use of this field is when the most efficient route to a network is through a router that is not running RIP. Such a router will not exchange RIP messages and would therefore not normally be selected by RIP routers as a next hop for any network. The explicit Next Hop field allows the router to be selected as the next hop regardless of this situation.<br /><br />The Next-Hop field is changed by using route-maps.<br /><br /><b><u>Using Offset Lists to change RIP's metric for a particular route</u></b><br /><br />You change the metric received or advertised in RIP by using an offset-list. This is very similar in configuration to distribute-lists where you reference an access-list. The access-list will be checked against sent or received updates and the specified offset added to the metric. The basic syntax is:<br /><br />offset-list [access-list-number_or_access-list-name] [in | out] [specified-offset] [interface]<br /><br />Let's look at an example:<br /><br />R1 has a route for 192.168.1.0/24 with a hop count of 0 as it is directly connected. We want to advertise that route to R2 with a hop count of 2. Remember that a RIP router will advertise out its hop count + 1 to other RIP routers so R2 would ordinarily receive a hop count of 1 to reach 192.168.1.0/24 via R1. Let's configure our offset-list:<br /><br />access-list 1 permit 192.168.1.0 0.0.0.255<br /><br />router rip<br />offset-list 1 out 1 FastEthernet0/0 <br /><br />Here <b>offset-list 1</b> specifies ACL 1 which will match 192.168.1.0/24. This is applied outbound as specified by <b>out</b>. We add 1 to the metric of all routes matched by our access-list as specified by the <b>1</b> after the <b>out</b> keyword. Finally we specify the interface out of which our offset-list is applied. <br /><br /><b><u>Clearing RIP routes from the routing table to speed up convergence</u></b><u></u><br /><br />As RIP has no concept of neighbours you can simply issue the <b>clear ip route *</b> command from privileged mode. This will clear out all routes and cause the router to send out RIP request packets. This wouldn't work with a routing protocol that has neighbours such as EIGRP as the routes are promoted to the routing table from the topology table. In that case you would have to tear down the neighbour adjacency.<br /><br /><b><u>Conclusion</u></b><br /><br />I've tried to be as brief as possible as I don't see the point of reinventing the wheel as there are so many quality papers on RIP. I hope I've got enough detail in here for you to understand the basic operation of RIP and some of the extras that can be configured.<br /><br />As always, if you have any questions about this topic please feel free to leave a comment and/or email me using the Contact Me tab at the top of the screen.<br /><br />Good luck with your studies!Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-6240379334240712627.post-81288468676837593722009-06-07T18:07:00.004+01:002009-06-08T13:09:25.109+01:00Route Maps and Access-ListsI received an email from one of the readers, Joel, who is getting confused as to how access-lists and route-maps work together. I have therefore created this topic to cover the very basics of access-lists and how they link into route-maps. In turn I have expanded the lesson on route-maps to cover a little more of the nuances of route-map theory as well as an aid to other readers.<br /><br />Access-lists contain very simple logic. Lists 1-99 (standard access-lists) will permit or deny all IP traffic from a particular source whereas access-lists 101-199 (extended access-lists) extend this functionality allowing you to permit/deny with more granularity, for example, specifying both source and destination address, Layer 4 protocols and port number (i.e. TCP/UDP), and Layer 3 protocols other than IP (i.e. ICMP).<br /><br /><span style="font-weight:bold;">The syntax for standard access-lists is as follows:</span><br /><br />"I wish to permit all IP traffic from host [host-ip-address]"<br />"I wish to permit all traffic from [subnet] [wildcard-mask]" <br />"I wish to deny all IP traffic from host [host-ip-address]"<br />"I wish to deny all traffic from [subnet] [wildcard-mask]"<br /><br />An example is you want to allow all IP traffic from 192.168.1.0/24. The access-list is simple:<br /><br />access-list [1-99] permit 192.168.1.0 0.0.0.255<br /><br /><span style="font-weight:bold;">The syntax for extended access-lists is slightly different:</span><br /><br />"I wish to [permit/deny] [type-of-traffic] going from [source-address] [source-wildcard-mask] to [destination-address] [destination-wildcard-mask] [optional port-number]"<br /><br />Let's say you would like to permit all Telnet traffic going from 192.168.1.0/24 to a device at 192.168.2.1.<br /><br />Telnet uses TCP port 23 and here is how you would write the extended access-list:<br /><br />"access-list [101-199] permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23"<br /><br />In English, this access-list permits TCP from 192.168.1.0/24 to the host whose address is 192.168.2.1 where the TCP port number is 23.<br /><br /><b><u>How to apply access-lists to route-maps</b></u><br /><br />Believe me there is nothing tricky about doing this. A route-map is a way of influencing the routing decision made by a routing device. The basic syntax of a route-map is as follows:<br /><br />route-map [route-map-name] [permit/deny] [sequence-number]<br />match [condition]<br />set [what-you-want-to-do-with-the-packet-if-it-matches-the-match-criteria]<br /><br />As you build up your route-map you simply increase the sequence number for each match you want to do. Once you have created your route-map you must then apply it to a router interface e.g.<br /><br />int fa0/0<br />ip policy route-map [route-map-name] [in/out]<br /><br />Let's step back up to the match criteria. There are a number of things that we can match on but what we will focus on is how we can influence traffic flows through a router. We do this by using the <span style="font-weight:bold;">match ip address [access-list-number]</span> command. The extended access-list in my earlier example called for allowing Telnet traffic from 192.168.1.0/24 to be able to reach host 192.168.2.1. Let's take that example a bit further and say that we want to make all Telnet traffic going from 192.168.1.0/24 to host 192.168.2.1 which has entered my router's fa0/0 interface to leave my router's Serial0/0 interface. We could use that access-list and apply it to our route-map (I've called it MYMAP):<br /><br />access-list 101 permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23<br /><br />route-map MYMAP permit 10<br />match ip address 101 <---this line refers to access-list 101<br />set interface Serial0/0<br /><br />int fa0/0<br />ip policy route-map MYMAP in <---applies the MYMAP route-map inbound on fa0/0<br /><br /><b><u>How does the router service the route-map?</b></u> <br /><br />Actually it is very logical. The router starts at the lowest sequence number until it finds a match. <br /><br />So let's run through it. A host at 192.168.1.1 tries to Telnet to 192.168.2.1 and the packet is received on fa0/0 of our router. Our router, looking at fa0/0, realises that policy-based routing is required and that it should look at the route-map named MYMAP in order to make a decision on how to forward the traffic. The router starts at the lowest sequence number in the route-map and checks the match criteria. The example above tells the router to check access-list 101. The packet received matches access-list 101 so the router returns to the route-map and checks what the set command tells it to do. The set command tells it to forward this traffic out of Serial0/0<br /><br /><b><u>What if there is no match found?</b></u><br /><br />If there is no match then the router will route the packet based on the contents of the routing table. If a host at 192.168.3.1 tried to Telnet to 192.168.2.1 and the packet is received through fa0/0 of our router, the router will look into MYMAP, then at access-list 101, realise that access-list 101 does not match 192.168.3.1 as a source address and will return to the route-map looking for the next highest sequence number. In our example there is not another sequence number so the router will simply forward the traffic based upon the contents of its routing table (i.e. what it would do if there was no route-map applied to the fa0/0 interface). <br /><br /><b><u>How could we use route-maps to drop traffic?</b></u> <br /><br />Chris, you've just told us that if no match is found then the packet will be forwarded by the contents of the routing table so how can I influence that? <br />Generally, you would drop traffic on an interface using an access-list applied directly to the interface, however, it can be done using a route-map. Let's say you want to have control over all traffic coming in on fa0/0 of our router and want to drop anything that doesn't match our defined criteria. Let's say I have created access-lists 101-105 which specifies my criteria. My route-map would look as follows:<br /><br />route-map MYMAP permit 10<br />match ip address 101 <---this line refers to access-list 101<br />set interface Serial0/0<br />route-map MYMAP permit 20<br />match ip address 102 <---this line refers to access-list 102<br />set interface Serial0/1<br />route-map MYMAP permit 30<br />match ip address 103 <---this line refers to access-list 103<br />set interface Serial0/2<br />route-map MYMAP permit 40<br />match ip address 104 <---this line refers to access-list 104<br />set interface Serial0/3<br />route-map MYMAP permit 50<br />match ip address 105 <---this line refers to access-list 105<br />set interface Serial0/4<br /><br />Now I want to deny everything else. Remember the Null0 interface, what I like to call Packet Heaven (as that is where packets that need to be dropped/die go)? Check this route-map statement out:<br /><br />route-map MYMAP permit 60 <br />set interface Null0<br /><br />Whoa Chris! What did you do there? Where has the match statement gone? The beauty is you don't need it. Sure, you could configure an access-list (e.g. access-list 106 permit ip any any) and have:<br /><br />route-map MYMAP permit 60<br />match ip address 106 <br />set interface Null0<br /><br />But there really is no need. If the route-map evaluation has got this far we are just saying "drop everything else, send it to Packet Heaven, Null0". By removing the match statement you are in effect creating a <span style="font-weight:bold;">catch-all</span> statement. Equally, you may have wanted all traffic not matching access-lists 101-105 to be routed out of Serial0/5 rather than be routed using the routing table or dropped. Your last route-map clause would have been:<br /><br />route-map MYMAP permit 60<br />set interface Serial0/5 <-- all traffic not previously matched will go via Serial0/5<br /><br /><b><u>Other Key Points About Route-Maps</b></u><br /><br />1. The route map statements can also be marked with a deny. If the statement is marked as a deny, the packets meeting the match criteria are sent back through the normal forwarding channels (in other words, destination-based routing is performed). Only if the statement is marked as permit and the packets meet the match criteria are all the set clauses applied. If the statement is marked as permit and the packets do not meet the match criteria, then those packets are also forwarded through the normal routing channel.<br /><br />2. There can be multiple match criteria on the same line where only ONE of the criteria has to match. There can be multiple match statements on different lines where ALL match statements must match. I think an example here is in order:<br /><br />route-map MYMAP permit 10<br />match ip address 101 102 103 104<br />match ip address 105<br />set interface Serial0/0<br /><br />The logic here works thus:<br /><br />match ip address 101 OR 102 OR 103 OR 104<br />AND<br />match ip address 105<br /><br />So a packet comes in and matches access-list 104, the router then goes on to check access-list 105. If the received packet also matches access-list 105 then the set command is used. If the packet had failed to match access-list 105 then the next statement in the route-map would be evaluated or the packet would be forwarded normally. <br /><br />3. There are other match criteria such as packet length but I'll focus on the other set criteria. <br /><br /><span style="font-weight:bold;">set ip next-hop</span> [next-hop-ip-address] - specifies where to send the packet. Preferable to use this rather than exit interface.<br /><br /><span style="font-weight:bold;">set default interface</span> [interface] - If there is no entry in the routing table for the destination of this packet route it through the specified interface<br /><br /><span style="font-weight:bold;">set default ip next-hop</span> [next-hop-ip-address] - if there is no entry in the routing table for the destination of this packet route it via the specified next-hop<br /><br />Notice the use of the "default". This is only true if there is no corresponding entry in the routing table.<br /><br />4. Like match statements, you can have multiple set statements too. Again, an example will help illustrate this.<br /><br />route-map MYMAP permit 10<br />match ip address 101<br />set interface Serial0/0 Serial0/1 <br /><br />By default any matches to access-list 101 will exit Serial0/0 but if that fails Serial0/1 will be used as the exit interface.<br /><br /><b><u>Conclusion</u></b><br /><br />Like everything, route-maps are easy once you understand how the syntax works. Any questions or feedback please feel free to leave comments and/or email me using the Contact Me tab at the top of the screen. Good luck to you all in your studies!Unknownnoreply@blogger.com16tag:blogger.com,1999:blog-6240379334240712627.post-60071960236009240552008-12-15T11:23:00.002+00:002008-12-15T14:14:40.840+00:00Vyatta on VM WorkstationHere's the deal. How do you fill your work time looking busy but having a bit of fun? Simple. Look out for emerging technologies and tell your department you want to "innovate" with Product X. So here I am, looking at Vyatta. Bold claims from these guys but is it as good as they say? Well I'm not here to run the mathematical experiments. What I want to know is "Is it easy to use?" and "Can I use it in one of our projects?". It's early days to be answering the latter but I may be able to answer the former over a series of posts.<br /><br />What I want to do is set up a dummy network in VM Workstation to simulate a square with a Vyatta router at each corner like so: <br /><br />Vyatta Instance 1 --> Vyatta Instance 2<br />Vyatta Instance 1 --> Vyatta Instance 3<br />Vyatta Instance 2 --> Vyatta Instance 4<br />Vyatta Instance 3 --> Vyatta Instance 4<br /><br />I really am a noob to VM Workstation but after a little playing around I got it to work.<br /><br />Taking the above connections I used the Custom Network Connections for each (I believe VMNet0 and VMNet1 are reserved):<br /><br />Vyatta Instance 1 --> Vyatta Instance 2 = VMNet2<br />Vyatta Instance 1 --> Vyatta Instance 3 = VMNet3<br />Vyatta Instance 2 --> Vyatta Instance 4 = VMNet4<br />Vyatta Instance 3 --> Vyatta Instance 4 = VMNet5<br /><br />By default each virtual machine in VM Workstation has one Network Connection set up (usually NAT). Modify this to a custom connection and from the drop-down list choose the appropriate VMNet. To add a new Network Adapter simply click Add in the Virtual Machine Settings and choose Network Adapter then select Custom and choose the desired VMNet connection. For my example above I modified the first Network Adapter on Vyatta Instance 1 to VMNet2 and created a new Network Adapter in VMNet3. I done similar on the other three instances and lo-and-behold everything was connected.<br /><br />Here's my basic settings:<br /><br />Vyatta Instance 1:<br /><br />configure<br />set system host-name Vyatta-Instance-1<br />set interfaces ethernet eth0 description Link_To_Vyatta_Instance_2<br />set interfaces ethernet eth0 address 192.168.2.1/24<br />set interfaces ethernet eth1 description Link_To_Vyatta_Instance_3<br />set interfaces ethernet eth1 address 192.168.3.1/24<br />commit<br />save<br /><br />Vyatta Instance 2:<br /><br />configure<br />set system host-name Vyatta-Instance-2<br />set interfaces ethernet eth0 description Link_To_Vyatta_Instance_1<br />set interfaces ethernet eth0 address 192.168.2.2/24<br />set interfaces ethernet eth1 description Link_To_Vyatta_Instance_4<br />set interfaces ethernet eth1 address 192.168.4.1/24<br />commit<br /><br />Vyatta Instance 3:<br /><br />configure<br />set system host-name Vyatta-Instance-3<br />set interfaces ethernet eth0 description Link_To_Vyatta_Instance_1<br />set interfaces ethernet eth0 address 192.168.3.2/24<br />set interfaces ethernet eth1 description Link_To_Vyatta_Instance_4<br />set interfaces ethernet eth1 address 192.168.5.1/24<br />commit<br /><br />Vyatta Instance 4:<br /><br />configure<br />set system host-name Vyatta-Instance-4<br />set interfaces ethernet eth0 description Link_To_Vyatta_Instance_2<br />set interfaces ethernet eth0 address 192.168.4.2/24<br />set interfaces ethernet eth1 description Link_To_Vyatta_Instance_3<br />set interfaces ethernet eth1 address 192.168.5.2/24<br />commit<br /><br />This is probably more for my reference but to undo anything use the "delete" command. For example if I accidentally put an IP address under eth0 for example I could use the following;<br /><br />delete interfaces ethernet eth0 address 192.168.3.1/24<br /><br />Now I've decided to run RIP just to see how easy it is.<br /><br />Vyatta Instance 1<br /><br />configure<br />set protocols rip network 192.168.2.0/24<br />set protocols rip network 192.168.3.0/24<br />commit<br />save<br /><br />Vyatta Instance 2<br /><br />configure<br />set protocols rip network 192.168.2.0/24<br />set protocols rip network 192.168.4.0/24<br />commit<br />save<br /><br />Vyatta Instance 3<br /><br />configure<br />set protocols rip network 192.168.3.0/24<br />set protocols rip network 192.168.5.0/24<br />commit<br />save<br /><br />Vyatta Instance 4<br /><br />configure<br />set protocols rip network 192.168.4.0/24<br />set protocols rip network 192.168.5.0/24<br />commit<br />save<br /><br />To shut down an interface:<br /><br />set interfaces ethernet eth0 disable<br /><br />To bring it back up:<br /><br />delete interfaces ethernet eth0 disable<br /><br />It all seems easy so far.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-6240379334240712627.post-73988972805908512812008-12-04T13:36:00.007+00:002008-12-04T14:47:39.648+00:00GNS3 Configuration Guide - Linux (Fedora 9)I've been hearing how much better Linux is to Windows from guys across the world so I thought I would install FC9 on my home computer and promptly destroyed Windows XP. What a blessing in disguise! Now I've made the leap of faith I am one happy man although still a little green to the world of Linux.<br /><br />Let's get to installing GNS3, VPCS, loopback adapter equivalent bridge interfaces etc. I'm going to do this without pictures as for the majority of the case it is exactly the same as the Windows installation. It is just the initial installation and dependencies that are required. <br /><br />Note to purists: I am a Linux noob so if my terminology is out then I apologise.<br /><br />Note the use of sudo here. If you haven't set it up then you can log in as root and repeat the command (without the "sudo" prefix).<br /><br />1. Install PyQt4 <br /><br />Fedora = sudo yum -y install PyQt4<br /><br />Ubuntu = sudo apt-get install PyQt4<br /><br />This should install all dependencies needed for GNS3 including SIP. <br /><br />2. Install tunctl and bridge-utils e.g. sudo yum -y install tunctl bridge-utils<br /><br />This will now allow you to create bridged interfaces equivalent to Microsoft Loopback Adapters.<br /><br />3. Download GNS3 from <a href="http://www.gns3.net/download">here</a>. I tend to go for the tgz file.<br /><br />4. Download Dynamips from the same location under the heading Associated Software. I run 32-bit only so I download the Dynamips 0.2.8-RC2 binary for Linux x86 platforms<br /><br />5. Right-click the downloaded GNS3 file and choose Extract Here. Drag the Dynamips file downloaded in Step 4 to the extracted folder. Now right-click the Dynamips file and select the Permissions tab and ensure the "Allow executing file as program" box is ticked, then click Close.<br /><br />6. Now double-click the gns3 file and choose Run. Assuming that all dependencies have been installed you should see GNS3 start with the screenshot in Step 3 of my <a href="http://subnettingmadeeasy.blogspot.com/2007/12/gns-configuration-guide.html">GNS3 Windows guide</a>. Follow the majority of that to set up the images and working directories plus the idlepc value.<br /><br />So hopefully now you should be able to muck around with GNS3 and do most of what you need to do. However, I had one main issue and that was how do I connect my router to my local machine so that I could run syslog servers, iperf, and other apps like we do using the Loopback Adapter in Windows? Well I have to pay my respects to tuner_x at the <a href="http://www.sadikhov.com/forum">Sadikhov IT forums</a> for the guide on how to do this. You must run GNS3 as root in order to achieve this so for example I run:<br /><br />sudo ./Chris/Desktop/GNS3-0.5-src/gns3<br /><br />NOTE: If Dynamips doesn't start (you'll probably notice that you cannot connect to a hypervisor on 7200 when dragging a router onto the stage) as root then you need to either clean the working directory as it points to your user account or point the working directory to a new location.<br /><br />1. If you didn't do this before you need to install tunctl and bridge-utils as outlined in Step 2 of the initial configuration guide above.<br /><br />2. Now add the following to the script below so each time you switch on your PC the bridge interfaces are created.<br /><br />sudo vi /etc/rc5.d/S99local<br /><br />Now insert the following (note that there is no particular naming convention, just what I chose to do) and save:<br /><br /># Script to create bridge interfaces. Requires tunctl and bridge-utils to be<br /># installed.<br />#<br /># This creates the interfaces. -t names the interface and -u sets the owner of<br /># of the interface.<br /><br />/usr/sbin/tunctl -t fed_0 -u Chris<br />/usr/sbin/tunctl -t fed_1 -u Chris<br />/usr/sbin/tunctl -t gns3_0 -u Chris<br />/usr/sbin/tunctl -t gns3_1 -u Chris<br /><br /># Then bring the interfaces up<br /><br />/sbin/ifconfig fed_0 up<br />/sbin/ifconfig fed_1 up<br />/sbin/ifconfig gns3_0 up<br />/sbin/ifconfig gns3_1 up<br /><br /># Now create the bridge interface<br /><br />/usr/sbin/brctl addbr gns3_br0<br />/usr/sbin/brctl addbr gns3_br1<br /><br /># Bring the bridge interfaces up<br />/sbin/ifconfig gns3_br0 up<br />/sbin/ifconfig gns3_br1 up<br /><br /># Add the tap interfaces to the bridge interfaces<br />/usr/sbin/brctl addif gns3_br0 fed_0<br />/usr/sbin/brctl addif gns3_br0 gns3_0<br /><br />/usr/sbin/brctl addif gns3_br1 fed_1<br />/usr/sbin/brctl addif gns3_br1 gns3_1<br /><br /># Here is an example of how to assign an IP address to the gns3_br0 interface so one<br /># can ping from a GNS3 router to the local machine in order to run syslog etc<br />#<br /># ifconfig gns3_br0 inet 192.168.2.254 netmask 255.255.255.0 up<br />#<br /># I do this manually and not via the script but keep it here for reference only.<br /># And that's it<br /><br />Now you could choose to reboot or restart the appropriate services. I tend to restart the services as it is quicker than rebooting.<br /><br />sudo /etc/rc5.d/S99local restart<br />sudo /etc/init.d/network restart<br /><br />Now add an IP address to one of your gns3 bridge interfaces. Here I am using the first:<br /><br />sudo ifconfig gns3_br0 inet 192.168.2.254 netmask 255.255.255.0 up<br /><br />NOTE: Do not use the same IP address as your main ISP router otherwise you'll knock out your Internet connection. D'oh! Always learn the hard way don't you Chris? LOL.<br /><br />Go into GNS3 and drag a cloud, or a customised symbol, onto the stage and right-click and choose Configure. Select the "NIO TAP" tab and type the name of your bridge interface (e.g. gns3_br0) then click Add, Apply, then OK. <br /><br />Hook your router up to the cloud, start the IOS, console into your router, and put the interface into the same subnet as your bridge interface. Bring the interface up and lo-and-behold you should have connectivity between your PC and your router.<br /><br />What about multiple hosts? You can still use VPCS as explained in my <a href="http://subnettingmadeeasy.blogspot.com/2008/06/adding-hostspcs-to-gns3-vpcs.html">VPCS Configuration Guide for Windows</a> although there is a slightly different way to run it. <br /><br />1. Once you have downloaded the file, extract it to your GNS3 folder. <br /><br />2. Now open the extracted folder and locate the "vpcs" file (NOT vpcs.exe). <br /><br />3. Right-click the vpcs file and choose the Permissions tab and tick the box next to "Execute".<br /><br />4. Go to the desktop and right-click and choose Create Launcher.<br /><br />5. Type = Application in Terminal<br /><br />6. Name = VPCS<br /><br />7. Command = the path to the vpcs file located in Step 2.<br /><br />8. Comment = Virtual PCs<br /><br />9. Click OK to create the launcher<br /><br />10. Drag the launcher into the VPCS folder.<br /><br />When you want to run VPCS just double-click on the created launcher. The configuration works just as it does in Windows.<br /><br />That's it. FC9 running GNS3 exactly as I had it on Windows. <br /><br />I hope it helps you Linux noobs to run GNS3.<br /><br />ChrisUnknownnoreply@blogger.com3