INE Workbook Vol 1 EIGRP

Another day, another section to study!

I haven't picked up too much from the eigrp section. This tells me I'm pretty well versed in EIGRP. I did pick up a few tips:

When configuring an interface level summary address, you can assign a distance of 255 to the summary. This will prevent the installation of the null route (thus preventing blackhole activity of summary component subnets) but will still advertise the summary.

interface fastethernet0/0
ip summary-address eigrp 100 150.1.4.0 255.255.252.0 255

I received another scenario where I needed to prefer one route over the other. Ok, no problem I can alter the bandwidth or delay metric to make that happen. So I view the EIGRP topology table for that subnet. Uh-oh, there is only one route available. I immediately thought there was something wrong with my topology or something else going on. That was not the case. The problem was a downstream router only advertises a candidate that meets the Feasibility condition and since split-horizon is enabled on the link, the route will not advertise back upstream. Now if I alter the metrics so the downstream router prefers the path that I want, I will achieve the desired solution.  Well, I hope that makes sense! It was a good scenario and shows you the process of EIGRP.

I've learned that because of the feasibility condition, you will not see all available routes, only those that meet the condition so you need to go step by step throughout the topology, and comparing the metrics. To make this easier, INE changed the metrics to only delay so to calculate a metric would simply be the sum of delay * 256. Once you step through the topology and view the metrics, you will see how you can get alternate paths into EIGRP. Very good scenario. Next, you need to balance the traffic by 5 to 1. Wow. This was a tough one and one that I will have to read and re-read again....I don't get where INE get's their math from. After some time, I finally figured it out. I am going to attempt to explain it here below, and then I am calling it a night!

From Cisco's whitepaper [http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#loadbalancing]

"How does the router divide the traffic between these paths? It divides the metric through each path into the largest metric, rounds down to the nearest integer, and uses this number as the traffic share count."


So look at your two available routes in your routing table.



R6(config-subif)#do sh ip route 155.1.9.9
Routing entry for 155.1.9.0/24
  Known via "eigrp 100", distance 90, metric 7680, type internal
  Redistributing via eigrp 100, eigrp 10
  Advertised by eigrp 10 metric 1 1 1 1 1
  Last update from 155.1.146.1 on FastEthernet0/0.146, 00:00:11 ago
  Routing Descriptor Blocks:
    155.1.146.1, from 155.1.146.1, 00:00:11 ago, via FastEthernet0/0.146
      Route metric is 8192, traffic share count is 15
      Total delay is 320 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 4
  * 155.1.67.7, from 155.1.67.7, 00:00:11 ago, via FastEthernet0/0.67
      Route metric is 7680, traffic share count is 16
      Total delay is 300 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2


To get a traffic share count of 5 to 1, your composite metric must be 5 times that of your best route. So from above, we need 5 times 76800 or 38400. Ok, here are the delay of our links.


R6 (100) -> SW1 (100) -> SW3 (100) = 300usec which is 30msec * 256 = 7680.
R6 (100) -> R1 (10) -> R3 (10) -> SW1 (100) -> SW3 (100) = 320usec/32msec * 256 = 8192


Ok, hopefully everyone is still with me. We need a metric of 38400. Let's get back to delay numbers so divide by 256 = 150msec of 1500usec. We can change the delay anywhere or everywhere along the path (provided we still meet feasibility condition) but to make it simple, just change one link! We will change R6 as listed above. So subtract the delays from the other links you are not changing and that will give you your delay number for R6.


1500 - SW3 (100) = 1400
1400 - SW1 (100) = 1300
1300 - R3 (10) = 1290
1290 - R1 (10) = 1280


1280usec is what we need on R6, but remember, you configure delay on the interface in msec, so 1280 becomes 128.


R6 (config)# interface f0/0.146
R6(config-subif)#delay 128


Now give EIGRP a few seconds to re-compute and tada!!



