On the path to my CCIE...

Welcome back!

2011-06-16T13:28:00.000-04:00

Well judging by the responses, I see there are some of you left out there. As I mentioned before, I'm going down the Service Provider 3.0 path. I kind of wished I started in the 2.0 track, but I can't change that now. The biggest hurdle is the lack of study resources, and rack time. Well, over at the IEOC Forums there has actually been a successful pass of the version 3 blueprint. That person has some service provider experience, but also used the Cisco provided practice labs (from the SPv3 study group) as well as some old material from the training vendors such as INE. And apparently, GigaVelocity will soon be offering SPv3 rack rentals!

So I've loaded up a new server to run my dynamips routers, ordered the SP v2 workbooks from INE (hoping they update to 3.0!) and using as much of the resources from Antonio Soares mini-labs as I can. I plan to just do the scenarios, read the DocCD and give it a try. I've got my written scheduled for July during Cisco Live so I need to get as much written studying done as possible.

Hopefully one of the vendors soon update their materials to cover the new blueprint. Until then, I plan to go at it alone hoping this isn't as difficult or as time consuming as the R&S. I don't have any real world experience in a true service provider environment, but I do work for a large company that runs their own MPLS network with service such as VPRN, VPLS, VPWS, MPLS-TE, RSVP, etc.

I also need to fit time in to finish my Alcatel-Lucent NRS-II and SRA certifications, but since I can't resume those studies until July, may as well stay sharp and get back on the Cisco track!

Anyone out there?

2011-06-15T17:47:00.002-04:00

Just checking to see if anyone is out there. I've decided to go for CCIE Service Provider 3.0 and trying to determine how beneficial the blogging will be this time around...

CCIE#26439

2010-07-12T21:05:00.002-04:00

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

CCIE#26439

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

2010-07-09T12:31:00.000-04:00

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.

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.
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.
INE Workbook Volume 4 on INE Rack Rentals. I completed labs 1-7.
Narbik Advanced Technologies Workbook. Specifically - MPLS. I had already been through his stuff twice. Chose INE for a different perspective and fresh material.
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.
INE/IPExpert blog posts - always useful and insightful. Even if you know the technology being discussed, it never hurts to reinforce your knowledge.
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.
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/
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

2010-07-07T12:02:00.000-04:00

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?

2010-07-06T15:20:00.001-04:00

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

2010-07-05T08:54:00.000-04:00

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.....

INE Workbook Vol 2 Lab 8

2010-06-25T12:01:00.000-04:00

You can use bandwidth to adjust STP costs as opposed to using the 'spanning-tree vlan x' command.

When you are doing PPP authentication over MLPPP, you need to enable the authentication parameters on the virtual-template interface and NOT the multilink group interface.

Always be on the lookout for split-horizon issues!! ALWAYS!

I found a big problem with doing the following:

R5
router eigrp 1024
redistribute rip metric 1 1 1 1 1

If, you need to adjust the metrics on neighboring EIGRP routers (variance, traffic share), your metric values will be too small to manipulate. EIGRP will take the smallest bandwidth in the path (1 as configured with the redistribute command) leaving you will only DELAY to manipulate. Usually this is a good thing, but even setting delay to the highest on one interface, and the lowest on the other interface, you will never get a traffic share of roughly 1:2. So - if you need to traffic share 1:4, you are screwed. Now - is it best to do 1 1 1 1 1 or something more like 1544 1 255 1 1500 for metric values? That I cannot say for sure. If you read through your lab and you see you will need to traffic share/load balance, I would set the metrics to more normal values.

You can fix BGP next-hop reachability by using a route-map and using 'set ip next-hop peer-address'. Just make sure that your peer address is reachable throughout your bgp domain.

By default BGP routers will only compare MED between prefixes learned from the same autonomous system. So if you need to influence the backbone routers for inbound traffic, you COULD use MED provided all your BGP routers are in the same AS, but you could also use AS-path prepending.

I always forget that you can attach a route-map to a network statement. So if you get a task for filtering a bgp originated route, and you cannot use prefix-lists or access-lists, a route-map attached to the network statement will be the way to go.

You can attach a group access-list to the 'ip pim send-rp-annouce' command to set a router to only advertise itself as the auto-rp candidate for a certain subset of multicast groups. This configuration is done at the Auto-RP candidate. You also set the rp-announce-filter on the auto-rp mapping agent.

ip pim send-rp-discovery Loopback0 scope 10
ip pim rp-announce-filter rp-list R1_RP group-list R1_Groups
ip pim rp-announce-filter rp-list R2_RP group-list R2_Groups
ip access-list standard R1_Groups
permit 224.0.0.0 0.255.255.255
permit 226.0.0.0 0.255.255.255
permit 228.0.0.0 0.255.255.255
permit 230.0.0.0 0.255.255.255
permit 232.0.0.0 0.255.255.255
permit 234.0.0.0 0.255.255.255
permit 236.0.0.0 0.255.255.255
permit 238.0.0.0 0.255.255.255
ip access-list standard R1_RP
permit 150.1.1.1
ip access-list standard R2_Groups
permit 225.0.0.0 0.255.255.255
permit 227.0.0.0 0.255.255.255
permit 229.0.0.0 0.255.255.255
permit 231.0.0.0 0.255.255.255
permit 233.0.0.0 0.255.255.255
permit 235.0.0.0 0.255.255.255
permit 237.0.0.0 0.255.255.255
permit 239.0.0.0 0.255.255.255
ip access-list standard R2_RP
permit 150.1.2.2

What I am not sure about is if you are required to do both. I suppose this would depend on your multicast topology but it's probably safer to do both.

I wasn't getting my RP mappings across my frame-relay interfaces. There was two solutions to this problem - one that wasn't solved by INE. R1 (the hub F/R router) had the wrong RPF interface for R2 and R3. A simple mroute fixed this issue. The other issue is PIM NBMA. Multicast traffic coming in from a spoke to another spoke will not work without PIM NBMA mode. Think of this like a split-horizon type issue. The pim nbma-mode takes the multicast traffic and treats each PIM neighbor like a point-to-point interface. Why listen to me drabble on about it - get it right from the horse's mouth..... Using IP Multicast over Frame-Relay Networks

Multicast helper is used to transfer broadcast traffic between two end points across a multicast network. There are several caveats such as using 'ip forward-protocol' to process-switch the traffic instead of fast-switching. You also need to apply the multicast helper map on the INCOMING interface of the last hop router (facing the multicast network) and not on the OUTGOING interface of the last hop router (facing the client). DocCD is your friend. If you see this in the lab, you should know exactly where to go....http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_inter_mc_helper_ps6441_TSD_Products_Configuration_Guide_Chapter.html

INE presents an interesting way to prevent transit traffic between two end nodes. R5 interface Fa0/1 has two subinterfaces - one to BB2 and one to BB3. By matching the input interface and dropping that traffic, R5 can no longer be used as a transit between the two nodes.

class-map match-all FROM_BB3
match input-interface FastEthernet0/1
class-map match-all FROM_BB2
match input-interface FastEthernet0/1
policy-map TO_BB2
class FROM_BB3
   drop
policy-map TO_BB3
class FROM_BB2
   drop
interface FastEthernet0/1.52
ip address 192.10.1.5 255.255.255.0
service-policy output TO_BB2
interface FastEthernet0/1.53
ip address 204.12.1.5 255.255.255.0
service-policy output TO_BB3

A little out there, but still feasible.

In order to tune a shapers queue, you need to apply a nested service-policy.

policy-map CBWFQ
class class-default
  bandwidth percent 100
  queue-limit 10
policy-map FRTS
class class-default
  shape average 128000
  service-policy CBWFQ

And with that, lab 8 is done. Again, not difficult at all and at points can be very tricky. I am getting much better at paying very close attention and doing exactly what is asked in the scenario. Going forward, I need to work on getting much faster as well. Tomorrow I plan to hit Narbik's troubleshooting scenario and then next Monday and Tuesday I've rented some rack time from INE and I plan to complete a few of their troubleshooting labs.

INE Workbook Vol 2 Lab 7

2010-06-23T12:20:00.000-04:00

Remember that by default 3560 switches do not trust CoS values and will re-write all CoS values with 0. So you either need to trust the ip phone, or trust CoS5 or whatever CoS values the phone is sending. 'switchport priority extend cos 1' will set the CoS on frames attached to the appliance (PC) instead of re-writing to 0. Verify all this with the 'show interface fa1/3 switchport' as well as 'show mls qos interface fa1/3'.

Rack1SW2(config-if)#do sh int fa1/3 switchport
Name: Fa1/3
Switchport: Enabled
Administrative Mode: dynamic access
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: Disabled
Access Mode VLAN: 5 (VLAN0005)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: ALL
Trunking VLANs Active: none
Protected: false
Priority for untagged frames: 0
Override vlan tag priority: FALSE
Voice VLAN: 4
Appliance trust: 1

Rack1SW2(config-if)#do sh mls qos int fa1/3
FastEthernet1/3
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 0

I got killed again but not paying attention. Words like 'only' can mean a lot. In my instance, I forgot to set a distribute-list on RIP to advertise ONLY the summary routes. I also got killed because I filtered all updates to a RIP neighbor, instead of only one route. These are very simple mistakes, but I got tossed 4 very easy points out the windows...sigh....

Very important - with OSPF always make sure you do NOT have dis contiguous area 0's. In the OSPF scenario, I accomplished everything they wanted me to - except I had dis-contiguous area 0's. And remember, that there are two ways to connect area 0's - a tunnel interface running in area 0, or a virtual-link. Be careful, because both methods will not produce the same exact results. Another 5 points lost....but hey, I'm still learning here!

The redistribution scenario was pretty crazy. I won't get into details, but I need more practice...just need to take it one step at a time. I always knew this was one of my weaknesses, and something I hope these fulls labs teach me to do. Nothing like repetition I say...

INE has a nice table describing BGP best path selection...

Attribute Direction Applied Traffic Flow Affected

--------------------------------------------------------------

Weight Inbound Outbound

Local-Pref Inbound Outbound

AS-Path Outbound Inbound

MED Outbound Inbound

The only one that trips me up is MED. Just remember that you set MED outbound to influence INBOUND traffic.

When setting BGP timers, you must also disable 'bgp fast-external-fallover', otherwise the routes are immediately withdrawn upon the BGP session tear-down.

Again, be very careful with the wording of each scenario and check and verify everything. I need to unsupress from routes to certain neighbors, which I accomplished correctly, but that task also stated to only those neighbors in AS300 should see the specific summary routes, all others should still get the summary. Well, if you don't set community no-export in your unsupress map, your routers that should have only had the aggregate, now have your unsupressed routes as well. Doh!

Also a good tip - it is best to always consolidate all attribute settings in a single route-map. Otherwise, the BGP order of operations can give you un-desirable results. Do not mix and match the application of route-maps, unsupress-maps, attribute-maps, distribute-lists, prefix-lists or filter-lists to the same neighbor in the same direction. Great tip...thanks INE!

Apply IPv6 access-lists with 'ipv6 traffic-filter' instead of 'ip access-group'. It's nice for cisco to right the ship and make the command syntax sounds like what we are actually doing it - but why not make everything consistent? There is no 'ip traffic-filter' and there is no 'ipv6 access-group'. This is one of my biggest pet peeves with Cisco IOS.......by the way Apple, enjoy paying Cisco just for calling your os iOS.....how stupid....

A very important but often overlooked point, the 'ip igmp join-group' command should be place on the client interface, or on the interface receiving traffic from the group, not the other way around.

When filtering on HTTP requests using a class-map, remember that this is a regex express. Thus to filter root.exe, you should configure 'match protocol http url "*root.exe*". Notice the double-quotes as this is important.

Local Area Mobility (LAM) is something I haven't seen in INE's or Narbik's Volume 1 workbooks. What gives? Anyway, it offers hosts a simple way to roam around the network. When 'ip mobile arp' is issued on an interface, the LAM process starts listening for ARP requests received on the interface that are from hosts which are not in the IP subnet of that interface. When these request are received, the LAM process knows these came from a mobile host. The hosts IP address is then installed in the IP routing table as a mobile host route. The access-group command tells the router which hosts to listen for arp requests from. You would then need to redistribute mobile routes into your IGP.

interface FastEthernet0/0
ip address 163.1.6.6 255.255.255.0
ip mobile arp access-group 2
!
router rip
version 2
redistribute mobile metric 1
network 54.0.0.0
network 150.1.0.0
network 163.1.0.0
network 204.12.1.0
distribute-list prefix RIP out FastEthernet0/1
distribute-list gateway BB1-BB3 in
no auto-summary
!
access-list 2 permit 163.1.5.25

From the above, the hosts in VLAN6 can now receive traffic for 163.1.5.25.

Remember that you can apply a netflow sampler-map using policy-maps. At this point, I'm not sure why would would have to do this (unless you were selectively exporting certain traffic) over just using the 'flow-sampler' interface command. Also, with PPP, you apply the flow ingress/egress or service-policies on the physical interface.

With RSH, you need to configure the remote-host based on hostnames as well as a username. At least that is what I take out of it. I have yet to find the configuration guide.

Lab 7 is done and complete. For being a difficulty level 9, I didn't think it was that hard. It was tricky at times, but is totally do-able. The worry here is the amount of work between a level 7 and a level 9 is pretty great, so you would really have to know your stuff to complete the level 9 lab in 6 hours. I liked this lab and thoroughly enjoyed it - even though it took me three days to complete. It took me three days because I was consumed with work - not because it took me that long! All in all though, it probably took me closer to 8 hours to complete as opposed to 5-6 hours. That's why I am doing these labs - to take my time and learn, and then to get faster. I don't know why I was scared of the difficulty level 9 labs....

Hopefully I'll squeeze in a full lab tomorrow, and then troubleshooting on Friday. For now, I'm off to load up my routers for tomorrow and call it a day.

INE Workbook Vol 2 Lab 6

2010-06-16T18:59:00.000-04:00

While in transparent mode, VTP advertisements can be carried through the transparent switch to other connected switches over trunk ports. If you are using DTP and the domains are mis-matched, the trunk will not form. You can override this by enabling static trunk mode, and disabling DTP. Also, VTP version 2 does NOT do any version checking.

