CCIE#26439

.......still in amazement.....

CCIE#26439

INE Workbook Vol 2 Lab 14 and final notes....

When you configure a neighbor under the EIGRP process, EIGRP will stop processing/sending multicast packets. This is useful if you only need to exchange eigrp with certain neighbors on a shared segment. This differs greatly from RIP. With RIP, a neighbor command will process updates with that neighbor via unicast but will still process multicast packets on the interface. In RIP, you also need to add passive interface.

The 'ip bandwidth-percent eigrp 10 x' command should  be placed on the physical interface, and not on the logic interface. The same goes for the bandwidth command. So far, I can't find the documentation from Cisco on this.

Enable DVMRP on in interface with 'ip dvmrp unicast-routing'. This will ensure the router can use DVMRP derived information for RPF checks.

It may be very important to add 'show run' to a parser view if that configured users should be allowed to see their pertinent configurations. The show run will only show relevant commands trusted to their view.

IP Traffic-export 'bidirectional' must be enabled if you want input/output export. Otherwise you will only get input statistics.

NAT on a stick is something I've seen a few times, and still just don't get. Chances are, you won't see it on the lab, but you could. In short, it is setup like a standard NAT , but uses a loopback interface as the inside interface. Then you need a policy-map on the 'outside' interface to match the translated traffic and 'set' the loopback interface.


interface Loopback0
 ip address 150.1.2.2 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 !
interface FastEthernet0/0
 ip address 172.16.0.2 255.255.255.0 secondary
 ip address 167.1.27.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 ip policy route-map Policy
 !
ip nat pool INSIDE 167.1.27.100 167.1.27.199 netmask 255.255.255.0
ip nat inside source list Inside pool Inside
!
ip access-list standard Inside
 permit 172.16.0.0 0.0.0.255
!


route-map Policy permit 10
 match ip address Inside
 set interface Loopback0


Maybe that will help someone out there.


Overall, this lab was not hard. I completed it in about 5.5 hours, with lots of breaks in between, and had time to verify my solutions. This lab was graded a level 9. Again, not difficult, just very in-depth. Many small tasks for 2 - 3 points. The only reason this should be perceived as hard is because it covers a very wide range of topics, and it really get's out there on the outer fringes of the blueprint (dvmrp? NAT on a stick?).


And that is it. This was my last full lab before my exam on Monday. I plan to continue reading Ruhan's short notes through the weekend, and re-visiting some Vol 1 topics that I haven't seen in a while. I also plan to re-read my own blog as I took some pretty nice notes. Other than that, I will take it easy for the weekend. No mad dash, no marathon until the finish. If I don't know it by now, I'm not going to know it much better  by Monday morning. 


With that being said, I am feeling really good. I have learned so much more this time around than my previous attempts. Doing these full labs is very beneficial. They teach you and show you how technologies and protocols inter-operate and they reinforce everything you learned in Volume 1. As much as I like Narbik's workbooks and his teaching style, he still has a huge whole in his materials and that is full scale mock labs. I don't think he believes in them but I disagree. If you are only working on one topic at a time, how will you know how zone based firewall will affect you routing protocols or your multicast 12 steps later in the exam? But I digress...


 I have rough days where I feel like I am not ready, but then I think back to how very close I came my first attempt, and compare that with how much better of an engineer I am now. I totally and 100% believe I am ready. I try not to get too excited at the prospect of finally conquering this thing. I want to stay grounded and humble so that I can attack this with a clear head.


So in short - here is what I have done the last 8 months.

1. INE's entire workbook Volume 1 on Dynamips. I completed the switching and some QoS tasks on 3560 switches located at my company's lab.
2. INE Workbook Volume 2 for Dynamips. I completed labs rated 7 and higher which included labs 1,3,7,8,9,10,11,12,13 and 14 for a total of 10 labs.
3. INE Workbook Volume 4 on INE Rack Rentals. I completed labs 1-7. 
4. Narbik Advanced Technologies Workbook. Specifically - MPLS. I had already been through his stuff twice. Chose INE for a different perspective and fresh material.
5. Re-attended Narbik's bootcamp in November of 2010. I picked up some good bits of information, but really - how many times can you re-attend? That was my 3rd.
6. INE/IPExpert blog posts - always useful and insightful. Even if you know the technology being discussed, it never hurts to reinforce your knowledge.
7. IPExpert vSeminars. Sometimes useful. I hate that they take the time to setup the lab during the live session. If you can't assign IP addresses, setup trunk ports and assign VLANs - you have no business wasting internet bandwidth watching the vSeminar. I recently attended one on multicast and after watching for 1.5 hours, they didn't make it past setting up PIM neighbor relationships. I still appreciate that they offer this for free.
8. Ruhan's CCIE Short Notes. Such a great book and something I will keep with me throughout my professional career. Give him some love - http://blog.ru.co.za/ccie-rs-short-notes-v4/
9. And last but not least - the Cisco DocCD. This should a very important aspect of your studies. Not only have I read the core topics from cover-to-cover, but I still like to bounce around during my labs. This way I can read what it is I am doing, and I can remember where certain items are located in the event I need to reference them in the doc cd. Both the configuration guides and the command reference are your friends.