R6(config-subif)#do sh ip route 155.1.9.9
Routing entry for 155.1.9.0/24
  Known via "eigrp 100", distance 90, metric 7680, type internal
  Redistributing via eigrp 100, eigrp 10
  Advertised by eigrp 10 metric 1 1 1 1 1
  Last update from 155.1.146.1 on FastEthernet0/0.146, 00:00:00 ago
  Routing Descriptor Blocks:
    155.1.146.1, from 155.1.146.1, 00:00:00 ago, via FastEthernet0/0.146
      Route metric is 38400, traffic share count is 1
      Total delay is 1500 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 4
  * 155.1.67.7, from 155.1.67.7, 00:00:00 ago, via FastEthernet0/0.67
      Route metric is 7680, traffic share count is 5
      Total delay is 300 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

Wow, I really hope that helps someone because for me, it took forever to digest this and figure it out. It didn't help that INE's solution was confusing as all hell to me. I am going to call it a night and resume EIGRP tomorrow.

INE Workbook Vol 1 RIP

Starting on RIP today. So many people forget about RIP and don't think it's a big deal, but I've seen many scenarios where RIP and it's nuances can really get you. So never forget anything, cover the entire blueprint!!

During task 1, I just blindly enabled RIP across all my routers. This is fine, but I need to change my mindset to immediately think of what problems I may encounter with RIP within my topology, especially items such as split-horizon and authentication with backbone routers. Also, an easy way to check your MD5/text password is to do "show key chain" which will place your configured passwords in quotations. This way, if there is a trailing space messing up your authentication, you will now see it!

This isn't new to me, but 'show ip interface s0/0' will show split-horizon behavior...


R5(config)#do sh ip int s0/0
Serial0/0 is up, line protocol is up
  Internet address is 155.1.0.5/24
  Broadcast address is 255.255.255.255
  Address determined by non-volatile memory
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.9
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is disabled
  ......


To disable split horizon...



R5(config)#int s0/0

R5(config-if)#no ip split-horizon

When changing RIP timers, you can change the hello timer on an interface basis (say for another RIP domain or BB routers)..

router rip

timers basic 10 60 60 80

int f0/0

ip rip advertise 30

You can use a '0' access list with offset-list. This will simply permit all prefixes to be offset.

router rip
offset-list 0 out 5 f0/0.146


INE presented an interesting scenario where a rip summary is configured on R4, advertised to it's neighbor R5 with split-horizon disabled, bounced back to R4, which then installs it's own summary pointing to R5. Wow, that was kind of crazy. The solution was to install a null route on R4 which was generating the summary. Other routing protocols already do this. You could also do offset-list/distribute lists to prevent the summary from be advertised back to itself. This would be something to keep an eye out for on the lab exam!


One thing that always trips me up is using an extended ACL to filter routes in RIP. I can always put it together that I need to you a distribute-list, but I always forget..network routes or host routes? Crap. Here is the config to filter VLAN 7 and 9 from R3 and filter VLAN146 and R1 Lo0 from R1.


router rip
distribute-list 100 in s0/0
!

access-list 100 deny ip host 155.1.0.3 host 155.1.7.0
access-list 100 deny ip host 155.1.0.3 host 155.1.9.0
access-list 100 deny ip host 155.1.0.1 host 155.1.146.0
access-list 100 deny ip host 155.1.0.1 host 150.1.1.0
access-list 100 permit ip any

So you match the route source (or gateway) first using a host statement, and then you match the route subnet address with another host statement.


I had another task that asks to use an offset-list to filter a route for VLAN5 from SW1 to SW3 which are connected via VLAN79. Ok, simple enough. I do a 'sh ip rip database' on SW3 to see the hop count SW3 is receiving for vlan 5.



155.1.5.0/24
    [3] via 155.1.79.7, 00:00:03, Vlan79

Ok, now to configure this on SW1.

access-list 1 permit 155.1.5.0 0.0.0.255
router rip
offset-list 1 out 13 vl79


In essence, SW1 receive 155.1.5.0/24 with a hop count of two, so when I add 13 to two on the advertisement out of SW1, I will advertise this to SW3 with a hop count of 16. When SW3 goes to add this to it's routing table, it will find the route inaccessible and will not install the route. This is where I prefer Narbik over INE. Their solution was like this:


router rip
offset-list 1 out 16 vlan79
!
access-list 1 permit 155.1.5.0


Does that work? Sure it does! If you advertise anything out with a metric of 16 it will be poisoned. Narbik's point is that you need to really understand the protocol and what is going on. And in the end, if a proctor hand-grades your lab, and see something very specific such as that, it may make the difference between pass or fail.

Another good scenario was showing how the distance command can affect routing within the RIP domain. If you blackhole a route (distance 255), RIP cannot advertise a route that it does not have in it's domain. This is similar to EIGRP.

Be aware that when you advertise a default route out only one interface (route map set-interface command) that default route can make it's way back to the originating router in on another interface. This will loop around the network, incrementing along the way until it is unreachable. This is similar to the summary issue above. If you advertise out all interfaces, this will never happen because of split horizon. Otherwise you can do the usual static null route or distribute list to curb this activity.

I don't have many other notes from RIP. One thing I did come across was IPCP. You can use PPP to assign IP addresses. Use 'peer default ip add x.x.x.x' on one side, and 'ip address negotiated' on the other side.This affects RIP because the two links negotiate a host route and are no longer considered on the same network. So you would need to enable 'no validate update-source' within the RIP process to get them talking.

Well, that is it for now. I am enjoying the INE workbook so far. I like the very thorough step-by-step process and validating using debugs. As a result, I am finding myself using debugging more and more. I am hoping to study some more tomorrow, and then I have a CCIE study group I will be joining later in the evening. As always, if you have any questions, feel free to post them.

Optimized Edge Routing/Performance Routing

In a nutshell, Optimized Edge Routing(OER)/Performance Routing(PfR) enables dynamic routing of traffic into or out of an enterprise based on various metrics including interface counters, throughput, delay, etc. I find it interesting Cisco wants to now call it PfR but all of the IOS commands are still OER....and this folks, is why IOS can be confusing as all hell. 

OER has five phases, Profile Phase, Measure Phase, Apply Policy Phase, Control Phase and Verify Phase. OER deployments include a Master Controller (MC) and the Border Routers (BR). 95% of your configuration happens on the MC. The BR reports metrics to the MC, which processes the statistics and enforces the policies at the BR. At least one external interface must be present on each BR and a group of BRs should have at least two external interfaces.

During the Profile Phase, traffic is discovered , OER learns traffic flows that experience issues automatically. You can also configure traffic classes manually. 

During OER measure phase, measurements can be passive or active. Passive measurements include items such as interface counters and netflow data. Active measurements include border routers simulating traffic using IP SLA to discover performance characteristics. 

In setting up OER, a very important and sometimes forgetten task is to setup a local interface on the border routers that communicate with the master. In most labs I see, the MC and BR within OER are setup with the loopback addresses. This obviously make's things easier. Also, when setting up the internal/external interfaces, all interfaces are defined.

oer master

border 150.1.4.4 key oer

interface f0/0 external

interface s0/0.1 internal

interface s1/2 internal

To setup a BR...

oer border

master 150.1.5.5 key oer

local lo0

To enable automatic learning of the prefix traffic classes using netflow, issue the following on the MC:

oer master

learn

throughput

The number of learned flows could exceed the MTC capacity. This is why prefix aggregation is enabled by default (/24) and resulting metrics are summarized or averaged. You can also use BGP aggregation, non-bgp (static routes) and manually configured prefix-length.

To configure a prefix traffic class, first create a prefix-list matching the prefix.

ip prefix-list OER permit 112.0.0.0/24

Then, create an oer map.

oer-map OER 10

match ip add prefix OER

You can also 'set' policies/monitoring within the OER map.

Then apply the oer map to the master.

oer master

policy-rules OER

To enable specific protocols/ports, simply use the 'protocol' keyword from within the MC Learn prompt.

oer master

learn

protocol tcp port 80 src

