INE Workbook Vol 2 Lab 8

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

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

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

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

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:

1. 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). 
2. 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..
3. 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

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

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

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

'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

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.