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.
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.
No comments:
Post a Comment