To test your OER deployment, you can utilize IP SLA, and this is where my dynamips problems started. You may experience some latency and dropped pings so make sure you set your frequency and timeouts appropriately. Also, to test file transfers, make sure your routers have enough disk space (disk0=256 in Dynagen .net configuration file). I wasn't able to transfer an IOS image to my routers so instead I used a very large text file. I used a Terminal Server with an ethernet interface pointed to a loopback adapter on my PC to send the text file to the router's flash.

I'm not going to cover the Apply, Control and Verify phases. I had way too many problems using dynamips on my work laptop and spent way too much time troubleshooting instead of labbing. I did make it through the lab. This is my third time through an OER lab and I am feeling pretty comfortable.

If anyone has any specific questions regarding OER, I would be happy to hear them. I will try to answer them intelligently. 

INE Workbook Vol 1 IP Routing part 2

I'm going to skip a fancy intro and just get to the nitty-gritty details.....

You can handle recursive GRE routing lookups using distribute-list on the routing protocol or static routes with lower AD.You would need to filter the destinations for the GRE tunnel out through the distribute list. So say on router 1...

int tunnel1
tunnel source lo0
tunnel dest 150.1.4.4
!
router rip
distribute-list prefix R4 out
!
ip prefix-list R4 deny 150.1.4.0/24
ip prefix-list R4 permit 0.0.0.0/0 le 32


You would obviously need to repeat this on the opposite end of the tunnel interface. Even easier, you can add static routes (with a lower AD) and the tunnel by default will use the static routes instead of any dynamically learned routes.Unfortunately, this is most likely not going to be available to you in the lab.

Also, to debug ip routing, you need to enable 'no ip route-cache' in the transit path.This enables fast-switching so that you can actually see the packets.

You can use a GRE tunnel in conjunction with a backup interface. Simply create a tunnel across the frame relay interface with unique IP addressing. And by enabling keepalives on the tunnel interface across the frame relay, these routers will be able to detect if IP transport is lost instead of relaying FREEK or PVC status. Also, by enabling backup interface on tunnel, the router will switch to the backup interface if there are any failures in the end-to-end transit of the frame relay PVC.

With ODR, CDP is enabled on ptp interfaces by default.You would need to enable CDP on multipoint interfaces. Man, I need to remember the simple command 'router odr'. For some reason, I'm always looking for an interface level command...most likely because of it's dependence on CDP.

I was going to include OER within this post, since it is covered in the same workbook but due to it's size, I will create a new post regarding OER. The INE labs are good, but I'm having some difficulty when it comes to Dynamips. One word of wisdom - make sure your 3725 router in dynamips has at least 256mb of memory. OER did NOT work on a 3725 with 128mb of ram.

Up next...OER

INE Workbook Vol 1 IP Routing

Well, I am making slow progress on INE WB1. I've had about two hours each day on the train ride into work available to study. Some times I was too tired, other times I didn't feel like studying. I was able to get through a few of the IP routing sections and I would like to share my notes with you.


The first interesting scenario was using Policy Based Routing (PBR). The scenario asked to use an alternate route based on CDP reachability. This was a real head scratcher but it really only added two lines in my route map.

route-map Policy-Routing permit 10
 match ip address R3-R4
 set ip next-hop 155.1.0.5
 set ip next-hop verify-availability
 set ip default next-hop 155.1.146.4



Simply add set ip next-hop verify ability to check for CDP. When used with set ip default next-hop, you can re-route based on CDP availability. If you look at this and think it is not working, remember this is based on CDP.  CDP has a default hello of 60 seconds and a hold time of 180, so it will take at least three minutes for CDP reachability to fail and the default next-hop to kick in. So either be patient, or change the hello timer to 5 and hold timer to 10 seconds. 

Additionally, you can also use IP SLA/Enhanced Obj Tracking to verify reachability. Use the same verify availability command, enter the IP address you want to verify, set a sequence number (For checking multiple destinations, like route-maps, first match processes) and then select the tracking instance.