Ok, I will say the MPLS section really tripped me up here, not because the scenario was particularly hard, but because partial configurations were there, and I thought I needed to add more configuration to make it work than was really necessary. This proves I need work troubleshooting MPLS. I can build a MPLS pretty easy from the ground up (at least in the CCIE realm) but make an existing one work is still a little bit of a weakness.

Multicast stub routing is accomplished by using the 'ip igmp helper-address x.x.x.x'. The address here is where group membership reports and leave messages will be sent to. When using the helper, typically there is no PIM neighbors between the two routers. Make the proxy router has another PIM interface to forward multicast traffic in the event that your neighbor-filter filtered the only connection.

You can stop communication with a malicious host by configuring a static mac entry and pointing it to an unused or dead interface. You could also use drop, as well as VACL.

I'm starting to get these dynamic ACLs w/ access-enable, but I still can't get there 100%. To prevent access to SW1 without being authenticated, here is the pertinent configurations. Once authenticated with the specified username/password - you can telnet to the host.

username TELNET password 0 CISCO
username TELNET autocommand access-enable
username CLI password 0 CISCO
interface Serial0/0
ip access-group DYNAMIC1 in
!
interface Serial0/1
ip access-group DYNAMIC1 in
!
ip access-list extended DYNAMIC1
dynamic PERMIT_TELNET permit tcp any any eq telnet
deny tcp any host 191.1.27.7 eq telnet
deny tcp any host 191.1.7.7 eq telnet
deny tcp any host 191.1.77.77 eq telnet
deny tcp any host 191.1.177.7 eq telnet
deny tcp any host 150.1.7.7 eq telnet
permit ip any any
!
line vty 0 4
password cisco
login local
line vty 5 903
login local

Fear not! If you do get this on the lab, it's easily found in the DocCD under Security -> Securing the Data Plan -> Configuring Lock and Key Security (dynamic access lists). Here is the directly link which I highly suggest you read... http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_lock_key_secrty_ps6441_TSD_Products_Configuration_Guide_Chapter.html

I get it. You create a regular extended access at list, but at the top you specify a permit statement to match the dynamic ACL. The autocommand access-enable will add the authenticated user to the dynamic access-list. Wow, now that I see it and read through the DocCD, it makes total sense. It's just one of those things you wont see very often. One important point - I believe you can attach the autocommand to either the username or the vty line. Attached to the username means only the specified username, attached to the vty line and it's any authenticated user. Also, when you attach a timeout value to the dynamic ACL, that is the absolute timeout. When you attach timeout to the autocommand, that is the idle timeout. Moving on...

When you are configuring RMON, you can send a trap, or you can log. Whichever one you chose, make sure you setup the proper logging/snmp server (logging 191.1.7.100 or snmp-server host 191.1.7.100 traps public). Again, CLOSE attention to details. Failing to do so would mean you missed out on 3 easy points. You may also need to add 'snmp-server ifindex persist' if not already enabled. I would as to not miss out on those points...if not given the ifindex, find them with 'do sh snmp mib ifmib ifindex'.

Not that I would expect Cisco to want you to know this, but UDP chargen is port 9. You can test UDP small servers with the traceroute command.

There was a tricky scenario that asked you to drop HTTP traffic, but not guarantee it any bandwidth. I simply added random-detect to the class default, as this will indeed drop HTTP traffic before the interface is congested. Now, is this the right answer? I can't be sure as the scenario said nothing about dropping ONLY http traffic. In any event, here is the 100% right answer.

class-map NOT_HTTP
match not proto http
policy-map Voice
class RTP
priority percent 25
class NOT_HTTP
class class-default
fair-queue
random-detect

In short, we removed everything except for HTTP from the class-default so when we enable random detect, only HTTP packets will be dropped in anticipation for interface congestion. Very tricky, but very cool.

With header compression, when it says 32 bi-directional connection, your compression-connections number should actually be 64. Again, another easy 2 points lost.

And with that, I am done with Lab 6. Overall, not really all the difficult, but lack of attention to details and the will to verify can absolutely kill you. My notes above reflect several small items that would have killed me. I love doing these full labs. These vendors all know how to present these to you, just like Cisco does. Is that breaking NDA? No. These guys have taken the exam themselves and have taught and mentored probably thousands of students when it comes to the CCIE. So if for nothing else, these full labs help you get familiar with the language you are likely to see in the real lab.

My time was pretty good on this lab - about 5 hours. I need to get faster, but overall I'm pretty happy with 5 hours right now. Short night, I've had kind of a rough day so I am going to prepare my racks for the next lab and start fresh tomorrow.

OSPF Sham-Links

2010-06-14T14:28:00.001-04:00

Pretty cool article that explains and shows how the sham link works. Important point here that I have not picked up from any vendors workbook - the Sham Links makes they MPLS transported routes appear as intra-area (instead of the default inter-area) and thus the reason why you can now tweak the ospf costs between your MPLS link and your backup link.

http://blog.ipexpert.com/2010/06/14/ospf-sham-links/

INE Workbook Vol 2 Lab 3

2010-06-12T11:49:00.000-04:00

Whats that? You heard me say I was going to work on troubleshooting? Well - troubleshooting with Dynamips doesn't work so well and I just couldn't load all the features on my dynamips switches. So I plan to rent some rack time next week. In the mean time, I am moving on to Lab 3. I skipped lab 2 because it was a difficulty 6 and since I'm getting low on time, I am only going to tackle difficulty 7 and above to start. If I have time - I will circle back to the other labs.

With CRB briding, a protocol can be routed on one interface while bridged on another interface. Traffic in the routing domain cannot be passed to the bridged domain. With IRB, a protocol can be routed and bridged on the same interface. For example, with CRB, IPX can be bridged while IP is routed. CRB is legacy and replaced by IRB with the addition of the BVI. Steps to create a bridge include:

Create a transparent bridge group using 'bridge 1 protocol ieee'. This creates a bridge for non-IP protocols. Add the pertinent interfaces to the bridge with 'bridge-group [num] where num is your bridge group number. These interfaces can now bridge non-IP protocols (aka - fallback bridging).
To enable IRB, and thus bridge IP protocols, issue the 'bridge irb'. Now you need to select which protocols to route; 'bridge 1 route ip'. Now IP will be routed and bridged. This is not specific to IP and can be accomplished with other protocols..
Now you need to create the bvi with 'interface bvi 1'. Now all traffic that passed through the bridged domain to the routed domain, and vice versa, must pass through the BVI. Now add any logical configuration such as IP address.

That's it! I am finally getting this bridging thing. I was able to accomplish this except I forget to add the IP address and route IP - mostly because the instructions weren't clear that I needed to do this. You can verify with 'show interface irb'. This will show you what protocols are bridged, and which ones are routed.

Remember that a virtual link IS an Area 0 adjacency so if you are required to authenticate all area 0 adjacencies, you must include authentication on your virtual links!

Boy did I get tripped on the redistribution scenario for a pretty stupid reason - I couldn't figure out how to prefer one route in OSPF over the other...METRIC STUPID! Sheesh. I didn't come up with the solution INE did, but had I altered the metric, my solution would have been the same....This is why I am doing full labs - so I can learn and remember stuff like this!

'timers lsa arrival 2000' will protect against flooding with the same LSA during network instability.

To prevent your BGP AS from being used as a transit AS, use the community NO EXPORT which will prevent advertisement to EBGP neighbors.

Use 'mpls ldp discovery transport-address interface ' to set ldp/tdp to use the specified interface as the TCP connect source instead of what you have set as the router-id (most likely loopback0).

The IGMP static-group command causes the devices to process switch the group specified.

The follow are required in an ACL to permit traceroute to complete.

1 permit icmp any any time-exceeded
2 permit icmp any any port-unreachable

In TCP intercept 'watch' mode, incomplete sessions will be terminated with a RST after 30 seconds. You can set the time with ' ip tcp intercept watch-timeout 15'.

If you get a scenario pointing you to a TFTP server on a vlan and NOT a particular host, you need to set the ip helper-address to the broadcast address of that subnet. Also, you need to enable 'ip directed-broadcast' on the VLAN interface.

'frame-relay interface-dlci 555 protocol ip 136.1.5.2' will assign and IP address via BOOTP to the host on dlci 555 when used on a point-to-point interface. With P2M, a frame-relay map will accomplish the same.

When using subinterfaces with rsvp, the 'ip rsvp' commands will need to be applied on the physical interface as well. If there are multiple subinterfaces, the physical rates should be the sum of all subinterfaces. Also - frame-relay requires fair-queue to be enabled. So if you are using FRTS, be aware...

And with that, I've finished lab 3. To be honest, this lab was not kind to me. I've used the blog here to take notes on the things that tripped me up. Other things that I didn't note here are just oversights that will kill me in the real lab. Read twice, and verify twice. That is my motto. My biggest weakness was the BGP section. If I have time, I would like to tackle both INE and Narbik's BGP sections for a little reinforcement. Well, I won't be studying tomorrow and will instead be traveling to Chicago for work. Hopefully I can get a few labs done next week, and touch back on BGP. We will see how that goes...

INE Workbook Vol 2 Lab 1

2010-06-10T12:07:00.000-04:00

When redistributing between protocols, be careful about connected interfaces. If you have redistributed a connected interface using a route-map, and you redistribute between two protocols - anything not specified in that route-map will not be redistributed. Those interfaces will be treated as connected interfaces. Here is a redistribution example.

router eigrp 10
redistribute ospf 1 metric 1 1 1 1 1
network 54.1.1.6 0.0.0.0
no auto-summary
eigrp router-id 150.1.6.6
!
router ospf 1
router-id 150.1.6.6
log-adjacency-changes
redistribute connected subnets route-map Redist
redistribute eigrp 10 subnets tag 10
network 150.1.6.6 0.0.0.0 area 46
network 183.1.46.6 0.0.0.0 area 46
router bgp 100
!

route-map Redist permit 10
match interface FastEthernet0/1

We are redistributing the connected interface f0/1 into OSPF. Now when eigrp is redistributed into OSPF, the eigrp connected interface (54.1.1.6) will not be present in OSPF and those route unreachable. Simple fix is to also redistribute the EIGRP connected interface.

route-map Redist permit 20
match interface Serial0/0

In the lab, if you need to redistribute between protocols and connected interface, you should immediately investigate this!

Sometimes, you may to use the neighbor x next-hop-self command to work around recursive lookup issues. For instance, from AS 100 we want to prefer the route to 150.1.11.0/24 in AS200 through the connection between R5 and SW4. So off we go and we set the metric out from AS200 to AS100. Poof! The route to R5 is preferred from within R1.

Rack1R3#sh ip bgp
BGP table version is 33, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
   r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network Next Hop Metric LocPrf Weight Path
.....
*>i150.1.11.0/24 183.1.105.10 100 100 0 200 i
* 183.1.123.1 200 0 200 i

Using a metric value of 100 over 200, we prefer 150.1.11.0/24 going through SW4 via 183.1.105.10. Let's see where that takes us.

Rack1R3#sh ip route 183.1.105.10
Routing entry for 183.1.105.0/24
  Known via "eigrp 100", distance 90, metric 2689536, type internal
  Redistributing via eigrp 100, ospf 1
  Advertised by ospf 1 subnets route-map EIGRP->OSPF
  Last update from 183.1.123.2 on Serial1/0, 03:12:41 ago
  Routing Descriptor Blocks:
  * 183.1.123.2, from 183.1.123.2, 03:12:41 ago, via Serial1/0
   Route metric is 2689536, traffic share count is 1
   Total delay is 40300 microseconds, minimum bandwidth is 1544 Kbit
   Reliability 255/255, minimum MTU 1500 bytes
   Loading 1/255, Hops 4

Ugh, no - that's not what we wanted. The route to 150.1.11.0/24 will go out via the Serial1/0 connection based on the next-hop value. So how to get around this? If on AS100 router R5, we set the 'neighbor next-hop-self' command for R3, the next-hop will be the connected interface.

Rack1R3#sh ip bgp
BGP table version is 34, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
   r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network Next Hop Metric LocPrf Weight Path
......
*>i150.1.11.0/24 183.1.0.5 100 100 0 200 i
* 183.1.123.1 200 0 200 i
Rack1R3#sh ip route 183.1.0.5
Routing entry for 183.1.0.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 1000 0 255 1 1500 route-map EIGRP-Connected
  Routing Descriptor Blocks:
  * directly connected, via Serial1/1
   Route metric is 0, traffic share count is 1

I need to learn to not make stupid mistakes. In a MPLS VPN environment, I tried to ping across the MPLS VPN but I didn't see the source interface on my ping command. Forgetting something like that could send me on a 'troubleshooting' spree for something that isn't really a problem...sigh...

I've said it before, I'll say it again - 'no ip mroute-cache' and 'debug ip mpacket' can be a lifesaver when troubleshooting multicast.....

INE presents things like you may see in the lab. I got a requirement to rate-limit ICMP packets. My only restriction was to not use 'match protocol'. So I configured the legacy rate-limit command with an access-list. That should be an acceptable solution. Their solution was the CBWFQ policing method (which I prefer) using an access-list to match ICMP packets. In my eyes, both are viable solutions.

With CBWFQ, you can't use percent and bandwidth commands, but you can use percent with priority commands. Unfortunately INE left out the fact that the voice traffic should be prioritized. They simply said 'allocate 64kbps to VOIP bearer traffic'. Standard practices says to use priority here, but the lab is certainly NOT based on best practices.

And with that, I've completed Lab 1 with a difficulty level of 8. I really didn't think that it was too hard. There was just way too many scenarios where they weren't real specific about what you should do, or left out important details. I guess this is where you would ask the proctor in the real lab and hope that they are more helpful than the last proctor I had. I just made a few simple mistakes that I need to keep track of because they can KILL YOU in the real lab. I need lots more practice doing redistribution, and these full labs should help me. I could also use some more help with EEM - mostly I need to know what all the variables are for an action....

I was almost regretting doing full labs because I thought I would get murdered, but really it was not that bad. I think I am going to fire up troubleshooting and work on that tomorrow and Saturday. I'll be leaving town Sunday for a week, but hopefully I'll be able to get a few full labs completed while I am out of town working....

Dynamips with 3725 and NM-16ESW modules

2010-06-08T13:11:00.000-04:00

Does no one else have a problem with this setup? I've tried windows. I've tried multiple linux distros. Tried GNS3. I've tried dozens of idle-pc values, several IOS versions, multiple servers, different configurations and I still have issues.