Wish me luck everyone. I hope to have good news Monday evening.

INE Workbook VOl 2 Lab 12 & Lab 13

Sometimes, you may need to filter in two locations. In the first scenario, you needed to filter on the switch and on the router. The scenario asked to configure SW1 or R1 so this could be a tricky scenario. On the switch side, I just added the mac address to an unused port to prevent communication. On the router side, I matched the source mac address in a class-map and dropped the traffic.

With an OSPF network type of broadcast, you will see both net link states and summary net link states for the OSPF area. A network type of point-to-point treats the local network slightly different, it will not have a net link entry for the area. Seeing the scenario, and reading that it now makes sense.

If you are using a line password, the login 'block' feature will not work. You must use AAA or the local database.

You only need two additional options to use a remote DHCP server to assign IP addresses via PPP.

ip address-pool dhcp-proxy-client
ip dhcp-server 139.1.11.100

This if in addition to the client 'ip address negotiated' and the host 'peer default ip address dhcp' commands.

If you are sending prefixes out to backbones at multiple locations, you may want to filter routes inbound so you do not learn the same route from another location.

With BGP synchronization, iBGP routes received from an iBGP neighbor must be present in the IGP routing table to be considered best paths. I always think of this a different way - which is wrong. I was under the impression that a route must be present in the IGP routing table before it can be advertised to another iBGP peer. The synchronization issue come from received routes, not advertised routes. The only rule that applies with advertisements is that the bgp advertisement must have a match in the routing table - be it static routes to null 0 or IGP. This is an important distinction in that iBGP routes must be redistributed into IGP between iBGP peers. This is to prevent a black-hole where an intermediary routers between the peers does not run BGP. Also be careful of OSPF/BGP router-id's when working with synchronization.

I made ISATAP tunneling more difficult than it needed to be. Part of the problem was I got it mixed up with 6to4 tunnels. With ISATAP, create the tunnel interfaces and set the source interface and the mode. Assign the requested IPV6 prefix using eui-64 for the host portion. Now all you need are your static routes - but where do you point them to? This is where some similarity between 6to4 and ISATAP come in. Your static route destination will be like so for a route from R3 to R4 loopback interface.

ipv6 route 2001:cc1e:1:4::/64 2001:cc1e:1:345:0:5efe:9601:404

The 2001:cc1e:1:345 is just the standard IPv6 prefix for the tunnel. 0:5efe is part of the ISATAP specification and should be placed between the prefix and the host address. 9601:404 is simply the hex representation of R4's loopback 0 interface (which is the source interface for it's tunnel back to R3.  Here are the DocCD details - http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1055566

So here is the full configuration for completeness:

R3
int tun345
ipv add 2001:cc1e:1:345::/64 eui-64
tunn so lo0
tunn mode ipv6ip isatap
!
ipv6 route 2001:cc1e:1:4::/64 2001:cc1e:1:345:0:5efe:9601:404
ipv6 route 2001:cc1e:1:5::/64 2001:cc1e:1:345:0:5efe:9601:505


R4
int tun345
ipv add 2001:cc1e:1:345::/64 eui-64
tunn so lo0
tunn mode ipv6ip isatap
!
int lo0
ipv add 2001:cc1e:1:4::4/64
!
ipv6 route ::/0 2001:cc1e:1:345:0:5efe:9601:303


R5
int tun345
ipv add 2001:cc1e:1:345::/64 eui-64
tunn so lo0
tunn mode ipv6ip isatap
!
int lo0
ipv add 2001:cc1e:1:5::5/64
!
ipv6 route ::/0 2001:cc1e:345:0:5efe:9601:303

The reason we are sending traffic from R4/R5 to R3 is because R3 is participating in OSPFv3 and providing IPv6 routing for the rest of the network. Thus, we also redistribute static in OSPF so that ospf neighbor routers can reach R4/R5. You could do this with any number of routers - just have one as the 'hub'. With two routers, you would just point them to each other. If this sounds like frame-relay, that is because that's really what it is. ISATAP treats the underlying IPv4 network as NBMA.

'ip dhcp relay information policy keep' will retain Option 82 information. This is a global exec command.
'ip dhcp relay information trust' will trust the Option 82 information with a 0.0.0.0 giaddr. This is an interface command.
'ip dhcp relay information trust-all' is the global equivalent of the above interface command.