route-map Policy-Routing permit 20
 match ip address R3-R5
 set ip next-hop verify-availability 155.1.146.4 1 track 1
 set ip next-hop 155.1.146.4
 set ip default next-hop 155.1.0.5

Important Note: When using a local policy, traffic is sent based on the loopback's source address and not source interface like RIB lookups. This could negatively  impact protocols such as BGP.



Here is the 12.3 command reference as I couldn't find this under the 12.4 command reference.
http://www.cisco.com/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_s1gt.html#wp1091258


I hope to post more later as I complete IP Routing in workbook 1.

Frame-Relay oddities/tips

Being stuck in a hotel room in DC due to the huge snow storm, I decided to get some study in today. As mentioned, I started with INE Workbook Volume 1. I skipped the first section, bridging and switching due to the lack of access to real 3560's. I plan to touch these later once I get some rack time rented.

The second section is all frame relay. Here are a few things I found out.

• You can disable inverse-arp per DLCI "no frame inverse-arp ip 201"
• An interesting way to disable inverse-arp is to put those DLCIs that you do not want dynamic mappings for into an "empty" subinterface. With no IP address on that interface, inverse-arp will be disabled for those DLCIs.
• When configuring frame-relay End-to-End keepalives, you need to configure the windows/thresholds/timers on both ends. For some reason, I thought the receive end would reply appropriately...
• Nothing new here but a good reminder for anyone else - for back-to-back frame-relay, you have to disable LMI keepalives. Without a frame-relay switch, there are no LMIs.
• You can fine-tune frame-relays broadcast queue.
  "frame-relay broadcast-queue 100 256000 36"
• You can bridge using frame-relay! Word of warning, this is inconsistent on dynamips but it does work. I just didn't get every ping through, even though the spanning tree instance was stable.

1. Enable frame-relay on serial interfaces (encap frame)
2. Disable IP routing and remove IP addresses on pertinent bridge routers
3. Create bridge (bridge 1 proto ieee)
4. Attach interfaces to bridge. To bridge across frame-relay and fast ethernet just attach bridge-group 1
   
5. Bridge frame-relay (frame map bridge 205 broadcast)
6. Test!

• They also cover frame-relay switching but the scenario said to not use the frame-relay route command. I scratched my head thinking of some interface-dlci/local-dlci flip-flop. I peeked ahead to the solution to find the connect command. You simply put in the interfaces, and the DLCI and it's supposed to work. Unfortunately, due to the IOS version I'm running, or dynamips - I could not get it to work. In any event, it's good to have this command available.

These are my complete notes for frame relay. It took me all day to get through this small lab, mostly due to the slow Internet speed accessing my servers at home. Hope someone else finds this useful! I hope to get some more studying in later this week and when I do, I will be sure to post my notes!

VCP - Done! On to the CCIE...

Well, last Thursday I took the VMware VCP-410 exam. I am happy to admit that I passed! I couldn't be happier as this is yet another item to add to my resume, makes me more valuable to my company and most of all - provides me some sense of accomplishment! Unfortunately, failing the CCIE lab twice kind of brought my spirits down. Now that I have completed my VCP training and certification - I'm moving full speed ahead with my CCIE. After my CCIE, I will be working on my Citrix CCEE certification....

My lab date is scheduled for July. I feel this should give me plenty of time to prepare. I am going to start with INE workbook volume 1. These are very technology focused and should firm up any week areas. I plan to mix in one lab from volume 2 and volume 3 once a week. I really think I need more time doing full labs to help prepare me for the actual lab. Of course, I will be mixing in DocCD reading every week. As I get close, I plan to mix mostly workbook 3 and workbook 4 with my DocCD reading. I also have the lasted Narbik workbooks and I plan to mix that in a bit as well.

Spent the week getting my servers re-provisioned for Linux and dynamips. I finally have my servers setup and plan to get some lab time in this week while I am away from home. I plan to start off slow. I want to be careful about overwhelming myself this time. I am determined but I don't want to burn out too soon. I am also going to try and be more study-conscious and post technical details here in the blog. Hopefully this will help me out, while helping other people out!