What are the issue? Sometimes layer 2 sometimes layer 3. Sometimes arp entries will be incomplete on one of my four switches to a directly connected neighbor. CDP shows up fine. Almost always, all my layer 3 interfaces on one switch will just fail to work. What gives? The other three switches will be just fine!!

At first, I thought it was load. Ok, I have a few servers laying around. Fired it up, installed ubuntu 10, dynamips and dynagen and fired up only my 4 switch instances. Guess what? Still problems. I tried Windows. Still problems. Tried CentOS. Still problems. It is not just me - I've had several friends who have also had the same issues with NM16-ESW modules with the 3725 images.

So what was my solution? Use the 3640 image. It works EVERY DAMN TIME. Now granted, the feature set is different, and I can't do things like EIGRPv6 and I can't use the now-standard vlan commands in configuration mode like on t he 3725 - but it WORKS. I wasted a whole day trying to get this to work (again) instead of working on a full lab. Sigh. I've searched google to no extent. I've searched the dynamips/dynagen forums, INE's forums and still, I can't find anyone else with this issue.

So if anyone out there has a solution, I would be glad to hear it.

....now back to starting my full labs tomorrow.....

Narbik MPLS

2010-06-08T09:09:00.000-04:00

Remember that LDP advertises it's LDP router-id as the transport address in the LDP discovery messages and you must provide reachability for that router-id. There should be an exact match for the LDP-ID in the routing table. Pay close attention as a lot of MPLS troubleshooting scenarios seem to at least touch this topic.

'show mpls ldp discovery detail' can be key to uncovering these scenarios. If you see something like 'no host route to transport address' your router does not have the route to the LDP neighbors transport (or router-id) address. Check your IGP routing table.

BB1(config)#do sh mpls ldp disc det
Local LDP Identifier:
   7.7.7.7:0
   Discovery Sources:
   Interfaces:
   FastEthernet0/0 (ldp): xmit/recv
   Enabled: Interface config
   Hello interval: 5000 ms; Transport IP addr: 7.7.7.7
   LDP Id: 6.6.6.6:0
   Src IP addr: 10.1.67.6; Transport IP addr: 6.6.6.6
   Hold time: 15 sec; Proposed local/peer: 15/15 sec
   Reachable via 6.6.6.6/32

'mpls ldp holdtime 90' will set the holdtime to 90 seconds, and the keep alive to 1/3 the hold timer.

When you are filtering label advertisements, you need to first disable label advertisement with 'no mpls ldp advertise-labels'. Otherwise your filtering will have no effect. The RD will make the non-unique customer IPv4 address into a unique 96-bit unique VPNV4 address. RD does not indicate which VRF a prefix belongs to and it is NOT a vpn identifier. The route-target is a bgp extended community saying which communities will be imported or exported with the specified VRF.

I finally get and understand the sham link. I just forget to put the loopback interface in the VRF! No wonder my bgp routes didn't show up!

I am slowly starting to get this SoO stuff. It's very easy to understand, but can be a bear to construct and setup.Simply use route-maps to set and filter the SoO extended communities. Chances are if you have redundant connections, you will need to set/filter SoO.

I really enjoy Narbik's MPLS labs. Something about how the labs are constructed and how he explains it makes total sense.

Now it's off to full labs....joy, joy....

INE Workbook Vol1 Bridging/Switching

2010-06-04T11:35:00.000-04:00

'show interface [interface] pruning' will show you what vlans have been pruned from that particular interface, or all interfaces with the absence of an interface in the command. I didn't know you could set which VLANs were prune eligible...

Rack24SW1(config-if)#do sh run int f0/13
Building configuration...

Current configuration : 183 bytes
!
interface FastEthernet0/13
switchport trunk encapsulation dot1q
switchport trunk native vlan 146
switchport trunk pruning vlan 2-6,8-1001
switchport mode dynamic desirable

With QinQ tunneling, I always forget the command for l2 tunneling. It's simply the interface-level 'l2protocol-tunnel [protocol]' command. To enable QinQ tunneling, set the switch access VLAN, set the mode the dot1q tunnel and apply any applicable l2 tunneling. You may also need to set the system MTU to 1504 to accommodate the additional 4-byte dot1q tag. You may also need to disable CDP on the switch interface if you do not want the switch to show up in your CDP neighbors list.

UDLD will not by default shut-down the port and will only mark the port as 'undetermined'. Aggressive mode will err-disable the port.

Spanning tree uses the designated (upstream) port-priority as a tie breaker if the end-to-end cost is the same on multiple ports to the same upstream switch. Remember that spanning-tree cost is calculated end-to-end.

When MST is enabled, RSTP is automatically enabled. Assign 'edge' port role using 'spanning-tree portfast'.

The 'switchport priority extend [trust|cos]' will either trust the COS markings or set the COS markings for the devices attached to the appliance; ie Cisco phone. Don't confuse this with 'mls qos cos 1 and mls qos cos override' which will wipe out the phone markings.

There are several built-in switchport macros that can be applied. View with 'show parser macro' command. Cool stuff. Includes a global macro, desktop template, router, switch, phone, etc. Built-in macros can be applied like so...

Rack24SW1(config-if-range)#int fa0/10
% Command exited out of interface range and its sub-modes.
  Not executing the command for second and later interfaces
Rack24SW1(config-if)#macro appl
Rack24SW1(config-if)#macro apply cisco-desktop $access_vlan 10
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION

%Portfast has been configured on FastEthernet0/10 but will only
have effect when the interface is in a non-trunking mode.
Rack24SW1(config-if)#do sh run int fa0/10
Building configuration...

Current configuration : 332 bytes
!
interface FastEthernet0/10
switchport access vlan 10
switchport mode access
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
switchport port-security aging type inactivity
macro description cisco-desktop
spanning-tree portfast
spanning-tree bpduguard enable

Very cool. I do quite a lot of LAN refresh projects and these may just come in handy.

Flex Links use the 'backup' interface command and are pretty self explanatory. When the line protocol of the primary interface goes down, the backup interface is brought up. You can also the preemption mode, delay and other features.

SW1(config-if)#do sh run int po1
Building configuration...

Current configuration : 243 bytes
!
interface Port-channel1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport backup interface Fa0/16
switchport backup interface Fa0/16 preemption mode forced
switchport backup interface Fa0/16 preemption delay 20

I don't know why fallback bridging was always so difficult. Fallback bridging works to bridge non-ip protocols such as IPX or sometimes IPv6 (depending on switch model and SDM template). All you have to do is create the bridge, and add the interfaces to the bridge. This is even simpler than CRB or IRB.

Private VLAN are pretty self-explanatory, but can be confusing to construct. First you create and map the VLAN through vlan configuration mode, and then you need to set the private-vlan mode per interface, and create the promiscuous, host, or private vlan mapping per interface. I always forget to set the mode....

vlan 100
  private-vlan primary
  private-vlan association 1000,2000,3000
!
vlan 1000
  private-vlan community
!
vlan 2000
  private-vlan community
!
vlan 3000
  private-vlan isolated
!
interface FastEthernet0/2
switchport private-vlan host-association 100 1000
switchport mode private-vlan host
!
interface FastEthernet0/4
switchport private-vlan host-association 100 2000
switchport mode private-vlan host
!
interface FastEthernet0/6
switchport private-vlan host-association 100 3000
switchport mode private-vlan host

Verify with 'show vlan private'. A quick way to test is to ping the broadcast address, with a ping repeat of 1. You may need to do this more than once if an ARP lookup is required.

SW1(config-if)#do sh vlan priv

Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
100 1000 community Fa0/1, Fa0/3
100 2000 community Fa0/1, Fa0/5
100 3000 isolated Fa0/1

R1#ping 255.255.255.255 rep 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:

Reply to request 0 from 100.0.0.5, 4 ms
Reply to request 0 from 100.0.0.2, 4 ms
Reply to request 0 from 100.0.0.3, 4 ms
Reply to request 0 from 100.0.0.6, 4 ms
Reply to request 0 from 100.0.0.4, 4 ms

You can use a radius server for authentication without using the global radius-server command.

R4(config)#aaa group server radius TST
R4(config-sg-radius)#server-private 155.1.146.100 key CISCO

You will also see a 'server' keyword under the configuration above. This simply references the global defined 'radius-server'. Now we can attach this 'private' radius server to our PPP authentication.

aaa authentication ppp PPPAUTH group TST local
interface Serial0/1/0
ppp authentication pap chap PPPAUTH

Now our PPP authentication will use the private-radius server and local usernames as a fall-back.You can also, like other authentication mechanisms, set the default authentication.

aaa authentication ppp default group tacacs local

Ok, now something new. PPPoE. On the client side, we need to create a dialer interface, set the ip to dhcp and enter any PPP authentication information here. Then on the physical interface, we enable pppoe and attach the dialer pool. This seems pretty easy...

interface FastEthernet0/1
no ip address
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Dialer1
ip address dhcp
encapsulation ppp
dialer pool 1
ppp chap hostname R3PPP
ppp chap password 0 CISCO