If you get a scenario asking you about collecting traffic being sent/received on an interface, storing it locally and providing you with 5 minute averages - the solution is not ip accounting and it is not netflow. The correct answer is 'ip nbar protocol-discovery'. Pretty simple eh?

You can also create a flow monitor to capture information.

flow monitor TEST                         <= defines a flow monitor
   statistics packet protocol             <= capture packet protocol
   statistics packet size                 <= capture packet size
   record netflow ipv4 protocol-port-tos  <= record netflow protocol, port and TOS counts


interface fa0/1
   ip flow monitor TEST output            <= capture output packets
   ip accounting output-packets           <= enable ip accounting output

Be very careful with policy routing. Although the configuration is pretty straight-forward, pay attention to where you place it. If there are multiple paths through the network, you will need to select the right location to apply the policy.

'frame-relay ip rtp priority 16384 16383 512' will prioritize RTP packets up to the configured rate, which is 512k here.

And with that, lab 12 and lab 13 are complete. Had a few things through me for a loop, and some other things that were messed up by INE. Overall, not too bad. I believe both labs were a level 9. Off now to prep for the next lab. Troubleshooting tomorrow and start on the next lab. Only a few days left....the clock is ticking....

What is missing?

I have typed so many ip addresses on this keyboard. And no, its not a cheap one.

Published with Blogger-droid v1.4.1

INE Workbook Vol 2 Lab 9, 10, 11

 By default, the EIGRP hello interface is 60 seconds for low speed NBMA interfaces and 5 seconds for all other media. So if you change the hold timer on a NBMA interface to less than 60 seconds, you better change the hello interval as well - to 1/3 the hold timer.

Also, EIGRP hold-time is transmitted in the hello packets and locally configured EIGRP hold-time actually specifies the hold-time for the remote side. So you only need to configure one side.

I believe I would have still gotten the points, BUT Narbik teaches something very important. BE VERY SPECIFIC and don't do more than what is needed. Not only is there not a discrepency in your solution, but the proctor will know that you really know the protocol/feature/etc inside and out.

When doing key accept/send lifetimes and you need to specify the start time as the present or in the past - set it to Jan 1 1993. This way there is no discrepancy since the router will always understand this date regardless of configured time/ntp parameters. I took the long way of setting the start lifetime for now, and then manually setting the clock.

'show ip eigrp interface detail fastEthernet 1/5' will show you the interface details for EIGRP. Not 'show ip eigrp interface fa1/15 det' like you would expect.

You can use the cli command 'renew dhcp FastE0/0' to renew an IP address. Subsequently, you can schedule this using Kron.

MQC uses the mincir value in the frame-relay map-class to determine the available bandwidth on a vc. Since mincir defaults to half the configured CIR, it may be required to adjust the MINCIR values higher if the reserved bandwidth exceeds half of the configured CIR.

When implementing IOS Firewall, it will only inspect after an access-group entry. So if you are permitting all TCP traffic on an access list, and then impement IOS firewall to inspect TCP traffic - it will never be inspected because the router will process the access-list before the inspection rules. Oversight like this can lose you 3 points. Also, be weary of the 'router-traffic option'. If you need to originate traffic from the router itself, you will need to add router-traffic to the inspection rule. IE; initiate H.323 call from R6 to BB1. To allow the return traffic to come in from BB1 to R6, you must add 'router-traffic'.

Here is a pretty interesting way of only allowing IP traffic...

bridge 56 route ip
bridge 56 route ipx
!

interface FastEthernet0/0
 ip address 187.1.56.6 255.255.255.0
 speed 100
 full-duplex
 ipv6 address FE80::6 link-local
 ipv6 address 2001:187:1:56::6/64
 ipv6 ospf 6 area 1 instance 99
 bridge-group 56
 bridge-group 56 input-lsap-list 201
!
access-list 201 permit 0x0800 0x0000

INE leads me to believe that if you use a rate-limit access-list to police traffic for a specified precedence, it will treat all other traffic differently, so you need to 'catch' the remaining traffic with precedence values accordingly.

access-list rate-limit 3 3
access-list rate-limit 1 mask FF

The first line just matches prec 3. The 2nd line matches any precedence value (mask FF). Now just configure CAR accordingly. I would have assumed you could have just done a standard rate-limit command without matching on any traffic. I will need to lab this up to verify.

Overall, these labs were not too difficult again. These were a difficulty level 8 or 9. I don't believe these labs to be hard at all - just very intense and time consuming. You would need to be very fast and efficient to complete these labs in 6 hours. And no I didn't do all these labs in a day - I've just been accumulating notes for multiple labs.

Man...only one more week and I'll be sitting in RTP.....