Now on the server side it is a little more difficult. On the physical interface, enable pppoe and attach to the bba group (broadband aggregation - where does cisco come up with this? They couldn't use pppoe-group? Thanks Cisco for creating another useless TLA). Under the bba-group, specify the virtual-template to clone and set any session options. Now on the virtual template, set the ip address, encapsulation and authentication parameters. INE has also used a 'trick' to use DHCP to assign the IP address.

ip dhcp excluded-address 155.1.35.1 155.1.35.2
ip dhcp excluded-address 155.1.35.4 155.1.35.254
ip dhcp pool PPPOE
   network 155.1.35.0 255.255.255.0
bba-group pppoe PPPOE
virtual-template 1
sessions per-mac throttle 10 60 300
interface FastEthernet0/1.35
encapsulation dot1Q 35
pppoe enable group PPPOE
interface Virtual-Template1
ip address 155.1.35.1 255.255.255.0
ppp authentication chap PPPOE

Well, that's it for Bridging/switching as well as INE volume 1. Overall, bridging and switching was pretty easy. I mostly just picked up a few tips along the way - nothing I didn't really already know. I have really enjoyed the INE volume 1 and appreciate how they cover some topics that other vendors don't, and how they are complete and thorough. Not that other vendors are bad - and I know INE doesn't cover items that other vendors do. In short, I'm saying it's best to study with two vendors to become a fully-rounded CCIE candidate.

My only issue is how they present the scenarios - they sometimes word them in such a way that it's easy to figure out exactly what they are asking for. Well, I think that is all for today. It's been a long week and I need some R&R. Hoping to fire up the lab this weekend to do Narbik's MPLS labs, and then start on INE Volume 2 (full labs) and Volume 4 (troubleshooting). I plan to hit labs that are graded a 7 or higher. Hopefully I can cover one lab every two days to start, and squeeze in a few troubleshooting scenarios throughout the week. Then as I get closer to my date, I plan to do a full lab in a day, and alternate day-to-day between full labs and troubleshooting. Man, at least I don't have to worry about studying for the stupid OEQ too.......

INE Workbook Vol 1 MPLS

2010-06-02T13:34:00.000-04:00

Finally on to MPLS, which is the last section of Volume 1. I skipped Bridging/switching so I will need to return to that before moving on to full labs. Hopefully I can tackle both MPLS and bridging/switching this week.

The route distinguisher (RD) is a special 64-bit prefix prepended to every route in the respective VRF routing table. This avoid collisions if two VRFs contain the same prefixes. It is possible to use static routes for 'inter-VRF' communications. If you are using a static route with the interface specification, the interface could belong to any VRF. With multi-access interfaces, you will also need to specify the next-hop associated with the interface. Cisco IOS will install a CEF entry in the 'source' VRF using the information provided and will not attempt to resolve the next-hop recursively. This only works with non-recursive static routes that use directly connected interfaces.

ip vrf VPN_A
rd 100:1
ip vrf VPN_B
rd 100:2
interface FastEthernet0/0.67
encapsulation dot1Q 67
ip vrf forwarding VPN_A
ip address 155.1.67.6 255.255.255.0
interface FastEthernet0/0.76
encapsulation dot1Q 76
ip vrf forwarding VPN_B
ip address 155.1.76.6 255.255.255.0
ip route vrf VPN_A 192.168.7.0 255.255.255.0 FastEthernet0/0.76 155.1.76.7
ip route vrf VPN_B 172.16.7.0 255.255.255.0 FastEthernet0/0.67 155.1.67.7

'mpls ldp autoconfig' will activate LDP/MPLS switching on all interfaces running OSPF. You can set the LDP router-id using the command 'mpls ldp router-id force'. If you want LDP to establish a TCP connection using the physical interface IP address, use the interface command 'mpls ldp discovery transport-address interface) command. LDP neighbor sessions can be authenticated using the 'mpls ldp neighbor password command. The IP address here is the LDP router-id. To make passwords mandatory, issue 'mpls ldp password required'.

Sham links must NOT be advertised by BGP and should instead be advertised by MP-BGP. When using OSPF as the PE-CE routing protocol, area 0 is not needed because OSPF VRF routing information is passed in MP-BGP updates. The MP-BGP cloud is a special 'super backbone'.

On to EIGRP SOO...in short, this prevents MP-BGP routes from re-entering BGP when mutual redistribution between EIGRP/MP-BGP is present with backup links. If an incoming or outgoing update has the SoO value matching the locally configured one, the updated is dropped. Here are the PE configs.

R5

interface FastEthernet0/0
ip vrf forwarding VPN_A
ip vrf sitemap EIGRP_SOO
ip address 155.1.58.5 255.255.255.0
route-map EIGRP_SOO permit 10
set extcommunity soo 100:15

R6

interface FastEthernet0/0.67
encapsulation dot1Q 67
ip vrf forwarding VPN_A
ip vrf sitemap EIGRP_SOO
ip address 155.1.67.6 255.255.255.0
route-map EIGRP_SOO permit 10
set extcommunity soo 100:16

We create the simple route-map and attach it to the CE facing interfaces. Now on the CE side, we attach the same to the backup-link configuration. SW1 is attached to R6 and SW2 is attached to R5.

SW1

interface FastEthernet1/7
no switchport
ip vrf sitemap EIGRP_SOO
ip address 155.1.78.7 255.255.255.0
delay 1000
route-map EIGRP_SOO permit 10
set extcommunity soo 100:16

SW2

interface FastEthernet1/7
no switchport
ip vrf sitemap EIGRP_SOO
ip address 155.1.78.8 255.255.255.0
delay 1000
route-map EIGRP_SOO permit 10
set extcommunity soo 100:15

When using BGP as your PE-CE routing protocol, you may be required to use as-override if both CE routers are using the same AS. When the PE router gets the routes from the CE router, they won't get installed in the other CE router because it will see it's own AS in the path across a e-BGP neighbor relationship. With AS-override, the CE AS will be replaced with the MPLS 'core' AS and thus installed in the BGP/RIB.

We can also use SoO with BGP peering. Simply attach the SoO attribute to the neighbor statements on each PE.

Internet Access with MPLS is interesting. The VPN clients will need a default route. In this case (with the global routing table), we need to create a special static pointing the default route to the global routing table. If Internet access is in a different VRF, classic route export/import could be used.

ip route vrf VPN_A 0.0.0.0 0.0.0.0 54.1.1.254 global

Then we need to originate the default route to our VPN clients - in this case via BGP.

router bgp 456

address-family ipv4 vrf VPN_A
  redistribute connected
  redistribute static
  neighbor 155.1.67.7 remote-as 78
  neighbor 155.1.67.7 activate
  neighbor 155.1.67.7 as-override
  neighbor 155.1.67.7 soo 100:1
  default-information originate
  no synchronization

Now since we are doing private addressing, we need to do NAT.

interface FastEthernet0/0.67
ip vrf forwarding VPN_A
ip address 155.1.67.6 255.255.255.0
ip nat inside
ip virtual-reassembly
interface FastEthernet0/0.146
ip address 155.1.146.6 255.255.255.0
ip nat inside
ip virtual-reassembly
interface Serial0/0
ip address 54.1.1.6 255.255.255.0
ip nat outside
ip virtual-reassembly
ip nat inside source list VPN_PREFIXES interface Serial0/0 vrf VPN_A overload
ip access-list standard VPN_PREFIXES
permit 150.1.0.0 0.0.255.255

Notice the vrf keyword in the NAT statement. This ties the NAT statement to the sources addresses in that particular VRF (as there could be several VRF's with overlapping address space).

AToM is a pretty simple concept. It takes the L2 frames and encapsulates them over MPLS. The VCs must match, and you may need to provide LDP neighbor password parameters.

R5(config)#do sh run int fa0/1
interface FastEthernet0/1
no ip address
duplex auto
speed auto
xconnect 150.1.6.6 100 encapsulation mpls

R6(config)#do sh run int fa0/1
interface FastEthernet0/1
no ip address
duplex auto
speed auto
xconnect 150.1.5.5 100 encapsulation mpls

Verify with 'show mpls l2transport vc detail'

R6(config)#do sh mpls l2tra vc det
Local interface: Fa0/1 up, line protocol up, Ethernet up
  Destination address: 150.1.5.5, VC ID: 100, VC status: up
   Next hop: 155.1.146.4
   Output interface: Fa0/0.146, imposed label stack {16 21}
  Create time: 00:01:10, last status change time: 00:00:57
  Signaling protocol: LDP, peer 150.1.5.5:0 up
   MPLS VC labels: local 29, remote 21
   Group ID: local 0, remote 0
   MTU: local 1500, remote 1500
   Remote interface description:
  Sequencing: receive disabled, send disabled
  VC statistics:
   packet totals: receive 4, send 40
   byte totals: receive 595, send 3145
   packet drops: receive 0, seq error 0, send 0

Now you can configure CE devices attached to the xconnect ports and assign IP addresses. L2TPv3 is similiar to AToM except it requires more options and you must specify a pseudowire class. You must also set the local interface. Enable path-mtu-discovery with 'ip pmtu'. 'ip dfbit set' avoids in-core framentation and performation degredation. 'ip tos reflect' copies the TOS bit.

pseudowire-class L2TPV3
encapsulation l2tpv3
ip local interface Loopback0
ip pmtu
ip dfbit set
ip tos reflect
interface FastEthernet0/1
no ip address
duplex auto
speed auto
xconnect 150.1.6.6 100 encapsulation l2tpv3 pw-class L2TPV3

Verify with 'show l2tp session all'.

Well, that is all for the MPLS section. Pretty brief but there was a lot of material to cover. Hoping to cover Bridging and Switching tomorrow - or perhaps I'll fire up Narbik's MPLS lab for a different perspective. I'll see how I feel tomorrow.

INE Workbook Vol 1 IP Services

2010-05-29T11:57:00.000-04:00

The first topic is proxy arp. Pretty simple logic overall, but there was one item I didn't know about - ip local-proxy-arp. This means that the router will run proxy-arp for the locally connected segment, which isn't usually the case because they are directly connected. INE showcased this by using 'switchport protected' on the switchports to show that the only way to get the devices on VL146 to talk, was to enable local proxy-arp on one of the nodes. Now pinging between the two protected ports is possible as the one in the middle will do proxy-arp and respond with it's own mac address.

With DHCP, configure the following to disable the BOOTP server and ignore requests.

R6(config)#ip dhcp bootp ignore
R6(config)#no ip bootp server

To configure a host to use it's MAC address only as the dhcp client-id; issue the following:

R1(config)#int f0/0
R1(config-if)#ip address dhcp client-id fastEthernet 0/0

Verify with 'show dhcp lease' on the client. Remember, 01 is added to the client-id, so if your mac address was c200.05c5.0000, the client-id would be 01c2.0005.c500.00.

PPP and address assignment is still something I need to work on (including PPPoE). On the 'client' side, add 'ip address negotiated'. Optionally, you can also request the netmask and the dns addresses. With the DHCP On-Demand Pool, you can import IPCP parameters.

ip dhcp pool ODAP_POOL
   import all
   origin ipcp
interface Serial0/1
ip address negotiated
ip rip advertise 10
encapsulation ppp
no peer neighbor-route
clock rate 64000
ppp ipcp dns request
ppp ipcp mask request

On the flip side, configure the other side like so...

interface Serial1/2
ip address 155.1.13.3 255.255.255.0
ip rip advertise 10
encapsulation ppp
no peer neighbor-route
peer default ip address 155.1.13.1
serial restart-delay 0
clock rate 64000
ppp ipcp dns 155.1.146.4 155.1.146.6
ppp ipcp mask 255.255.255.0

A word of caution when doing IGP routing w/ PPP. You will obviously have a host route (unless you disable it) that will be injected into the IGP routing domain (depending on protocol and network advertisements). Also watch out since each end of the PPP link will be a /32 and the IGP neighbors will see updates that are NOT on the connected subnet.

DHCP proxy w/ PPP was interesting. On the client side, you do the same - 'ip address negotiated', again disabling the neighbor-route to preserve IGP functionality. On the 'server' side, just do a 'peer default ip address dhcp' instead of actually assigning an IP. Next, you need to create a default IP address pool using the proxy-client feature. Now tell the router where the DHCP server is located (instead of the helper-address). Everything should work, but the DHCP server will not have a route back to the host until IP is negotiated. So now you must add static routes to go around the host that will be assigned the IP address. Not really difficult, just new!

ip address-pool dhcp-proxy-client
ip dhcp-server 155.1.146.6
interface Serial1/3
ip address 155.1.23.3 255.255.255.0
ip rip advertise 10
encapsulation ppp
no peer neighbor-route
peer default ip address dhcp
serial restart-delay 0
clock rate 64000

In summary, one host can proxy requests for another. Adding this to my list of things to revisit!

On to Option 82. To enable, you must first enable globally - 'ip dhcp relay information option'. Optionally you can set the subscriber-id per link.

interface FastEthernet0/0
ip dhcp relay information option subscriber-id VLAN58
ip address 155.1.58.5 255.255.255.0
ip helper-address 150.1.6.6

On the DHCP server side, this is where 'classes' come into play. Create a class, select the relay agent information option (option 82) and then enter the HEX relay-information. How do you get the hex information? With a debug dump w/ DHCP matching ACL. Find the ASCII subscriber-id string (you did set that right?). The information option starts with decimal value 82 (hex 0x52), followed by the total option length (0x16). Following that are the suboptions. Whew. What a task...I really didn't think this would be that difficult.

ip dhcp pool VL58
   network 155.1.58.0 255.255.255.0
   default-router 155.1.58.5
   class TEST
   address range 155.1.58.8 155.1.58.8
ip dhcp class TEST
   relay agent information
   relay-information hex 020c020a00009b013a05000000000606564c414e3538

Something pretty easy - you can have DHCP update ARP. And then you can only allow authorized arp entries thus disabling dynamic ARP.

ip dhcp pool VL146
   network 155.1.146.0 255.255.255.0
   default-router 155.1.146.4 155.1.146.6
   dns-server 155.1.146.4 155.1.146.6
   lease 0 12
   update arp
ip dhcp pool R1
   host 155.1.146.11 255.255.255.0
   client-identifier 01c2.0005.c500.00
   update arp
interface FastEthernet0/0.146
encapsulation dot1Q 146
ip address 155.1.146.6 255.255.255.0
ip rip advertise 10
arp authorized

If not all hosts are DHCP, you need to statically add their ARP entries; 'arp 155.1.146.4 1234.5678.90AB.CDEF'.

IP SLA, VRRP and HSRP are all pretty simple. GLBP can be slightly more difficult, only because of the load-balancing aspect to it. The weighting always trips me up, but to do a 2:1 ratio, just do the following:

R4(config-if)#glbp 146 weighting 20
R4(config-if)#glbp 146 load-balancing weighted

R6(config-subif)#glbp 146 weighting 10
R6(config-subif)#glbp 146 load-balancing weighted

With the above configuration, you will achieve the 2:1 ratio since R4 has a higher weighting. Weighting does not affect the round-robin method or the host-dependent method.

IRDP is pretty easy, I just always forget the client command 'ip gdp irdp'. Moving on to NAT...

The NAT no-alias commands removes the proxy-arp ability from the NAT entries. When you do NAT, the router making the translations will proxy-arp for the NAT'd addresses. You can verify with the 'show ip alias' command. Adding the no-alias option means the proxy-arp will not happen, and you will not be able to ping that static TCP PAT address.

Overlapping addressing w/ NAT was interesting. The requirement said that only one host would complete NAT. So R1 was configured like so...

interface Loopback1
ip address 10.0.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
ip route 11.0.0.0 255.255.255.0 Null0
ip route 22.0.0.0 255.255.255.0 Serial0/1
!
ip nat pool NET22 22.0.0.1 22.0.0.254 prefix-length 24
ip nat inside source static network 10.0.0.0 11.0.0.0 /24
ip nat outside source list NET10 pool NET22

The static route to Null0 was required because NAT will first do a route table lookup before performing any translations. We simply translate 10.x.x.x to 11.x.x.x, and on the incoming we translate 10.x.x.x to 22.x.x.x so that R1 'hides' it's 10.x.x.x network (that overlaps with R2). So packets appear to come in with a dest of 11.0.0.1 and a source of 22.0.0.x.

On to TCP Load balancing. This requires the ip nat inside destination command. Pretty easy to understand - I can just never construct the proper NAT entries for some reason. I guess I get confused by items such as 'ip nat source' and 'ip nat inside|outside source'.

interface FastEthernet0/0
ip address 155.1.58.5 255.255.255.0
ip nat outside
interface Serial0/0
ip address 155.1.0.5 255.255.255.0
ip nat inside
ip nat pool ROTARY prefix-length 24 type rotary
address 155.1.0.1 155.1.0.1
address 155.1.0.2 155.1.0.2
address 155.1.0.3 155.1.0.3
ip nat inside destination list LOAD_BALANCE pool ROTARY
ip access-list extended LOAD_BALANCE
permit tcp any host 155.1.58.55 eq telnet

So now connecting to telnet via 155.1.58.55 will load-balance between R1, R2 and R3.

When doing stateful nat, without HSRP - configure the routers like so...

R4

ip nat Stateful id 1
  backup 155.1.146.4
   peer 155.1.146.6
   mapping-id 1
ip nat pool TST 155.1.254.1 155.1.254.254 prefix-length 24
ip nat inside source list Net155 pool TST mapping-id 1

R6

ip nat Stateful id 2
  primary 155.1.146.6
   peer 155.1.146.4
   mapping-id 1
ip nat pool TST 155.1.254.1 155.1.254.254 prefix-length 24
ip nat inside source list Net155 pool TST mapping-id 1

I always get confused between primary, backup and peer. Should each one have a primary and backup entry? Should they both include peer statements? The above configuration is correct.

I finally found the use for the NAT Virtual Interface.

R5(config)# int s0/0
R5(config-if)#ip nat enable
R5(config-if)#int s0/1
R5(config-if)#ip nat en
R5(config-if)#int f0/0
R5(config-if)#ip nat en
R5(config-if)#ip access-list st VLAN8
R5(config-std-nacl)#permit 155.1.8.0 0.0.0.255
R5(config-std-nacl)#exi
R5(config)#ip nat pool NVI_POOL 155.1.188.1 155.1.188.254 prefix-length 24
  accounting Specify the accounting
  add-route Add special route to Virtual Interface
  arp-ping WLAN ARP Ping
  type Specify the pool type


R5(config)#$ NVI_POOL 155.1.188.1 155.1.188.254 prefix-length 24 add-route
R5(config)#ip nat source list VLAN8 pool NVI_POOL
R5(config)#router rip
R5(config-router)#redistribute static metric 1

The NAT direction is always inside for NVI NAT. A routing looking is performed before the translation. After the routing decision is made, the packet source is translated and then forwarded. NVI eliminates the need for a separate static route but you still need to advertise the static into the routing domain. We also finally have a use for the 'ip nat source' command.

Extendable static NAT allows you to configure multiple static mappings for the same local or global IP address.

Well, that is it for NAT. I will say I understand NAT a lot better, and I am able to craft the solutions to the majority of the scenarios. There were some slightly tricky scenarios, but nothing really all the difficult. Moving on to the remainder of IP Services....

Ahh!!! I finally found it! How to figure out the TOS from Precedence...multiply it by 32! Precedence of 3 would be TOS 96. It's easy to turn on IP Accounting for precedence packets...'ip accounting precedence' but the regular 'show ip accounting' does not show anything. Instead you need to 'show interface s0/1 precedence'.

R6(config-if)#do sh int s0/0 prece
Serial0/0
  Input
   Precedence 6: 34 packets, 2436 bytes
  Output
   Precedence 0: 10 packets, 1040 bytes
   Precedence 3: 5 packets, 520 bytes
   Precedence 6: 38 packets, 14457 bytes

Display mac-accounting with 'sho interface fa0/0 mac-accounting'. Enable it on the interface with 'ip accounting mac in|out'.

By default, IOS routers will forward UDP packets only for the following protocols:

TACACS(not TACACS+)
TFTP
BOOTP
TIME
NETBIO NS and DG
DNS

Enable or disable with the 'ip forward-protocol udp [protocol]'. The command 'ip directed broadcast' will forward broadcast to 255.255.255.255. This can be changed with the 'ip broadcast-address x.x.x.x'.

With WCCP, the direction of the redirection indicated which traffic flows are redirected. You can exclude interface from redirection with the 'ip wccp redirect exclude in|out' interface command. You can also enable outbound ACL checks with 'ip wccp outbound-acl-check'.

For WCCP version 2 to support multicast group membership, you must enable 'ip wccp [serviceID] group-listen' on the interface.

Server Load balancing. What IOS version is this supported on? Again, across all my real and dynamips routers, I don't have the 'ip slb' command. Here are the pertinent configs for directed mode. Pretty self-explanatory.

ip slb serverfarm SERVERS

nat server (nat to the virtual IP and real IP)

predictor roundrobin (round-robin)

real 150.1.1.1 (IP address of real server)

reassign 2 (reassign to another server after x failed syn packets)

faildetect numconns 3 (detect a failed server after x number of connections)

retry 120 (retry the server after x seconds

weight 1 (round-robin weighting)

inservice (is active)

exit

real 150.1.2.2

reassign 2

faildetect numconns 3

retry 120

weight 2

inservice

exit

real 150.1.3.3

reassign 2

faildetect numconns 3

retry 120

weight 3

inservice

end

ip slb vserver VSERVER

virtual 155.1.58.55 tcp telnet

serverfarm SERVERFARM

inservice

exit

If anyone has any experience with any type of loadbalancers (cisco CSS, linux heartbeat, etc). These command should be very familiar. Verify with 'show ip slb vservers|serverfarns|reals|conns|stats'

SLB dispatched mode uses layer 2 mods only to forward packets to the real servers and does not do any layer 3 mods. The real servers are each assigned a unique IP address and share an overlapping anycast address to accept packets to the virtual server. In dispatched mode, SLB implements a load-balancing algorithm. The weight setting actually specifies the # of connections a server can accept before moving to another server in the farm.

'ip nbar custom' and 'ip nbar port-map' are the keys to creating custom classifications, including low-level byte string match.

You can modify netflow sampling to something say, one in every 10 packets using a policy.

R6(config)#flow-sampler-map SAMPLER

R6(config-sampler)#mode random one-out-of 10

R6(config-sampler)#policy-map NETFLOW_MAP

R6(config-pmap)#class class-default

R6(config-pmap-c)#netflow-sampler SAMPLER

R6(config-pmap-c)#int s0/0

R6(config-if)#no ip flow egress

R6(config-if)#service-policy output NETFLOW_MAP

The interface-level netflow configuration will override the MQC configuration so it must be disabled.

I didn't know IOS could act as an authoritive DNS server. If you know how to run a DNS server, this should be pretty easy.

ip host cisco.com ns 155.1.146.4

ip host cisco.com ns 155.1.146.6

ip host R4.cisco.com 150.1.4.4 155.1.146.4 155.1.45.4 204.12.1.4 155.1.0.4

ip host R6.cisco.com 150.1.6.6 155.1.146.6 155.1.67.6 54.1.1.6

ip dns server

ip dns primary cisco.com soa ns.cisco.com ccie.cisco.com 21600 900 7776000 86400

The following will dampen the connection to BB1 for 30 seconds after a reload.

R6(config-if)#dampening 30 1000 2000 60 restart 2000

The half time 30 seconds. The reuse penalty is 1000. The suppress penalty is 2000. The max dampen time is 60 seconds. With the 'restart' command, we can configure the penalty value following a restart; in this case - 2000. Since the half-life is 30 seconds, it will be down to 1000 after 30 seconds, which is the reuse penalty value.

Whew. Nice section, as usual I picked up on a few things, reinforced some others. Things are going well. Hopefully I can tackle MPLS and Bridging/Switching next week. I'm taking a day off tomorrow and probably Monday - I need it!

INE Workbook Vol 1 System Management

2010-05-26T11:16:00.000-04:00

The command 'logging origin-id string ' will send syslog messages with the configured name as the origin. The 'service sequence-numbers' includes sequence numbers in syslog messages. This helps prevent against tampering with stored syslog information. 'logging count' allows to count all 'notification' and above system messages to provide statistics for quick analysis of the system history. Timestamps can be configured separately for logging and debugging messages (service timestamp [debug|log] [uptime|datetime] (msec year ...).

With archive logging, you can show the output that's suitable for direct application..

sh archive log config all provisioning

You can also show the differences (+/-) between two configs, and you can show the incremental, which will again output in a direct application format.

SW1#sh archive config differences flash:initial.cfg system:running-config
Contextual Config Diffs:
+archive
+log config
+logging enable
+path tftp:155.1.58.100/sw1-config
+rollback filter adaptive
+write-memory
+time-period 1440
interface Vlan67
+ip address 155.1.76.7 255.255.255.0
+shutdown
interface Vlan67
-ip address 155.1.67.7 255.255.255.0

SW1#sh archive config incremental-diffs flash:initial.cfg
!List of Commands:
interface Vlan67
ip address 155.1.67.7 255.255.255.0
end

Very cool. With the right configuration, you could get by without Ciscoworks/rancid in a small environment.You can even do a 'configure replace' to rollback changes.

Conditional debugging. Another feature I had no idea existed. You can set a debug condition for an interface, ip, username, mac, vlan, etc. Very cool. Be careful, undebug all does not remove the conditions. You can set most TCP client parameters with the 'ip tcp' configuration. The exceptions are 'service telnet-zeroidle' - idle outgoing telnet sessions should signal the remote host to pause output. The busy message 'busy-message # message # does just that - sets the busy message when the configured host is unavailable.

On the flip side, configure 'refuse-message # Sorry, the line is already in use #' to set the busy message for the VTY line directly. You can set the session limit for the console line; 'session-limit 1'. The vacant message will display the configured output when the line is idle.

line con 0
vacant-message # Welcome to IOS#

To allow SNMP management stations to reload the device, you must enable the RW community string in addition to 'snmp-server system-shutdown' command. You can restrict access to certain MIB values using views. Simply create the view, and attach to the community string. Here we have created a view for the cisco subtree for the community PUBLIC.

snmp-server view ROVIEW cisco included
snmp-server community CISCO RW SNMP-HOSTS
snmp-server community PUBLIC view ROVIEW RO

To enable informs for a particular hosts, issue the following:

snmp-server host 155.1.146.100 inform version 2c CISCO

Traps can be configured globally or per-host, with some exceptions like snmp link up and down can only be enabled globally. The host specific configuration overrides the global snmp config. It is required to configure the 'snmp-server enable traps' and the 'snmp-server host' commands in order to send notifications.

You can set CPU and memory thresholds using the 'process cpu' and 'memory' IOS commands. When doing so, you may be required to also enable 'snmp-server enable traps cpu threshold'

memory reserve critical 512
memory free low-watermark processor 1000
process cpu threshold type total rising 50 interval 5

On to SNMPv3. For some reason, I thought this was difficult but in reality, it is not. You create groups ( attach read/write views) and add users to that group. You can do the same thing for trap hosts, NMS stations, by specifying the v3 username instead of the v1/v2c community. Great Article from Cisco on SNMPv3.

To send all debugging and high priority level messages to SNMP host, issue the following:

logging history size 100
logging history debugging
snmp-server enable traps syslog
snmp-server host 155.1.146.100 CISCO

Syslog first sends the logs to a history buffer, and then the SNMP agent replicates the messages as SNMP traps.

Now on to RMON. I have no major issues here except for absolute and delta sampling. Absolute is used for variables that increase or decrease over time and have an upper or lower bound when a log should be generated. Delta is used for variables that either constantly increase or constantly decrease. Absolute samplings would be interface queue depth, cpu, memory. Delta would be interface errors, input packets, output bytes. Remember that anytime you call a particular interface, you need to enable 'snmp-server ifindex persist'.

RSH/RCP on the IOS? Pretty cool! RSH does not use passwords, but instead an entry in the local .rhosts table. The table maps IP and username to local username and privilege level. So when asked for local username, typically you would just use the hostname.

R6:

ip rcmd rcp-enable
ip rcmd rsh-enable
ip rcmd remote-host R6 150.1.1.1 R1 enable
ip rcmd remote-host RCP 150.1.1.1 R1 enable

R1:

R1#rsh 150.1.6.6 /user R6 show run int s0/0

Building configuration...

Current configuration : 349 bytes
!
interface Serial0/0
ip address 54.1.1.6 255.255.255.0
ip hello-interval eigrp 10 5
ip hold-time eigrp 10 15
ip authentication mode eigrp 10 md5
ip authentication key-chain eigrp 10 MD5_KEYS
encapsulation frame-relay
clock rate 2000000
frame-relay map ip 54.1.1.254 101 broadcast
no frame-relay inverse-arp
frame-relay lmi-type ansi
end

R1#sh run | i ip rcmd
ip rcmd remote-username RCP
ip rcmd source-interface Loopback0

Now NTP. The part that always trips me up is NTP authentication. I finally get it. 'ntp authentication-key' simply creates the key on both masters and clients. Issue 'ntp authenticate' if you will be authenticating your time sources (ntp server, ntp broadcast/multicast, ntp peer commands). Now attach the key to the pertinent server/broadcast/multicast client statements (ntp server 1.1.1.1 key 1) and say these are trusted keys (ntp trusted-key 1). Boom! Everything should work. Verify with 'show ntp association detail'. Remember, key numbers must be the same on both master and clients.

ntp authentication-key 4 md5 062526126F615D 7
ntp authentication-key 6 md5 062526126F615F 7
ntp authentication-key 58 md5 0327723825207414 7
ntp authenticate
ntp trusted-key 4
ntp trusted-key 6
ntp clock-period 17179895
ntp source Loopback0
ntp server 150.1.4.4 key 4 prefer
ntp server 150.1.6.6 key 6

R5(config-if)#do sh ntp ass det
150.1.4.4 configured, authenticated, our_master, sane, valid, stratum 5
ref ID 127.127.7.1, time C02948F5.1BA2EA04 (00:25:25.107 UTC Fri Mar 1 2002)
...trim

150.1.6.6 configured, authenticated, insane, invalid, stratum 5
ref ID 127.127.7.1, time C0294872.9FBBF625 (00:23:14.623 UTC Fri Mar 1 2002)
...trim

Autoinstall over ethernet. The only difficult was finding out the client-id. In short, you need to enable a pool, let the client get an address, issue a 'show ip dhcp lease' to find the client ID, and then enter the client id (prepending 00 to the hex ID) in the dhcp pool. From there, you will need to run one of your routers as a DNS server, so the autoconfig host can find it's hostname as well as the hostname of the tftp server.

Autoinstall over frame-relay was not drastically different. Instead of DHCP, the client will probe the hub router for an IP. The hub will look up the map statement for that particular DLCI and hand-out the IP address configured for that map statement. From there the client will broadcast tftp requests out all available DLCIs. The staging router should either be the tftp server, or use 'ip helper-address' pointing to the actual tftp server.

You can also use RARP. Simply add a static arp entry to the RARP server, and set the rarp server address under the interface connected to the autoinstall client. Same tftp rules apply - the rarp server should be the tftp server itself, or use 'ip helper-address' pointing to actual tftp server.

Next came menus. The only two things I really need to remember here are 1) menu-exit is the command to exit from the menu and return to the shell; 2) username OPERTOR autocommand menu OPERATOR will automatically load the menu OPERATOR upon login for the user OPERATOR.

Banners can be confusing. Which banner performs what function? The MOTD banner will be shown to all connecting users. The login banner will be displayed before the username prompt. The exec banner is shown before the shell prompt and the incoming banner is used for reverse telnet connections. Special variables such as $(line) and $(hostname) can be used to create dynamic notifications. Also, you can disable banners per line.

line con 0
no motd-banner
no exec-banner

KRON was pretty simple except I didn't know you could do this...

sh running-config | redirect tftp:155.1.146.0/r4-conf

Ah! That explains a lot. So issue the following to configure KRON to save the running config to TFTP @ 155.1.146.100 daily at 8:00.

kron occurrence SAVE_DAILY at 8:00 recurring
policy-list SAVE_CONFIG
kron policy-list SAVE_CONFIG
cli show running-config | redirect tftp://155.1.146.100/r3-config

And now...EEM scripting, which I hate - simply indicated by the keyword 'scripting'. I'm no slouch when it comes to basic perl programming, grep statements, regex, etc but I am NOT a programmer. If I wanted to be a programmer, I wouldn't be worried about the damn CCIE....anyway, moving on....

The core of EEM is the EEM server that sits between the event detectors and event subscribers. There is a fixed amount of event detectors that post an event when a condition is met. They include:

CLI event detector - detects commands typed in CLI based on regex matching.
Syslog event detector - responds to syslog strings, allowing for matching on regex.
Interface Counter - responds to various interface counters that cross a threshold setting.
Counter - responds to the change of value of a generic counter.
SNMP - monitors SNMP objects and post an event upon the condition being met.
None - This is a special case. Called when a user issues 'event manager run' to execute a named EEM script/applet.
Watchdog - generates periodic timer events and allows the EEM script to be run at repeating intervals.

Event subscribers on the other hand, are defined and registered with the EEM server as applets or scripts. Applets are a simple program written using a very basic set of CLI commands that start with the 'action' keyword. Scripts are special TCL scripts written to hand the EEM events. Applets themselves are described as easy to write, yet powerful enough to perform many functions including CLI commands, e-mail generation, snmp/syslog message generation and implementing basic program logic. TCL is a full scripting language and requires more skills to develop. It would appear that the lab will focus on applets only - which is a good thing!

Every applet has a name and a detector condition defined to trigger said applet. The applet may access global variables, defined using the 'event manager environment' command or parameters passed to them by the detector. Every event detector has pre-defined variables. Documentation on writing EEM applets, which I will be reading later. You can list variables for a detector by using 'show event manager detector detailed' command.

The first scenario request that you fire an action if the interface Serial0/0 rxload goes above 60%. Interface load is gauged by 1 - 255, so 60% is 153. Here is the event:

event interface name Serial0/0 parameter rxload entry-op gt entry-val 153 entry-val-is-increment false poll-interval 60

Nothing really that difficult. We are checking a interface, named Serial0/0, checking for rxload that is greater than 153 and we are not incrementing. The actions are really simple and should be self explanatory.

event manager applet INTERFACE_LOAD

event interface name "Serial0/0" parameter rxload entry-val 153 entry-op gt entry-val-is-increment false poll-interval 60

action 0.0 cli command "enable"

action 1.0 cli command "configure terminal"

action 2.0 cli command "interface Serial0/0"

action 3.0 cli command "ip access-group CRITICAL_TRAFFIC in"

action 4.0 mail server "155.1.146.100" to "noc@INE.com" from "r5@INE.com" subject "Interface Alert" body "Interface Serial0/0 over 60% RX load"

Next up is syslog events. The tasks asks that if someone shutdown interface Serial0/0, to un-shut the interface and send an e-mail. At first I thought this would be a 'cli event' but I couldn't construct what I needed. Looking at the solution, you create a syslog event like so. Also notice the $_cli_result" variable used in the e-mail generation. NOW I know how to do that......

event manager applet INTERFACE_SHUTDOWN

event syslog pattern "Interface Serial0/0.*changed.*down"

action 1.0 cli command "enable"

action 2.0 cli command "conf t"

action 3.0 cli command "interface Serial 0/0"

action 4.0 cli command "no shutdown"

action 5.0 cli command "end"

action 6.0 cli command "show users"

action 7.0 mail server "155.1.146.100" to "admin@ine.com" from "r5@ine.com" subject "Interface Shutdown Alert" body "Interface Serial 0/0 unshut, current users $_cli_result"

Looking at that now, not really that difficult. Just a little regex matching...moving on to CLI events....and the familiar but misunderstood sync option...

When the applet event is sync, the EEM server will hold the matched CLI command execution until the script terminates. The script should return an exit value in the variable $_exit_status and this will determine whether the triggered command will run (status 1) or not (status 0). Async will let the CLI command execute and the event will be posted after that. The script cannot affect the command execution. Async CLI events require a set of additional parameters such as # of occurances and the time window for occurances. You can also use the puts action which allows displaying arbitrary text on the console, provided the script is async.

So if you need to modify the output, such as a show run, you need to set sync to yes.

event manager applet SHOW_RUN

event cli pattern "show run" sync yes

action 1.0 cli command "enable"

action 2.0 cli command "show run | exclude username"

action 3.0 puts $_cli_result

action 4.0 set $_exit_status 0

I wish I could test this, but my IOS won't let me use the action 'puts'! Additionally, some of the sytax such as event tags is not there. 12.4(15)10T on C3725. Go figure. Anyway, to explain the above - we are triggering the event based on an entered cli command; show run. Since we set sync to yes, we can modify the output - excluding usernames. The 'puts' action displays the modified output to the user. In the end, we need to set $_exit_status to 0 so that the original command 'show run' does not run. Hope that helps someone out there.

Now periodic scheduling. Pretty easy - instead of matching an event on CLI, syslog, etc - you match on a watchdog timer value and set appropriate actions. Notice the syslog action below.

event manager applet SHOW_RUN_EVERY_5min

event timer watchdog time 300

action 1.0 cli command "enable"

action 2.0 cli command "write term"

action 3.0 syslog msg "Configuration Saved"

action 4.0 mail server "155.1.146.100" to "noc@ine.com" from "r5@ine.com" subject "Configuration" body " $_cli_result"

Now on to what INE calls "Advanced Features". We need to write an applet that clears interface counters every 3 minutes, excluding Serial interfaces and account for any future interfaces added to the router. I am guessing a watchdog timer and doing some SNMP ifindex stuff...

Yay. Loops and conditional constructs. A few interesting actions...

'info type interface-name' pulls out the list of interface names in the system matching a regex
'regexp PATTERN STRING' performs regex match against a string. If there is a match, the variable $_regexp_result is set to "1". This commands takes extra arguments for extracting the matched substrings.
'continue' - starts another interation
'cli command COMMAND patter PATTERN' - allows the CLI commands that await a users response. The patter is the regex matching the command prompt.

Again, I couldn't test! I don't have a 'interface-names' info type option. Argh! I've also tried my 3640/12.4(16a) and my 2621xm/12.4(15)T13. Finally found a 2851 w/ 12.4(24)T3 that works. Are these ISR only commands?

Well, here is the config.

event manager applet CLEAR_INTERFACE

event none

action 1.0 info type interface-names regexp "Fa|Se"

action 2.0 foreach _iface "$_info_interface_names"

action 3.0 regexp ".*(Serial).*" "$_iface"

action 4.0 if $_regexp_result eq 1

action 5.0 continue

action 6.0 else

action 7.0 cli command "enable"

action 8.0 cli command "clear counters $_iface" pattern "confirm"

action 9.0 cli command "y"

action 9.1 end

action 9.2 end

To be honest, I'm not sure I could re-construct this in the lab. I'm just not a very good programmer and when you don't do things like foreach/loop logic every day, it is easy to forget. My programming days are WAY behind me.

The info type action is pretty simple. Get the interface names, and extract those with Fa|Se. Attach the result to the _iface variable. For each result, if it's a serial interface, continue to the next one. If it is not a serial, clear the counters. I can look at that and make sense of it, but to construct this in a lab would be difficult. I think this is possibly the hardest EEM applet you could expect to see on the lab, and I would put those chances very low.

Well, that is it for system management. This section was not too bad, and I now feel I have a better understanding of things such as EEM, banners and NTP. Next is IP services, MPLS and then finally Switching. I am hoping by June 4th to be done with all of Volume 1, and then start on Volume 2 full labs while mixing in Troubleshooting labs and re-visiting certain Volume 1 topics. That will give my five solid weeks of doing full labs and troubleshooting and maybe a mock lab. Feeling pretty good on my progress.

INE Workbook Vol 1 Security

2010-05-24T10:13:00.000-04:00

You can set the prompts and banners through the aaa process...

aaa authentication banner ^CWelcome Bitches!^C
aaa authentication fail-message ^C Piss off fucker - your not who you say you are!^C
aaa authentication password-prompt "Please enter your password fucker:"
aaa authentication username-prompt "Who the fuck are you:"

IOS by default do not authorize console sessions, where as Catalyst IOS always authorizes the exec shell, even the console line.

Inbound IOS UDP traceroute uses port range 33434 - 33474. Path MTU discovery uses ICMP packet-too-big. You can use 'show ip port-map' to locate common TCP/UDP port-numbers.

Reflexive access-lists used to trip me up before. I now understand them, but still have some trouble putting them together. In short, you just add a reflect [ACL_NAME] to the end of your outbound permit statements. Then on your inbound ACL, simply do a evaluate [ACL_NAME] statement. Hopefully, this will finally commit reflexive ACLs to my ROM....also, if you use reflexive ACLs, you may need to account for local traffic by either statically permitting the traffic in the inbound ACL or use local policy routing to divert the local traffic across the loopback interface and make it re-enter the router.

Ahhh....dynamic access lists. How I hate you so. First, enable absolute timeout extension.

access-list dynamic-extended

Now create an inbound ACL permitting pertinent traffic and specifying the dynamic access-list.

ip access-list extended 100
remark == Permit Telnet ==
permit tcp any any eq telnet
remark == Permit rotary line 7001 ==
permit tcp any any eq 7001
remark == Permit RIP ==
permit udp any any eq 520
remark == Dynamic ACL for WWW ==
dynamic ACCESS timeout 15 permit tcp any any eq 80
deny ip any any log

Apply the access-list.

interface FastE0/0.67
ip access-g 100 in

Now tie the username/password to the autocommand.

username ENABLE passw CISCO
username ENABLE autocommand access-enable host timeout 5

Above, the autocommand access-enable command will add the authenticated user to the dynamic access-list. The 'access-enable host timeout 5' command is hidden from the IOS parser, so commit this to memory. Without the 'host' portion, the dynamic entry will have a simply 'any any' ACL entry. Now to configure the VTY lines...

line vty 0 3
login local
line vty 0 4
rotary 1
password CISCO
login
autocommand access-enable timeout 5

Now from the above VTY config, if a user logs in with the ENABLE username on line 0 - 3, or connects via TCP 7001 with line password CISCO, they will be added to the dynamic access-list and permitted outbound WWW connections. This is really easy to understand, but hard to remember and re-assemble. In short, if you can remember the 'autocommand access-enable host timeout x' command, you can complete the dynamic access-lists. You can manually clear the dynamic entries by issuing a 'clear access-template 100 ...' command.

Packet drop with PBR is achieved by using 'set interface null0' command.

uRPF can be enabled in strict or loose mode. With strict mode (ip verify unicast source reachable-via rx) the router applies the uRPF check to the source IP address of incoming packets to ensure the source IP address matches an explicit IP route in the routing table and the next hop for this entry should point out the interface the packet was received from.

Loose mode is commonly used with more than one ISP uplink and use asymmetric routing. Loose mode (ip verify unicast source reachable-via any) checks that it has an IP route matching the source address of the packet. It does not matter whether the next hop for this route points out the receiving interface or not. uRPF can also call an access-list for packets violating the uRPF condition. You could permit exceptions, or can use the 'deny ip any any log' to log packets denied.

Access-list logged packets are process switched. To limit impact on CPU, you may want to rate-limit the amount of process-switched packets using 'ip access-list logging interval x'.

You can enable inspection of router-generated UDP traffic using the 'ip inspect name Firewall udp router-traffic' command. Traffic inspected with CBAC will be allowed through the firewall, but will be further inspected for other details. CBAC uses the ip port-map command and you can specify a host specific port map (ip port-map ftp port 80 list 98) will inspect FTP sessions to port 80 with hosts permitted by access-list 98. When the number of connections across the firewall exceeds 4000, you may want to adjust the default hash-table size to match approximately half of the maximum connections count. With 5000 sessions, the optimal hash table size would be 2048 buckets.

On to port security. The only thing that really trips me up is protect/restrict and what each mode does. One drops the offending traffic, the other drops the offending traffic and logs to syslog. How do I remember this? Think of port-security as a bouncer at a club. If the bouncer is protecting the entrance, he doesn't need to know who tries to enter, he just needs to protect. If he needs to restrict the entrance, he needs to know who is who and thus log that information. Maybe that will help someone else, or maybe I'm just "special"...moving on....with a trunk port, we can specify a total amount per physical port, as well as total amount per vlan...

switchport port-security maximum 1 vlan 146
switchport port-security maximum 1 vlan 67
switchport port-security maximum 2

You can also limit based on 'access' and 'voice' vlans.

switchport port-security maximum 1 vlan access
switchport port-security maximum 2 vlan voice

With DHCP snooping, you need to trust the DHCP servers, as well as the trunk ports to DHCP server.You can disable/ignore Option 82 by three methods.
1)Instruct IOS DHCP server to accept DHCP messages with a zero 'giaddr' using the global 'ip dhcp relay information trust-all' or the interface 'ip dhcp relay information trusted'.
2)Configure the DHCP snooping feature to not insert Option82 using 'no ip dhcp-snooping information option'.
3)Trust the port where you receive the original DHCP message.

By default, the switch does not accept DHCP packets with a non-zero 'giaddr' on untrusted ports. In addition, it does not accept DHCP packets with Option 82 on untrusted ports. This can be changed with the 'ip dhcp snooping information allow-untrusted'.

With dynamic ARP inspection, the DHCP bindings database is used by default. For static hosts, you need to configure an ARP access-lists and apply the filter.

SW-1(config)#arp access-list VLAN146

SW-1(config-arp-nacl)#permit ip host 155.1.146.1 mac host 000f.3454.a66 log
SW-1(config-arp-nacl)#permit ip host 155.1.146.4 mac host 0011.9315.78e0 log
SW-1(config)#ip arp inspection filter VLAN146 vlan 146

If there are no permit matches, and there is no explicit 'deny ip any mac any' statement, the feature also checks the DHCP bindings database. If there is a explicit deny, or the access-list has been applied with the 'static' keyword, then ARP inspection does not consult the DHCP snooping database.

To log packets matching the ARP ACL, issue an 'ip arp inspection vlan 146 logging acl-match [matchlog|none}' to enable/disable logging of ARP packets.

With catalyst switches, you can apply both ingress MAC and IP ACLs. You cannot filter IP traffic based on MAC address unless you utilize port-security. Man, do I really have to remember Ethertypes? ARP is 0x806.

Here is something I didn't know. You can attach an access-class to a username. So if you are told that a user can only connect to a specified router, issue the following..

R2(config)#access-list 100 permit ip any host 150.1.1.1
R2(config)#access-list 100 permit ip any host 155.1.146.1
R2(config)#access-list 100 permit ip any host 155.1.0.1
R2(config)#access-list 100 permit ip any host 155.1.13.1
R2(config)#access-list 100 deny tcp any any eq 80 log
R2(config)#username TELNET access-class 100

Now when user TELNET logs in to R1, he can only access R1, and any attempts to reach WWW servers will be logged. Pretty neat and simple. Just something I didn't know could be done.

Role-based CLI enhances the command authorization model and instead of using privilege levels, you define user roles. A view may be associated with a user utilizing the local database or special external AAA attribute. You must enable 'aaa new-model' for role-based access-control to work. The 'root' view always exists. You will need to switch to the root view to be able to create other views. Simply issue a 'enable view' and enter the enable password. Create a super-view (includes other views) using 'parser view SUPER super' view and attach the child views. Here is a sample...

parser view INTERFACE1
secret 5 $1$ROi5$kTuvXkskL1UlhC8EZ0BwG/
commands interface include all ip
commands configure include interface
commands exec include configure terminal
commands exec include configure
commands configure include interface FastEthernet0/0

R4#enable view INTERFACE1
Password:

R4#
*Mar 1 00:13:20.031: %PARSER-6-VIEW_SWITCH: successfully set to view 'INTERFACE1'.
R4#?
Exec commands:
  configure Enter configuration mode
  credential load the credential info from file system
  enable Turn on privileged commands
  exit Exit from the EXEC
  show Show running system information

R4#configure t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#?
Configure commands:
  do To run exec commands in config mode
  exit Exit from configure mode
  interface Select an interface to configure

R4(config)#

Moving on to Router IP traffic Export. This is something new for me. It is a feature to monitor IP traffic received or sent on any WAN or LAN interface. This allows monitoring of IP traffic on non-shared interfaces such as Frame-Relay. Really, it's pretty easy and self-explanatory.

ip traffic-export profile EXPORT
  interface FastEthernet0/0
  bidirectional
  incoming access-list Filter
  outgoing access-list Filter
  mac-address c203.05b0.0001

You can set the mode, inbound or bidir. You can also filter a subset of the incoming/outgoing traffic. Then just specify where you are exporting the traffic to (connected interface and MAC) and you are done!

Control plane policing is pretty easy if you have already done MQC policing. Match with ACLs/class-maps, police rate x pps through the policy map, and apply service policy through 'control plane' configuration mode.

Now Control Plane Protection is a whole different beast. In short, the control plane has three sub-interfaces - host, transit and cef exception. Using CPPr, you can drop, filter, police and set queue limits. This is a pretty complicated beast. You can use a class-map type port-filter to match closed ports. You can also create a class-map type queue-threshold to set queue limits. Then when you apply the service policy, you have to specify the type as well. Wow. Will need to do some additional reading on this if I have time.

Next up - Flexible Packet matching. Holy crap.....more reading, lots to learn here...moving on.

And now, zone based firewalls. This one is pretty easy to understand, you just have to put all the pieces together.A short list of steps include:

Define access-lists for traffic scopes
Defines class-maps(match protocol and optionally ACL)
Define policy-maps
Configure zones to zone-pairs, apply the policies
Assign zones to the interfaces

Meaningful names for all objects with prefixes such as ACL_, CMAP_PMAP, will allow you to easily separate the objects purpose. You can also police within the class-map, and set IOS FW type inspection parameters. You can also inspect protocol specific parameters. The basic zone-based firewall is pretty easy, but once you get into protocol parameters, it gets pretty messy. Man I hate this security stuff...if only there was a CCIE track for security professionals.....................................................

Now on to transparent firewall, which requires running a bridge group. The router can operate the bridge in two modes. Concurrent Routing and Bridging or Integrated Routing and Bridging. CRB mode allows the router to bridge frames between interfaces configured as members of a single bridge group. The router acts as a bridge for one set of interfaces, and a L3 router for the remaining interfaces. IRB mode allows configuring a special Bridge Virtual Interface for every bridge group. This represents the router as a L3 device within the bridge group. BVI is like a SVI in a layer 3 switch. You create bridges with 'bridge crb' or 'bridge irb'. In addition, with IRB, you need to add 'bridge x route ip' to route packets. Then simply add the interfaces to the bridge group by issuing 'bridge-group x'. Bridges by default will have STP disabled - enable with 'bridge x protocol IEEE'. For the transparent firewall, you may apply the classic firewall inspect rules and ACLS to the interface configured with the bridge group numbers.

To filter non-IP traffic, you need to apply a protocol-type access-list. These exist in the range 201 - 299 and permit traffic based on Ethertype of SNAP PID value. Apply with 'bridge-group x input-type-list '. Broadcast frames are subject to the transparent firewall. To permit DHCP, issue 'ip inspect l2-transparent dhcp-passthrough'. Overall, not too difficult. Create a bridge and apply firewall policies to the interfaces - inside,outside,dmz,etc.

You can also do zone-based firewall w/ transparent bridging. Good news! I was able to build the config myself. ZBF is a classic example of Narbik's 'tell a story' method. Remember the steps, and do them in the right order, and it will work every time! Now IOS IPS...

I would say the chance of actually seeing this on the lab is very small, but it is included for completeness. Here are the steps:

Download IOS IPS files
Creating IOS IPS configuration directory on flash
Configuring IOS IPS crypto key
Enabling IOS IPS
Loading IOS IPS signature package(s) to the router
Tuning signatures.

If you see this, the IPS files should already be loaded for you. You create the directory with the unix classic 'mkdir' command. The IOS crpyto key is used to verify the signatures. You simply needs to load Cisco's public key into the router. From there, you need to configure IOS IPS like so...

ip ips name [list ]

ip ips config location flash:

ip ips notify sdee

ip ips notify log

The above should be self-explanatory. The next step is to retire most IPS signuatures. Since the package is so big, the IOS will not be able to fit all signatures into memory. Retired signatures are not compiled in memory, disabled are compiled but not triggered - so it is important to retire the signatures.

ip ips signature-category

category all

retired true

exit

category ios_ips basic

retired false

exit

The above will retire all signatures, and then enable the basic IPS signatures. Now you need to apply the IPS rule to the interface.

interface FastE0/0

ip ips in

The final step is loading the IOS IPS signature package. Signatures are loaded using a special destination known as IDCONF.

copy ftp://cisco:cisco@10.0.0.100/IOS-S310-CLI.pkg idconf

This will initiate the compile process in the router memory. Use 'show ip ips signature count' to check stats on the loaded signatures. You can also tune individual signatures like so...

ip ips signature-definition

signature 2004 0

status

enabled true

retired false

exit

engine

event-action produce-alert

exit

alert-severity high

fidelity-rating 100

exit

You can also tune an entire category, use category x instead of the signature definition name above.

Finally, there is a limited Signature Event Action Processing feature. You may assign Target Value Rating to IP subnets.

ip ips event-action-rules

target-value medium target-address 150.1.2.0/24

exit

The risk-rating computation formula for attacks towards this IP subnet are 'medium'.

And with that being said, I have completed security. Overall, not too bad. I did learn a few new things, and was introduced to things I had not seen before. I will need to re-visit and read up on several items such as ZBF, Flexible Packet Matching, CPP/CPPr and Role Based CLI. In the mean time, I am moving on to system management, which will probably include my most-hated EEM.....

INE Workbook Vol 1 QoS part 2

2010-05-17T10:10:00.000-04:00

The HDLC header is 4 bytes, but complete overhead is 7 bytes per INE. Here is the verification - http://www.javvin.com/protocolHDLC.html .INE actually has an awesome graph showing WAN frame overhead. In short, F/R and HDLC are 7 bytes, whereas PPP is 9 bytes. So to calculate the priority for one VoIP call use g729a (60 byte payload) at a rate of 50pps over a HDLC serial link ....

(60 bytes + 7 bytes overhead)*(50 packets/second)*(8bits/byte) = 26800bps or ~27Kb.

Remaining bandwidth is calculated by taking the overall available bandwidth (75% by default) and subtracting the LLQ classes. I am always confused on if remaining bandwidth is calculated on interface bandwidth, or available bandwidth

To provide bandwidth guarantees while limiting traffic rate, use nested service policies. For example, to limit overall bandwidth to 512k, while providing LLQ for voice at 32k and guaranteed bandwidth for http of 256k:

policy-map CBWFQ
class VoIP
  priority 32 400
class WWW
  bandwidth 256
class class-default
  fair-queue
policy-map Shape
class class-default
  shape average 512000 10240
  service-policy CBWFQ

Now attach the root policy to the interface.

interface FastEthernet0/0.146
encapsulation dot1Q 146
ip address 155.1.146.6 255.255.255.0
ip rip advertise 10
service-policy output Shape

Pretty easy to understand, difficult to remember!! Using the above configuration, the 75% rule does not come into play and link queues (control plane traffic) no longer apply and you may wish to define a class for control plane traffic. The same procedure follows policing. When you want to police a subset of overall policed traffic, use nested policy-maps like so...

policy-map Nested
class R1WWW
   police cir 64000 bc 3200 be 4800
   conform-action set-prec-transmit 1
   exceed-action set-prec-transmit 0
   violate-action set-prec-transmit 0
class R6WWW
   police cir 64000 bc 3200 be 3800
   conform-action set-prec-transmit 1
   exceed-action set-prec-transmit 0
   violate-action set-prec-transmit 0
policy-map Police2
class WWW
   police cir 128000 bc 3200 be 4800
   conform-action transmit
   exceed-action set-prec-transmit 0
   violate-action drop
  service-policy Nested

MQC allows the nesting of up to three levels of policing.

When doing a dual-rate three-color policer, pay attention when specifying Bc and Be values in addition to the CIR and PIR values. CIR is tied to Bc values, and PIR is tied to Be values, but there are two buckets here - one for CIR and one for PIR. So if PIR is double what you've specified to CIR, your Be will be 2x the Bc value. Using 64k CIR and 128k PIR, with TC of 400ms for CIR and 200ms for PIR, I did the calculations and came up with 3200 for both answers but this is incorrect since there are two buckets. The correct answer is Bc of 3200 and Be of 6400 since you need to add to both buckets at the same time. I hope that makes sense...

Not really useful, but you can apply GTS using MQC on a frame-relay physical interface by matching f/r DLCI. Typically, I attach the service-policy to a map-class and attach the class to a particular DLCI as this give you more granular control for things such as shape adaptive.

When doing MLPPP, f/r traffic shaping is required for PVCs to provide proper QoS properties to engage at the PPP level. MLPPP requires LLQ at the virtual-interface level. LLQ is essential for interleaving since it ensures that scheduler services VoIP packets.Calculate the fragment based on the interface physical rate, not the PVC CIR.

Use QOS pre-classification when using tunnel interfaces. The service policy applied at the interface can see the tunnel encapsulated packets as they cross the interface. The physical interface policy still accounts for header overhead, thus allowing fair scheduling. Otherwise, traffic between two endpoints will be seen as a single flow. You can apply service policies on some tunnel interfaces like GRE, but not IPsec.

With RSVP, the sender sends a PATH message, asking to establish QoS-aware path downstream to the receiver. The path message contains information describing the flow the sender is going to originate. The router compares the parameters in the message with available resources, and provided everything is ok, sends the message. The receiver will respond with a reservation request message towards the sender. The receiver is responsible for requesting specific QoS properties from the network. Once the sender receives the RESV message, it can now send data. Since flows are unidirectional, two reservations must be installed.

You can simply enable rsvp on an interface with the 'ip rsvp bandwidth' command. You can also configure bandwidth parameters. The default is to use 75% of the interface bandwidth for RSVP and allow the same amount per-flow. You cannot set this higher than 75%. Man RSVP is a different beast. I don't know how many times I've read and labbed it up and I still don't get it....moving on the MLS QOS...

You can set CoS directly in the 3550 switches using the global command 'mls qos cos policy-map'. Using this feature you must set the DSCP marking and set layer 2 marking using the 'set cos' command. This simulates the pass-through feature. Set COS feature only works when you trust DSCP. You can configure 'set dscp' or 'set ip precedence' but not both.

mls qos cos policy-map
ip access-list st IP_ANY
   permit any
class-map IP_ANY
   match access-gr name IP_ANY

policy-map Classify
   class IP_ANY
   trust dscp
   set cos 2

int fa0/4
service-policy input Classify

With Per-Port Per-VLAN classification, you can match traffic classes inside specific VLANs. Typically these are used for trunk ports but can be used on access ports. You will need two-levels of class-maps. The top level will match Vlan and the 2nd class-map. The 2nd class-map will match the traffic. The policy-map will match the top level classes with respective set actions. This is with 3550. With 3560, you do Per-VLAN QoS by enabling 'mls qos vlan-based' on the physical ports and apply the service policy to the vlan SVI.

You cannot police traffic using a single-level policy-map on the 3560. You create a top-level policy with any 'set' commands or whatnot. From the top level policy, specify the 2nd level police policy.The top level applies to the VLAN globally, where the 2nd level policy may only match port ranges and applies policing to the individual ports. You can also not use class-default. You need a user-defined class to match all traffic.

I need to really remember how to do VLAN qos on the 3560. You need one class-map to match specific traffic, another top level class-map to match the vlan, and match the lower class-map. From the top level, you can use the 'set' commands, police, etc.

Input queues on the 3560 are global and based on SHared Round Robin. The logic is as follows:
1) You may configure one of the queues as priority.
2) If queue is priority, you assign it a bandwidth threshold value expressed in percents from 0% to 40%. Those percents define the amount of internal ring bandwidth available to priority queue.
3) Both Queue 1 and Queue 2 has additional SRR weights, used by the scheduler.

Service the priority queue up to the max rate, then schedule all exceeding packets using fair round robin scheduling.

Each queue has three thresholds per queue and by default, they are set to 100%. Third threshold is locked to 'queue full' and cannot be changed. You can still map DSCP and COS values to third threshold. Both queues share buffer space and you can divide it using relative weights in percent. SRR uses WTD - every queue has a # of drop thresholds and you map codepoints to these values.

You can set the buffer limits for specific minimal reserve levels. By default, queues 1 thru 4 use reserve levels 1 to 4 with a value of 100 buffers. You can alter the buffer limit for each level, and then assign queues to different levels.

mls qos min-reserve 7 170 (170 buffers to min-reserve level 7)
int fa0/4
wrr-queue min-reserve 1 7 (assign min-reserve level 7 to queue 1)

SW-4(config-if)#do sh mls qos int fa0/4 buffer
FastEthernet0/4
Minimum reserve buffer size:
100 100 100 100 100 100 170 170
Minimum reserve buffer level select:
7 2 3 8
SW-4(config-if)#

All queues configured in shaped mode have absolute weights assigned. 'srr-queue bandwidth shape '. If some weights are zero, then those queues operate in shared mode. For non-zero weights the scheduler places the respective queue in shaped mode. In shaped mode, the system limits the queue sending rate to 1/weight*interface-speed. SRR scheduler guarantees this rate to the queue. For 100mbps interface with a shaped weight of 20, the queue is shaped to 5mbps. Exceeding traffic is delayed.

All queues not configured in shaped mode operate in shared mode. 'srr-queue bandwidth share . These weights are non-zero. If shaped weight is also non-zero, the scheduler ignores the shared weight and considers it zero in bandwidth share computations. Shared queues share bandwidth remaining after the shaped queues, proportional to their configured weights.

Threshold 3 is the queue-full threshold. If you are asked drop a specific DSCP pointcode only when the queue is full, map to threshold 3. 'mls qos srr-queue output dscp-map threshold 3 46'.

You can match multiple URL strings with NBAR using regex.

match protocol http url "*.bin|*.t[ea]xt"

Well, that completes the QoS section. Overall, not too bad. If I have time I would like to revist the switching QoS section. I plan to rent some rack sessions from INE and touch the Switching volume and re-visit switching QoS in the same session. Up next is Security! I'm off again for another awesome IPexpert vSeminar!

INE Workbook Vol 1 QoS

2010-05-13T08:10:00.000-04:00

The hardware output queue is also known as the TX ring, and is configurable under the interface level 'tx-ring-limit' command. This is a FIFO queue only and is used prior to the software queue being used (hold-queue command).

HDLC header is 4 bytes.

In custom queueing, routing update packets need to be manually mapped to custom queue 0 unless the interface is running frame-relay as f/r uses the special broadcast queue for multicast routing updates. To calculate the custom queue sizes, simply divide the desired share count by the packet size, normalize by dividing each queue by the smallest packet value and round up. Now that you have your share amount, simply multiply the packet sizes by the share amount to create the queue size.

RTP Voice requires 30% of the traffic with a queue size of 60 bytes. Account for HDLC overhead for a total of 64. Divide 30/64 = .46875. To normalize we divide by the smallest amount (not shown here) of .096 giving us a result of 4.88 for RTP. Round up and you get a share count of 5. Now to enter the queue size, multiply 5 by the packet size of 64 for a result of 320.Overall, not too difficult. Just need to memorize the formula...

'show queue [interface] [slot/port] [queueID]' will show you the queue contents.

'queue-list 1 lowest-custom 2' will set the round robin scheduler to begin at queue 2 meaning both queue 0 (default priority) and queue 1 will be treated as priority queues.

IP routing updates are sent with a precedence of 6. So to prevent routing packets from being dropped using WRED, set the hold-queue size to something like 10, and set random-detect for prec 6 to something larger than your hold-queue size.

Selective Packet Discard?!? WTH is SPD?!? Well, it's the queue management technique for interface input queuing. The SPD commands are hidden, but you can view them in the running config. Here are some of the commands:

spd extended-headroom 150
spd headroom 120
ip spd mode aggressive
ip spd queue threshold minimum 75 maximum 150

This enables SPD in aggressive mode, increases the memory headroom to 150 (for IGP), increases the headroom for BGP to 120 and sets the thresholds to min 75 max 150. You also need to set the input queue on the interface to match. Aggressive mode simply means the router will drop malformed packets, instead of placing them in the hold queue.

You can create a hierarchical rate-limit structure on an interface using a 'continue' statement following the rate-limit commands.

Ah - rate limit ACLs, such a thorn in my side. Each rate-limit ACL can contain just one line. The purpose of these ACLs is to create high-performance rate-limiting configurations. The biggest point here is to remember to use rate-limit ACLs and not standard ACLs - but would standard ACLs be accepted in the lab since they would accomplish the same goal? IP Prec based rate-limit ACLs are fun because they can be based on a mask value.To start off, you have 8 possible precedence values, 0 - 7.

[p7] [p6] [p5] [p4] [p3] [p2] [p1] [p0]

So if we want to check for prec values 1,2 and 4 we would re-draw it like this.

0 0 0 1 0 1 1 0

Now you turn that binary to hex to receive a hex value of 16, and that is your mask. I always want to take the prec values, turn those into binary and then convert to hex. Another thing to remember...

I made a mistake doing frame-relay traffic shaping. I accidentally set the Be value to the rate, so for a burst of 384k with a Tc of 10, I set Be value to 3840. Wrong answer! This is EXCESS of the CIR. With a CIR of 256k, the correct answer would have been 1280. It totally makes sense, but little things like that can really screw you up in the exam.

You can change the per-VC FIFO queue depth under the map-class using the frame-relay holdq command. In addition, you can set the physical interface queue depth using the standard hold-queue command.

Legacy QoS configuration packet sizes include the full layer 2 packet length. So if you need to filter packets based on a 60 byte packet, you actually need to configure 64 bytes to account for the 4-byte cisco frame-relay header.

PVC Interface Priority Queueing can prioritize certain DLCI's over other DLCIs. First, assign a map-class to a priority queue, and then attach the map-class to the DLCI. You also need to enable PIPQ by entering 'frame-relay interface-queue priority' interface command.

You can use DLCI-based Frame Relay Priority feature to forward traffic out different DLCIs based on priority level.The command is frame-relay priorty-dlci-group [x] [high] [med] [norm] [low] where x is the list # and high, med, norm, low are queue levels that the circuits are mapped to. In short, you map priority-queues to DLCIs.

interface Serial0/1
bandwidth 128
ip address 155.1.45.4 255.255.255.0
encapsulation frame-relay
no keepalive
priority-group 1
clock rate 128000
frame-relay priority-dlci-group 1 100 200 200 200
frame-relay map ip 155.1.45.5 100 broadcast
frame-relay interface-dlci 100
frame-relay interface-dlci 200
max-reserved-bandwidth 100
priority-list 1 protocol ip high udp rip
priority-list 1 protocol ip low list 101
priority-list 1 protocol ip medium list 102
priority-list 1 protocol http normal
priority-list 1 protocol ip high lt 64
priority-list 1 queue-limit 5 40 60 80

In the above example, RIP and packets <= 64 bytes are sent out DLCI 100, all other traffic is sent out DLCI 200.

On to frame-relay switching and policing. Frame relay switching was pretty easy for me to handle. You can either use the 'connect' global command or the interface 'frame-relay route' command. Also, you can apply classes to switched PVC's - just add the keyword 'switched' to the interface-dlci command.

Know how to use both in the event you are prevented form using one of them. The policing aspect was new. This functions much like the traffic shaping. Enable policing with 'frame-relay policing'. From there you can apply map-classes to the DLCIs. The one important point is to use the 'in' keyword when performing frame-relay policing. Below are the pertinent configs.

interface Serial1/2
ip address 155.1.13.3 255.255.255.0
ip rip advertise 10
encapsulation frame-relay
serial restart-delay 0
clock rate 128000
frame-relay map ip 155.1.13.1 133 broadcast
frame-relay interface-dlci 132 switched
  class R1
  load-interval 30
frame-relay interface-dlci 133
no frame-relay inverse-arp
frame-relay intf-type dce
frame-relay route 132 interface Serial1/3 231
frame-relay policing
frame-relay congestion-management
  threshold ecn 3
  threshold de 5
!

map-class frame-relay R1
frame-relay cir in 64000
frame-relay bc in 8000
frame-relay be in 8000

Well, I think that is enough for this section. Next section will include MQC related commands.....

INE Workbook Vol 1 IPv6

2010-05-10T11:48:00.000-04:00

Unique Local Addressing replaces Site Local addresses. ULA is RFC 4193 and similar to the use of RFC1918 address space. The format is as follows:

FC00 (7 bits) + Unique ID (41 bits) + Link ID (16 bits) + Interface ID (64 bits)

FC00 is a given. The unique ID is totally random and avoids address collisions. Think of the Link ID as the subnet and the Interface as the actual IP address in IPv4 terms.

Globally Routable addresses start with the binary prefix 001 and thus encompass the range 2000 - 3FFF. Currently, only the 2001::/16 is used for allocation.

Remember that the EUI-64 address is constructed by inverting the 7th u/l bit and inserting FFEE in the middle. Mine below is a little funky because of dynamips but the concept is the same. Since we have trailing 0's, we simply end up with FFFE19:0

R1#sh int Fast0/0 | i Hardware
  Hardware is Gt96k FE, address is c200.0619.0000 (bia c200.0619.0000)
R1#sh ipv int br | s FastEthernet0/0
FastEthernet0/0 [up/up]
   FE80::C000:6FF:FE19:0
   2001:1:0:146:C000:6FF:FE19:0
R1#

You can configure specific prefixes for IPv6 neighbor discovery advertisements. By default, all prefixes are advertised. Doing so, you can configure one to disable autoconfig. Very important to remember to enable ipv6 unicast-routing and un-suppress router advertisements on ethernet interfaces.

interface FastEthernet0/0
ip address 155.1.58.5 255.255.255.0
ip rip advertise 10
speed 100
full-duplex
ipv6 address FC00:1:0:58::5/64
ipv6 address FC00:1:0:85::5/64
ipv6 nd prefix FC00:1:0:58::/64 14400 14400 no-autoconfig
ipv6 nd prefix FC00:1:0:85::/64 14400 14400
ipv6 nd ra interval 40
ipv6 nd ra lifetime 60
no ipv6 nd suppress-ra

After spending way too much time, I discovered that 'clear ipv6 route *' doesn't work for RIP like IPv4. Instead, do this.

R5(config)#do clear ipv6 rip RIPNG

...and ta-da my filtered route disappeared. Stupid things like this could really trip you up in the lab.

Interesting note that EIGRPv6 has the option 'no ipv6 next-hop-self eigrp'.This is used on the hub router and explicitly sets the next hop field in the relayed EIGRPv6 updates to the spoke's router IP address.

OEQ Alert: EIGRPv6 cannot do unequal cost load balancing based on the limitations of CEF6. You can load balance across links of different metrics, but only equally (1 to 1). You configure this just like IPv4 - using the variance command.

There are two ways to originate a default route in EIGRPv6 - using a summary address (with an automatically computed metric and an AD of 90) and using redistribute (with an AD of 170 but you can explicitly set the metric). Currently, there is no leak-map option.

With IPv6 NAT-PT, both source and destination addresses of every packet must be rewritten.A block of IPv6 addresses will represent the IPv4 address space. This block is usually /96 in length to cover all 2^32 IPv4 addresses but could otherwise be arbitrary. IPv6 NAT-PT requires 3 items:
1. Rules to translate IPv4 to IPv6
2. Rules to translate IPv6 to IPv4
3. THe /96 prefix to map the IPv4 address space to. (using ipv6 nat prefix)

So in short, enable 'ipv6 nat' under the respective interfaces, create the NAT rules, enter the nat prefix and route as appropriate.

R6(config-subif)#int f0/0.67
R6(config-subif)#ipv6 nat
R6(config-subif)#int f0/0.146
R6(config-subif)#ipv6 nat

R6(config)#ipv6 nat v6v4 source fc00:1:0:67::7 155.1.146.7
R6(config)#ipv6 nat v4v6 source 150.1.4.4 2000::9601:0404
R6(config)#ipv6 nat prefix 2000::/96

R6(config)#ipv6 router rip RIPNG
R6(config-rtr)#redistribute connected
...
SW1(config)#ipv6 route 2000::/96 fc00:1:0:67::6

Nothing really all that new here. It is just important to map the source addresses and enter the NAT prefix.

It is very important to remember IPv6 is represented in hex and not binary. So when converting 11 to binary, remember it's 11 in HEX to binary which is 17 in decimal notation.

IPv6 multicast addresses are the range FF00::/8. The first 8 bits are the multicast address, then four bits each for flags and scopes, leaving 112 bits for group ID. The first 3 flag bits are unused and set to 0. The fourth bit is the transient bit and indicates permanent or temporary. If permanent, this bit is set to 0. Examples of permanent are ff02::2 (all routers) and ff02::6(OSPF DR routers). The remaining four bits are the scope ID bits. There are 16 combinations and not all are in use.

There is no dense mode in IPv6 multicast. As soon as you type 'ipv6 multicast-routing', PIMv6 is enabled across all IPv6 capable interfaces, and must be explicitly disabled. MLD has replaced IGMP. IPv6 multicast uses tunnel to connect the router to the RP. This tunnel is only used for the registration process and then the receivers switch to the optimal path. Use 'show ipv6 pim tunnel' to view these tunnels.

'show ipv6 pim range-list' will show the mappings of RPs to the multicast group ranges.

IPv6 embedded RP gave me nothing but trouble. I just couldn't get it to work after verifying all my unicast routes, my RPF interfaces, and double-checking my configs. I guess I'll need to lab this up some more. From the multicast address ff76:0640:2001:cc1e::8, you can derive the pertinent RP address. 2001:cc1e:: will be the prefix. 0640 includes a 0, 6 is the RP interface-ID, and LL is an 8-bit prefix length, giving you an RP of 2001:cc1e::6/128. The router to be the RP must have a loopback interface with this address, and be reachable via IGP routing protocols.

FF3x::/96 is the IPv6 SSM range.

IPv6 tunnels use protocol 41 for transport. Be careful with access-lists as there is no keyword available is IOS extended access-lists.

The format of 6to4 IPv6 addresses are as follows:
2002 (16 bits):IPv4 address (32 bits):Subnet ID(16 bits):Interface ID (64 bits)

So, 150.1.3.3 becomes 2002:9601(150 = 96 hex, 01 = 1 hex):0303(3 = 3 hex, 3 = 3 hex):: From there, assign 2002:9601:303::3 to your tunnel interfaces, and use 2002:9601:303:1::3 for your loopback. Now route 2002::/16 out your tunnel interfaces and everything should fire away!

ISATAP is another automatic 6to4 tunneling mechanism. ISATAP constructs the interface ID of the IPv6 address based on the IPv4 address of a host using EUI-64 address rules. If you use prefix 2001:1:0:345::/64, then R3 will have the following IP:

2001:1:0:345:0:5efe:9601:0303/64

Since ISATAP cannot automatically extract the destination (tunnels are more for transport), you must use static routes.

Neither tunnel mechanisms are hard to complete, it's just remembering how to construct the IPv6 address. Hopefully this is something easy enough that you can look it up in the DocCD and get an easy 2 -3 points.

Well, that is it for IPv6. Overall, not too bad. There are just a few gotcha's like remembering to enable IPv6 router advertisements, and enabling eigrp under the process, creating your static routes for tunnels, etc. That is about all for my lab for today. Now I am off to prep my lab for the next section of the workbook - QoS and prepare for the IPexpert vSeminar this afternoon.

Bye Bye Open Ended Questions!

2010-05-06T11:10:00.000-04:00

EIGRP Unequal Cost Load Balancing...

2010-05-03T18:16:00.000-04:00

Sat for one of IPexpert's awesome vLecture series this morning. The topic was EIGRP and I brought up this exact scenario. Thanks to Tyson for working this up into a blog post. Very helpful.

http://blog.ipexpert.com/2010/05/03/eigrp-unequal-cost-load-balancing/

In short, the lesson is to know and memorize the formula...

(accumulated delay/10 + 10^7/bandwidth in kb) x 256 = metric

...I think I might get a blackboard and some chalk and write this formula 1,000 times.....