Mobile ARP

Well seeing as how I just missed a 4-point task on mobile ARP, I thought now was a good time to learn it. It's actually very simple and pretty cool once you get it working.

Topology is a little confusing so here it is in 2 parts:

PHYSICAL:

R1---CAT1===dot1q===CAT2---R8

LOGICAL:

VLAN 100---R1---R2---R5---R7---R8---VLAN 200

The task says that users on R8's LAN occasionally mover over to R1's LAN. They still need access to the network. What we do is configure R1 to listen for ARP packets from R8's subnet (VLAN 200).

We can test this by creating an SVI for VLAN 100 and giving it an IP in R8's subnet. When it tries to contact anyone, we will see a mobile route appear in R1's route table. This route then gets redistributed into the routing protocol (OSPF in this case). It appears as a /32 route so the longer match wins over any other route advertisement of VLAN 200.

All configuration is on R1:

1) CREATE THE ACL

R1(config)#access-list 8 permit 172.31.80.0 0.0.0.255


2) CONFIGURE MOBILE ARP ON INTERFACE

R1(config)#interface f0/0
R1(config-if)# ip mobile arp access-group 8


3) REDISTRIBUTE

R1(config)#router ospf 1
R1(config-router)# redistribute mobile subnets


4) VERIFY

Ceate an SVI on VLAN 100 with VLAN 200 IP address:

CAT1(config)#int vlan 100
CAT1(config-if)#ip address 172.31.80.100 255.255.255.0
CAT1(config-if)#^Z
CAT1#ping 172.31.80.8

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.80.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/219/1016 ms

Run debug and show commands on R1:

R1#debug ip mobile
IP mobility events debugging is on
Nov 29 21:17:14.138: Local MobileIP: route add 172.31.80.100

R1#show ip route mobile
172.31.0.0/16 is variably subnetted, 11 subnets, 6 masks
M 172.31.80.100/32 [3/1] via 172.31.80.100, 00:11:05, FastEthernet0/1
R1#

Traceroute shows how many hops we are actually going through:

CAT1#trace 172.31.80.8

Type escape sequence to abort.
Tracing the route to 172.31.80.8

1 172.31.10.1 4 msec 4 msec 0 msec
2 172.31.12.2 0 msec 4 msec 0 msec
3 172.31.100.5 12 msec 8 msec 12 msec
4 172.31.200.7 12 msec 8 msec 12 msec
5 172.31.78.8 12 msec * 8 msec
CAT1#

IPexpert Volume 2 Section 12 Review

I woke up late for this one but I still finished in plenty of time. Probably about 4 hours. I made some serious mistakes though that I completely overlooked. It was in the BGP section, I didn't configure a confederation...so that may have ruined 2 or 3 tasks - not real sure how to gauge the impact. You should have seen the look on my face when I saw the PG.

With that included I missed 6 tasks for about 15 points:

-8 Tasks 8.1 - 8.3
I knew we were using private AS numbers so I immediately thought configuring a confederation. However, I did not deduce that from the task requirements so I didn't bother. Reviewing it, I completely overlooked R1's task of peering with R2 is AS 200. AS 200 should have been the confederation....BIG BOOBOO. Completely unacceptable.

-4 Task 9.3 IOS Services
Completely missed this "Mobile ARP" section. I had a NAT solution that does what I thought the task asks. I have no idea how to configure mobile arp and I guess it's time to learn. I wonder if anyone even uses it...

-2 Task 11.2 DHCP
I used "no ip bootp server" for the DHCP router not respond to bootp requests. However, the answer was "ip dhcp bootp ignore"

-1 Task 14.3 Multicast
Configured MRM incorrectly. I used the DocCD for this and was what you could call "way off." It was a 1 point task and I was not too concerned.

My goal from here on out is to keep my score above 80 while improving my "process." That includes verifying everything, making notes and a point tracker, refraining from marking the actual lab docs (which I heard you cannot do), and moving through the DocCD.

Missing the BGP confederation is something that should never happen. I am lucky there were not more tasks dependent on it. Everything else was filtering of some sort. Who knows, I may have been marked of on the entire BGP section (20 points).

One thing I worry about is that I have not really been challenged during Layer 2 configurations. I pretty much breeze through VTP, trunking, and other topics, but I know there are topics that will get me (QoS, tunneling). For these I rely on the DocCD and make my own labs. That being said, Volume 1 Section 5 has an extremely difficult tunneling lab that I need to review.

BGP - Conditional route injection

Topology

R5----R7

R5 is advertising 10.34.19.0/26 to R7
Configure R7 to inject 10.34.19.48/28

1) MAKE PREFIX-LISTS

ip prefix-list EXIST seq 5 permit 10.34.19.0/26
ip prefix-list INJECT 5 permit 10.34.19.48/28
ip prefix-list SOURCE seq 5 permit 192.168.5.5/32


2) MAKE ROUTE-MAPS

route-map INJECT permit 10
set ip address prefix-list INJECT

route-map EXIST permit 10
match ip address prefix-list EXIST
match ip route-source prefix-list SOURCE


3) CONFIGURE BGP

route bgp 567
bgp inject-map INJECT exist-map EXIST


4) VERIFY

R5#show ip bgp nei 192.168.7.7 advertised-routes | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 10.34.19.0/26 192.168.2.2 0 200 0 24 1 i

R7#show ip bgp injected-paths | begin Net
Network Next Hop Metric LocPrf Weight Path
*>i10.34.19.48/28 192.168.5.5 0 200 0 24 1 i

Things to remember:

- Must use Prefix-lists, NOT ACLs
- Injected route must a subset of am aggregate already in the table
- Use "set" command for inject-map, not "match"
- I commonly forget the "prefix-list" argument when configuring the maps
- inject-map Command is a bgp command, not per-neighbor

IPexpert Volume 2 Section 11 Review

I just completed this lab in about 4 or 5 hours. I spent the first hour (before my session even started) reading the lab, redrawing the L3 topology and making a task checklist. This actually took me about a half hour. I got an estimated score of 89, missing 4 tasks for 11 points. Two were easy, but the other two...well, just proof that I need to review the DocCD :-)

Here are the misses:

-3 Task 5.4 EIGRP
Routes should be dropped from inactive neighbors in half the default time. I used hold time command, but the PG had "timers nsf route-hold 120" as the answer. I need to review NSF.

-3 Task 6.1 RIP
I forgot to enable v2-broadcast on one interface. BONEHEAD!

-1 Task 8.7 BGP
Completely misunderstood the aggregation task. BONEHEAD #2!

-4 Task 10.2 DNS
We needed to create a domain list with "ip domain list ipexpert.net". I just used the domain-name command. I am not familiar at all with how DNS resolution works on Cisco routers so I need to review this.

Over the last few months I have increased my speed and efficiency dramatically. Time does not seem to be an issue anymore. When I started studying in the spring, I was taking so long on full scale mock labs, I stopped doing them. Many commands I know by heart, but occasionally I misunderstand a question or just have the wrong command like the EIGRP section above.

Now that I have more time, I use it to prep before I start. This includes reviewing and drawing the topology. I want the processes I use on the practice lab to be just like the ones on the real lab. That way nothing is new and I can get in my comfort zone. I definitely "feel" ready for the real thing, but that doesn't mean I am.

I can still think of some topics that would give me a hard time, unfortunately I haven't seen to many of these lately...but I know they are there...waiting to get me ;-)

What I'm thankful for - CCIE study edition

In the spirit of this holiday I thought I'd make a list of things that make labbing, studying and the overall process of preparing for the CCIE Lab exam a lot easier. In no particular order:

- Vendor Wars. Great deals are among us!

- Groupstudy. It's taken some criticism lately, but it still remains the best place to brainstorm with fellow CCIE candidates and those that have already passed. And don't forget the archives!

-Ebay. Couldn't have built my lab without it!

- Debug ip packet + ACL. Excellent when you need to debug ip packet but you've got sub-second ospf hello timers. Believe me, I found out the hard way!

- Show access-lists. Easy way to see if you get a hit on an ACL

- Static routes. Just for workarounds while you get reachability in place. I had a ppp task where the router needed an address via dhcp (proxy) but the server couldn't respond unicast to the destination subnet (no route) and no routing protocols were in place yet. Remember to remove them after!

- Colored pencils for each routing protocol. I prefer light green for OSPF, dark green for EIGRP, orange for BGP, black for RIP. I only have 4 colored pencils in my apartment and I put them to good use.

- Regular expressions for parsing show commands with the include, exclude and section arguments.

- Route tagging. Really makes route redistribution a whole lot easier to deal with.

- Master Command index on the DocCD. Nothing short of a life saver sometimes :)

- Trees. A whole lot of scratch paper going on around here...

- And last but not least...Blogrolls!

Well that's my list for now. What are you thankful for?

OSPF - Lowest IP address in OSPF is used as forwarding address on ASBR

I was labbing some NSSA today and I was wondering how the OSPF ASBR chose the forward address since it seem to appear on the opposite side of traffic flow. Example:

R3----SW1----R6

SW1 is the ASBR (redistributing it's loopback). Traffic was flowing through R6, but the address pointing to R3 was the "forward address". It doesn't really matter as long as the link is in OSPF but it can impact metric calculations since SW1's interface cost to R3 will be included.

I did a short search on GS and RFC2328 but could not find anything. I had a guess it was the lowest IP in OSPF on the router and it turns out that is right:

SW1#show run | sec router ospf
router ospf 1
router-id 11.11.11.11
log-adjacency-changes
area 2 nssa
redistribute connected metric-type 1 subnets route-map con2ospf
network 2.0.0.1 0.0.0.0 area 2
network 192.168.37.7 0.0.0.0 area 2
network 192.168.67.7 0.0.0.0 area 2

SW1#show ip int bri
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.37.7 YES manual up up
FastEthernet2/0 192.168.67.7 YES manual up up
Loopback2 2.0.0.1 YES manual up up
Loopback100 100.100.100.100 YES manual up up

SW1#show ip ospf database external

OSPF Router with ID (11.11.11.11) (Process ID 1)
SW1#show ip ospf database ns
SW1#show ip ospf database nssa-external

OSPF Router with ID (11.11.11.11) (Process ID 1)

Type-7 AS External Link States (Area 2)

LS age: 243
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 100.100.100.100 (External Network Number )
Advertising Router: 11.11.11.11
LS Seq Number: 80000009
Checksum: 0x8EBF
Length: 36
Network Mask: /32
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 20
Forward Address: 2.0.0.1
External Route Tag: 0

SW1#

Routing Loop - Part I

I was reading "Optimal Routing Design" by Cisco Press today and a routing loop scenario was described (chapter 2), but they had it all wrong and screwy and it gave me a routing loop in my brain. So I wanted to actually do a similar scenario some justice. This hopefully will be first part in maybe a series of posts that deal with routing loops, since they can be real buggers.

The Topology:



The Scenario:

R2 is hub with R5 and R6 as OSPF neighbors.
R5 and R6 are also EIGRP neighbors with R7.
R7 is redistributing it's serial interface with R8 into the EIGRP domain.
R5 and R6 are mutually redistributing between OSPF and EIGRP.

If R5 and R6 redistribute OSPF into EIGRP with equal metrics, everything stabilizes, even though you have a suboptimal path. This is because External OSPF (AD=110) is preferred over External EIGRP (AD=170). So whichever device (R5 or R6) redistributes R7's serial network into OSPF first, will keep it's route via EIGRP but the other router will learn it via OSPF.

Let's take a look at R5 and R6 OSPF and EIGRP config (there both the same):

R5#show run | sec router ospf|eigrp
router eigrp 1
redistribute ospf 1 metric 1 1 1 1 1
network 150.100.0.0
no auto-summary
router ospf 1
log-adjacency-changes
redistribute eigrp 1 subnets
network 150.100.100.0 0.0.0.255 area 0
R5#

This results in the following route entries for 150.100.78.0

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 1 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:10:23 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:10:23 ago, via Serial1/0
Route metric is 20, traffic share count is 1

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:01:21 ago
Routing Descriptor Blocks:
150.100.56.7, from 150.100.56.7, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
* 150.100.56.5, from 150.100.56.5, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

R2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 76 msec 72 msec 20 msec
2 150.100.56.7 48 msec * 72 msec
R2#

Notice that R5 has learned the route via OSPF and has advertised it back into EIGRP with the same metric that R7 is originally advertising it with. R6 has installed them both. So far it's not impacting anything.

Now let's suppose we had a task that said R7 should prefer R5 to reach the OSPF domain and you must configure the solution on R5. How could we do that? We could adjust the metric when redistributing. Let's do this by increasing the bandwidth metric on R5:

R5(config)#router eigrp 1
R5(config-router)#redistribute ospf 1 metric 2 1 1 1 1

Now let's look at R6's entry:

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 1280002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.5 on FastEthernet0/0, 00:01:37 ago
Routing Descriptor Blocks:
* 150.100.56.5, from 150.100.56.5, 00:01:37 ago, via FastEthernet0/0
Route metric is 1280002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 2 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

Its' pointing back to R5!! Let's look at R5:

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 2 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:15:35 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:15:35 ago, via Serial1/0
Route metric is 20, traffic share count is 1

It's still pointing to R2!! Trace from R2:


R2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 40 msec 76 msec 16 msec
2 150.100.56.5 96 msec 28 msec 44 msec
3 150.100.100.2 44 msec 36 msec 44 msec
4 * * *
5 * * *
6 * * *

So...how would you fix it?

R5 and R6 should learn this route via EIGRP...but last time I tried you could not alter AD for specific external routes...but you can do it for OSPF.

access-list 78 permit 150.100.78.0 0.0.0.255
router ospf 1
distance 180 0.0.0.0 255.255.255.255 78

Now the OSPF route will never be preffered but we do have failover should R5 or R6 lose its LAN connection. Doing this on one side actually fixes it, but leaves R6 with a suboptimal route. I prefer to do it on both.

Final verification of the solution:

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:16 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:16 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:12 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:12 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 44 msec
150.100.100.5 104 msec
150.100.100.6 20 msec
2 150.100.56.7 56 msec * 72 msec
R2#

If you know any other scenarios, please let me know.

IPexpert Volume 2 Section 10 Review

I just completed this lab, took about 5 hours and scored pretty well. As far as I can tell I only missed 3 tasks for a total of 9 points. And the ones I missed were not that tough...

-2 Task 2.1 Switching
Didn't know the command to prevent channel misconfiguration from disabling the ports. The command is "no spanning-tree etherchannel guard-misconfig". I was looking under the errdisable commands.

-2 Task 2.2 Switching
Ports should wait 44 seconds before they forward. I set forward timer to 22, the PG said it was 12, because ports also wait max-age timer.

-5 Task 11.1 Security
Task said to allow "mail' so I allowed SMTP. The PG had POP3 as well.

The major difference between this lab and other labs were the number of sections. There was a total of 38 tasks across 13 sections. Each task had a 1 or two bullets and was usually 2 or 3 points. This is opposed to some labs where the tasks are 4 or 5 points but have several bullets of things to accomplish.

After my first read-through, I thought this would be a difficult lab but once I got started it was relatively easy. There was no multicast or IPv6 and the QoS section was really easy. The only security task was the long ACL which I missed because I only specified SMTP as "mail" instead of including POP3...oh well.

The only real challenging task was some conditional advertisement in BGP which I got real quick after browsing the DocCD. R6 was only supposed to advertise loopback 201, if 200 was shutdown. So I created an advertise-map that matched loopback 201 (via ACL), and a non-exist map that matched loopback 200 (also via ACL). This worked perfectly and I was kind of surprised I got it to work so fast, since I have had trouble in the past with bgp conditional advertisements.

Wish I had more to say at this point but it was pretty much smooth sailing. All while watching the Raiders destroy the Broncos :)

Route Redistribution - Tagging like an Expert

The inspiration for this post comes directly from IPexpert's wonderfully insane Volume 1 Section 12 Lab. THIS LAB IS INSANE. Not too bad really, but see for yourself :)

Here is the topology:


All I am going to do in this post is explain how I go about "prepping" for redistribution. These are just a random set of miscellaneous notes, in no particular order. I will number them just for identification purposes :)

Also, remember you can do ALL of this in a notepad file before you configure the routers. I try to do it like that, that way my head is truly "around" the whole scenario. Of course, there is some tweaking that will always need to be done once you do get down to business.

1) ASSIGN TAGS

First thing I like to do is think about tagging a routing domain. Remember we always drop the tag coming in so if you like to use the AD for a tag, be careful if you have multiple domains with the same protocol.

For example, if you set a tag of 110 on R4 and R7 for OSPF routes going into EIGRP. If you deny this tag from EIGRP into OSPF, you prevent R7 and R4 from learning about each other's OSPF networks. In this lab I used 110 for the R2/R4 process. And I used 115 for the R5/R6/R7 process.

Here are the tags I assigned, these were applied at the END of every redistribution route-map.

RIP = 110
OSPF AREA 0 = 110
BGP = 256
OSPF AREA 567 = 567
EIGRP 7800 = 7800
EIGRP 12348 = 12348

On R4, I might have something like this:

route-map ospf2eigrp permit 50
set tag 110

2) WHEN TO DENY TAG ON RE-ENTRY

Another thing to remember is when to deny the tag. I only deny the tag when it's entering that protocol from which it came. Unless, of course, I am specifically asked to block routes from entering a certain domain.

Example Rip routes are tagged with 120 going into OSPF (or community 120 in BGP). The only place I deny 120 from entering a routing domain is on R2 from OSPF to RIP, or BGP to RIP (matching community value, not tag).

So building on the above route-map I would have this now:

route-map ospf2eigrp deny 10
match tag 12348
route-map ospf2eigrp permit 50
set tag 110

Everything else is allowed.

3) ALLOW TAGS TO PASS THROUGH

Another thing to remember is to allow the tags to "pass through" each domain. In the above route-map, R4 removes any tags that R2 may have placed on RIP routes from R1. This prevents us from identifying and blocking the re-entry RIP routes in BGP on R2!

So on R4 we could do this:

route-map ospf2eigrp deny 10
match tag 12348
route-map ospf2eigrp permit 20
match tag 120
route-map ospf2eigrp permit 30
match tag 567
route-map ospf2eigrp permit 40
match tag 7800
route-map ospf2eigrp permit 45
match tag 115
route-map ospf2eigrp permit 50
set tag 110

Here I have "pre-identified" or "pre-classified" all the tags I want pass-through. This way we can identify the originating protocol of every route in the EIGRP 12348 domain.

4) WHEN TO CONVERT TAGS

Another note to remember is that BGP does not use tags, but it does community values to identify routes. So on R2, R5, and R6 we will need to "convert" the tag to community value. And when we redistribute the other way, we need to make a community-list to match and drop that route.

For example on R2 we set the community of OSPF routes into BGP as follows:

route-map ospf2bgp permit 50
set community 110

On R5 and R6 this community is converted to a tag as follows:

ip community-list 1 permit 110

route-map bgp2ospf permit 20
match community 1
set tag 110

Now as long as we allow this tag to pass through on R7 and R8, R4 can identify these OSPF routes so it will not redistribute them back into OSPF area 0.

5) OPTIMAL ROUTING

Lastly, we are not concerned with optimal routing here. If you are tasked with making paths optimal, you will have to work with metrics or administrative distances to do so. But that's easy right? :)

BGP - Local AS notes

Here is the topology:

R6[AS256]-----R9[AS9999]=====BB3[AS3561]

We will be looking at the BGP tables of R6 and BB3 as we test each option of the local-as neighbor configuration.

1) LOCAL-AS

R9 has local-as configured with as 19999. R6 sees routes as follows, with 19999 in between BB2 and R9 real AS number.

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999
R9#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?

BB3 sees routes from R9 in the same way, as if AS19999 was connected between itself and R9:

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 9999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 9999 256 i


2) LOCAL-AS NO-PREPEND

With the no-prepend option, R6 does not see 19999 in the path:

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999 no-prepend
R9#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?

This command has no impact on the routes BB3 receives. They look the same.

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 9999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 9999 256 i


3) LOCAL-AS NO-PREPEND REPLACE-AS

With the Replace-as, everything looks the same as the last command on R6.

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999 no-prepend replace-as
R9#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?

However on BB3 we now see a difference as 9999 is no longer in the path.

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 256 i

BGP - RIP failures and suppress-inactive

Here is the topology:

R1 [AS10] ----- R2 [AS256]------R6[AS256]

The network between R2 and R6 is 150.100.100.0/24. This network is advertised into BGP on R6 but not R2. Because this is a connected route, R2 does not install it as a BGP route. It does receive the advertisement however and propagate it to R1.

Here is the R2 config:

R2#show run | sec router bgp
router bgp 256
no synchronization
bgp log-neighbor-changes
network 150.100.25.0 mask 255.255.255.0
neighbor 150.100.12.1 remote-as 10
neighbor 150.100.100.6 remote-as 256
neighbor 150.100.100.6 route-reflector-client
no auto-summary

Here is the R6 config:

R6#show run | sec router bgp
router bgp 256
no synchronization
bgp log-neighbor-changes
network 150.100.69.0 mask 255.255.255.0
network 150.100.96.0 mask 255.255.255.0
network 150.100.100.0 mask 255.255.255.0
neighbor 150.100.100.2 remote-as 256
no auto-summary

Here is R2's BGP table:

R2#show ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 150.100.25.0/24 0.0.0.0 0 32768 i
*>i150.100.69.0/24 150.100.100.6 0 100 0 i
*>i150.100.96.0/24 150.100.100.6 0 100 0 i
r>i150.100.100.0/24 150.100.100.6 0 100 0 i

Notice the last entry has an 'r' next to it. This is not installed in the route table as a BGP route. It is already installed as connected. This is known as a RIB failure.

But the route is advertised to R1:

R1#show ip route bgp
150.100.0.0/16 is variably subnetted, 7 subnets, 2 masks
B 150.100.96.0/24 [20/0] via 150.100.12.2, 00:05:25
B 150.100.100.0/24 [20/0] via 150.100.12.2, 00:05:25
B 150.100.69.0/24 [20/0] via 150.100.12.2, 00:05:25
B 150.100.25.0/24 [20/0] via 150.100.12.2, 00:05:25

Now here's the tricky part. You can use the BGP suppress-inactive command to prevent RIB failures from getting advertised. But when I use it on R2 and R6 it doesn't work quite like I expected.

R2#show run | inc inac
bgp suppress-inactive
R2#

R6#show run | inc inac
bgp suppress-inactive
R6#

Notice here that R1 still has the 150.100.100.0 route from R2:

R1#clear ip bgp *
R1#
*Nov 23 13:59:37.379: %BGP-5-ADJCHANGE: neighbor 150.100.12.2 Down User reset
*Nov 23 13:59:38.039: %BGP-5-ADJCHANGE: neighbor 150.100.12.2 Up
R1#
R1#show ip bgp
BGP table version is 5, local router ID is 200.0.3.1
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
*> 150.100.25.0/24 150.100.12.2 0 0 256 i
*> 150.100.69.0/24 150.100.12.2 0 256 i
*> 150.100.96.0/24 150.100.12.2 0 256 i
*> 150.100.100.0/24 150.100.12.2 0 256 i

Anybody know how this command is supposed to work in preventing RIB failures from getting advertised in BGP?

Traffic Shaping - "Peak" sets target rate higher than "Average"

Here is my topology:

R1----R3----[LAN with R4 and R5]

R4 and R5 are sending traffic to R1's loopback 1.1.1.1
R3 has the following configuration:

! ACLs to match R4 and R5:
!
access-list 4 permit 172.12.34.4
access-list 5 permit 172.12.34.5
!
! Classes that match R4 and R5:
!
class-map match-all R4
match access-group 4
class-map match-all R5
match access-group 5
!
! Policy that uses "peak" for R5, "average" for R4
!
policy-map SHAPER
class R5
bandwidth 100
shape peak 128000
class R4
bandwidth 100
shape average 128000
!
! Policy applied outbound toward R1
!
interface FastEthernet0/0
ip address 172.12.123.3 255.255.255.0
load-interval 30
speed 100
full-duplex
service-policy output SHAPER

This has been running for about 10-15 minutes. R4 seems to be shaped as normal around 128k. R5 though is hitting 180k.

R3#show policy-map interface
FastEthernet0/0

Service-policy output: SHAPER

Class-map: R5 (match-all)
14826 packets, 20963964 bytes
30 second offered rate 181000 bps, drop rate 0 bps
Match: access-group 5
Queueing
Output Queue: Conversation 265
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 833/1177862
(depth/total drops/no-buffer drops) 0/0/0
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
256000/128000 1984 7936 7936 62 1984

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 14826 20963964 831 1175034 no

Class-map: R4 (match-all)
10214 packets, 14442596 bytes
30 second offered rate 124000 bps, drop rate 0 bps
Match: access-group 4
Queueing
Output Queue: Conversation 266
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 5221/7382494
(depth/total drops/no-buffer drops) 0/0/0
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/128000 1984 7936 7936 62 992

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 1 10213 14441182 5221 7382494 yes

Class-map: class-default (match-any)
226 packets, 22043 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any


But if you look in the output above you can see that the Target/Average rate for R5 is set to 256000/128000. Nowhere did I specify 256000. By using shape peak 128000, this was configured for me. What's more is that my traffic rate never reaches 256000. This is because there is congestion on the interface and R4 is also sending traffic. If I stop R4 from sending this is what I will have:

R3#show policy-map interface
FastEthernet0/0

Service-policy output: SHAPER

Class-map: R5 (match-all)
23779 packets, 33623506 bytes
30 second offered rate 241000 bps, drop rate 0 bps
Match: access-group 5
Queueing
Output Queue: Conversation 265
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 2859/4042626
(depth/total drops/no-buffer drops) 0/0/0
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
256000/128000 1984 7936 7936 62 1984

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 23779 33623506 2853 4034142 yes

Class-map: R4 (match-all)
12499 packets, 17673586 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group 4
Queueing
Output Queue: Conversation 266
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 6393/9039702
(depth/total drops/no-buffer drops) 0/0/0
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/128000 1984 7936 7936 62 992

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 12499 17673586 6392 9038288 no

Class-map: class-default (match-any)
328 packets, 32056 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

I never quite reach 256000, but I am getting close and hover around 241000 to 246000 consistently.

Still researching why the target rate is 256000...if anyone knows, please leave comment!

* * * * * U P D A T E ! ! ! * * * * *

This is a flash update, I think I have a better understanding of this now. For some reason I was thinking the values after "peak" was different than the value after "average". They are both CIR! This will always be the "average rate". You target rate will be set using default values if you do not specify a Be. And it appears Be = Bc by default.

R3(config-pmap-c)#shape ?
average configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]], send out Bc only per interval
peak configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]], send out Bc+Be per interval

So if you want a peak rate of 512000, there are multiple things you can configure since you are sending Bc+Be every interval. In fact you can:

1) set peak to 512000, Bc to 5120, Be of 0
2) set peak to 384000, Bc to 3840, Be to 1280
3) set peak to 256000, Bc to 2560, Be to 2560

All of these (and many more combinations) set target rate to 512000.

IPexpert Volume 3 Mock Lab 2 Review

What a ride it has been since my last mock lab. For those that were not following then I scored a 41 with a veritable plethora of bonehead mistakes. This was a few months ago I think. Today I just finished lab 2 and got a 73. The grading script was incorrect on my multicast section so I actually got a 78. Plus my DHCP excluded address range ended with .255 instead of .254 so I might have had 3 more points on the real thing. Also my IPv6 RIP failover solution worked (ipv6ip tunnels), I think the grading script didn't wait long enough for convergence to happen.

Anyways, it was a good confidence booster. I managed my time well. I skipped tasks that were not easily doable, then came back and did them when I had time. I kept track of all my points on a sheet and I figured I was good for about 81. It was pretty accurate score keeping considering if you give me the multicast and dhcp tasks that's exactly the score I would have had.

Here is a little review of the misses:

-3 6.3 DHCP
I put ip dhcp excluded-address 142.42.27.128 142.42.27.255 but the answer had .254 on the end.

-4 3.3 OSPF
I use nssa no-summary to generate a default into OSPF. The answer was supposed to be nssa default-information-originate.

-7 3.2,3.4 RIP EIGRP Filtering
I couldn't figure out the ACL with the least amount of lines for both these tasks. It was a tough one. The ACL had to be 4 lines at most and only allow routes with a 3rd octet of 25-45. I haven't looked at the SG yet so I don't know what the answer is. I skipped both these.

-4 7.2 IPv6
According to the SG, "R5 Should still be able to ping 2001:1::1 2001:4::4 2001:5::5 2001:6::6 with its Fa0/0 Interface Shutdown." This does work! I don't know how long it's waiting to ping, but it's not long enough. My configuration works.

-5 5.1 MULTICAST
The SG was wrong. The task said to configure R2 with priority of 10 and R7 with 20. The grading script has it backwards. I have since found out that the workbook was updated and I was using a printed copy from a couple months ago. No sweat I had the task right.

-4 8.2 QOS
Worst QOS task ever. It was just too many freaking lines.

I still have 45 minutes in my lab left but I am pretty much beat today. I'm gonna get back to volume 2 the next few weeks and review volume 1 too. Next graded lab will probably be in a month or so.

Redistribution filtering with distribute list

This command still gets me because of the "out" keyword but here is it how it works. It might help to remember there is no "in" keyword when you filter from a routing process.

Topology:

R1---OSPF---R2---OSPF---R5---EIGRP---R6---EIGRP---R9

R9 has loopback 9.9.9.9
R2 has loopback 2.2.2.2

We will filter these routes during redistribution but allow all others.

Will start by filtering R9's loopback from EIGRP to OSPF. On R5 we create the prefix-list:

R5(config)#ip prefix-list BLOCK9 deny 9.9.9.9/32
R5(config)#ip prefix-list BLOCK9 permit 0.0.0.0/0 le 32

Then we apply it under the OSPF process. I know it looks weird but just remember there is no "in" direction when you filter this way.

R5(config)#router ospf 1
R5(config-router)#distribute-list prefix BLOCK9 out eigrp 1

Lets' check R2, notice we see R6's loopback but not R9's

R2#show ip route | inc E2
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2 6.6.6.6 [110/20] via 150.100.100.5, 00:00:11, Serial1/0.2
O E2 150.100.69.0/24 [110/20] via 150.100.100.5, 00:07:51, Serial1/0.2
O E2 150.100.56.0/24 [110/20] via 150.100.100.5, 00:07:51, Serial1/0.2

Now let's do the other direction. First Let's check R9's table:

R9#show ip route | inc EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
D EX 1.1.1.1 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 2.2.2.2 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 4.4.4.4 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 192.168.100.2 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 150.100.100.2/32
D EX 150.100.24.0/24 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 150.100.12.0/24 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1

Configure R5. remember this blocks FROM ospf process 1:

R5(config)#ip prefix-list BLOCK2 seq 5 deny 2.2.2.2/32
R5(config)#ip prefix-list BLOCK2 seq 10 permit 0.0.0.0/0 le 32
R5(config)#router eigrp 1
R5(config-router)#distribute-list prefix BLOCK2 out ospf 1

The neighbors will resync:

*Mar 1 00:20:38.571: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 150.100.56.6 (FastEthernet0/0) is resync: route configuration changed

Now check R9 and R2's loopback has been filtered:

R9#show ip route | inc EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
D EX 1.1.1.1 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 4.4.4.4 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 192.168.100.2 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 150.100.100.2/32
D EX 150.100.24.0/24 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 150.100.12.0/24 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1

Quick way to see who if you are STP root for a VLAN

I had a task to configure SW1 as root for even vlans and SW2 as root for odd vlans. Here is the way I parsed the "show spanning-tree" command:

Rack1SW1#show spanning-tree | inc VLAN|This
VLAN0001
VLAN0003
VLAN0004
This bridge is the root
VLAN0005
VLAN0007
VLAN0017
VLAN0023
VLAN0028
This bridge is the root
VLAN0038
This bridge is the root
VLAN0056
This bridge is the root
Rack1SW1#

IPexpert Volume 2 Section 9 Review

This was my second lab of the day and I stunk it up. I don't know what it was, but I just could not get off the ground on this thing. This is the type of stuff that worries me when the exam comes around. Not getting pass the L2 stuff can just kill you. Sometimes I read to much into crap.

I always think etherchannels have to be more than 1 port...they don't have to be. If the task says "show int trunk" can only show port-channels and you have a single link in there, make it a port-channel dammit!

Here are the screw-ups:

-4 task 1.1. A tricky question. There is an unused gig port that needed to be set up as a port-channel and trunk link. Without it you didn't have L2 connectivity between all the switches. I looked in the PG.

-3 task 1.2. I couldn't this task to work without messing up another. Turns out you had to use a voice vlan instead of a trunk port. I cheated so I could continue, it was affecting reachability. As you can see, I didn't get off to a great start on this one.

-4 task 3.3. Made an error on the ospf timers throttle command. I used msec values instead of sec. BONEHEAD!

-4 task 6.2. Didn't apply ACL to all required interfaces. The task was to allow only certain devices to sync via NTP. Access-group was not allowed so you needed to configure an extended ACL and apply it to the interfaces. I didn't put an ACL on one interface of R1 and R2 each.

-4 task 7.1. Couldn't get Hierarchical MQC to work. I really had this one, but the commands were giving me IOS errors about needing certain things. We needed to police http video to 200k while giving normal http 20% bandwidth. I think my problem was I had "bandwidth 200" configured under the video class which screwed things up later in the road. All I needed was "police 200000" under it.

-3 task 8.1. Didn't block ICMP from other hosts besides the loopbacks. I thought something was funny when I had a permit ip any any after another permit statement. For future reference, if you have a "permit ip any any" after another permit statement, you are probably forgetting to deny something!

-4 task 8.2. I had everything on this task but transport input none on vty 5 through 15. Stuff like this kills me.

-3 task 8.3. Didn't apply control policing on outbound direction. I only did it inbound. Why? I don't know.

This is probably the last time I do two full-scale practice labs in one day. It's doable I just feel like I let myself down and my brain is fried. There is at least 20 points up there that I should NOT have missed. No excuses whatsoever. I missed the first 2 tasks and the last 3 for 17 total points.

It all comes down to planning your attack at the beginning, following through with that plan and finishing strong. A clear mind and stamina are two things I did NOT have on this lab. If you have these issues, I suggest you address them. Fortunately, I believe practice labs are the way to do this :)

Now for the optimistic part of the post. To be honest the first 7 or 8 labs of volume 2 were kind of easy, very cut and dry. This one was a real test. I felt good reading the solution guide knowing that I fully understood where they were coming from. Even though I haven't taken the real thing yet, I expect this type of situation. You HAVE to think outside of the box. If the rest of Volume 2 is like this, I think I shall be well prepared.

IPexpert Volume 2 Section 7 Review

I skipped this lab by accident last week so here is the review today. I just finished it in about 4 hours and change. There was nothing at all too difficult. In fact there was no QoS, Security or Multicast at all. Three of my favorite subjects! ;-)

I think I only missed a few tasks, although there was some issues I had with the PG regarding route redistribution. I am waiting on a reply from onlinestudylist to see if in fact there was an issue or if I am just mistaken. The issue had to do with redistributing OSPF into RIP version 1 and the networks weren't being advertised because of this...anyways, more on that later. Here are the mistakes I did make:

-3 task 1.4. Didn't configure max-age so switches would detect loss of link quicker than normal. I thought I could change the mode to rapid-pvst but this didn't change the max-age. Looks like I need a refresher on STP.

-2 task 3.2. Configured distance on wrong router. Task said RIP routes received by R2 should have AD of 105, I read it wrong as "from R2" so I configured R4. Bonehead mistake.

-3 task 5.4. Didn't configure passive interfaces. Bonehead mistake. Plus the redistribution issues I mentioned earlier were part of this task. If you're gonna miss a task, might as well miss the whole damn thing!

-3 task 9.2. Forget the word "errors" at the end of the logging command. I think the default is level 7 "debugging" so I should have got this one.

Well not too shabby. The BGP section had a lot of points but was rather easy. The IGP section was also pretty much a breeze. Good way to start a weekend I guess :)

Logging XML - A short DocCD adventure

I had a task today in IPexpert volume 2 section 7 that asked me to configure R5 such that while I am telnetted into it, it will display error messages in XML. huh?

I had no idea what command this was and while it turned out to be simple here's how I found it:

1. Main DocCD URL:
http://www.cisco.com/web/psa/products/index.html

2. Select Cisco IOS Software > 12.4 > 12.4 Mainline

3. Master Index

4. Cisco IOS Master Command List, All Releases

5. Now here is where I used the browser search to look for XML in EACH page (didn't take but 1 minute). By the time I go to section labeled "is-type through mwi-server" I had found the following commands:

logging buffered xml
logging console xml
logging monitor xml

Which one is it? Well it's not buffered because we want the logs displayed on the screen. And it's probably not console because we are going to be logged in through the vty. So I used the logging monitor xml and then test:

R5(config)#logging monitor xml

From any other router:

R1#
R1#telnet 192.168.5.5
Trying 192.168.5.5 ... Open


User Access Verification

Password:
R5>en
Password:
R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#int f0/1
R5(config-if)#shut
R5(config-if)#

hmm...nothing...oh wait!

R5(config-if)#
R5(config-if)#exit
R5(config)#exit
R5#term mon
R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#int f0/1
R5(config-if)#no shut
R5(config-if)#
LINK3UPDOWN*Nov 8 20:07:21.098FastEthernet0/1up

That's better!

Some VTP Stuff

Here are some random things I labbed and debugged while configuring VTP.

Topology:

SW4 === SW3 === SW2

SW4 = VTP server
SW3 = VTP transparent
SW2 = VTP client

1) If VTP domain names don't match, then trunk cannot be negotiated:

This is on R3 and R4 while domain names were different, Trunk links were in "dynamic desirable" mode.

12:29:06: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/23 because of VTP domain mismatch.
12:29:06: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/24 because of VTP domain mismatch.

And on R4:

IPeCat4#show int trunk

So we statically configure trunking both sides (or change domain names...more on that later)

IPeCat3(config)#int rang f0/23 - 24
IPeCat3(config-if-range)#sw mo trunk
IPeCat3(config-if-range)#int po 34
% Command exited out of interface range and its sub-modes.
Not executing the command for second and later interfaces
IPeCat3(config-if)#sw mo trunk
IPeCat3(config-if)#

IPeCat3#show int trunk

Port Mode Encapsulation Status Native vlan
Po34 on 802.1q trunking 100

2) Debugging VTP

IPeCat3#debug sw-?
sw-ip-admission sw-vlan

IPeCat3#debug sw-vlan ?
badpmcookies vlan manager incidents of bad PM (Port Manager) cookies
cfg-vlan config vlan
events vlan manager events
ifs vlan manager ifs error tests
management vlan manager management of internal vlans
mapping vlan mapping
notification vlan manager notifications
packets vlan manager packets
redundancy VTP VLAN redundancy
registries vlan manager registries
vtp vtp protocol debugging

IPeCat3#debug sw-vlan vtp ?
events vtp events
packets vtp packets
pruning vtp pruning events
redundancy vtp redundancy
xmit vtp packets transmitted

3) Domain must match for vtp packets to pass through

IPeCat4(config)#vlan 420
IPeCat4(config-vlan)#exit

SW3 denies it:

IPeCat3#
12:34:48: VTP LOG RUNTIME: Dropping packet received on trunk Po34 - not in domain ipexpert
12:34:48: VTP LOG RUNTIME: Dropping packet received on trunk Po34 - not in domain ipexpert
IPeCat3#

SW2 does not know about the VLAN now:

IPeCat2#show vlan id 420
VLAN id 420 not found in current VLAN database
IPeCat2#

We must change domain name on SW3:

IPeCat3(config)#vtp domain ipexpert
Changing VTP domain name from wrong to ipexpert
IPeCat3#show vtp sta | inc Domain
VTP Domain Name : ipexpert
IPeCat3#

(This takes while)

12:37:55: VTP LOG RUNTIME: Relaying packet received on trunk Po34 - in TRANSPARENT MODE (nc = false)
12:37:55: VTP LOG RUNTIME: Relaying packet received on trunk Po34 - in TRANSPARENT MODE (nc = false)

SW2 has the vlan now:

IPeCat2#show vlan | inc 420
420 VLAN0420 active
420 enet 100420 1500 - - - - - 0 0
IPeCat2#

IPexpert Volume 2 Section 8 Review

I just completed this lab. It took me awhile because I was taking breaks watching Tennessee remain unbeaten, and Miami beat up Denver. I accidentally skipped lab 7 by the way, so I will do that one next weekend hopefully. This lab had some neat redistribution issues which I am getting better at fixing on the fly. I always tag and drop first when redistributing. Then alter distances based on what routing protocol should be used to reach certain networks.

Here are the mistakes I made on this lab:

-3 task 3.2. Didn't use rip triggered on R4 because serial interface was multipoint. Should have made a point-to-point subinterface on R4.

-3 task 5.2. Confused about the IP address, thought it was R8's loopback, but it wasn't. You need to configure static RP override as well as bidir PIM.

-3 task 6.4. Forgot to allow 127.127.7.1 in the NTP Acl. This caused R1 to lose sync with itself and it can't be master or serve time requests. I hadn't bothered to re-verify later in the lab that R2 was still synced. This is a good lesson learned.

-3 task 6.2. Couldn't find the DHCP options for TFTP. (They are 66 and 150 - thanks to the peeps on GS for the links)

-3 task 6.3. It was a NAT questions - I couldn't even figure out what they wanted. I knew there was a secondary address, but the task said "Configure support for a new network." Configure support? WTF. Anyways I was suppose to create a NAT rule for this new network.

-3 task 8.3. Didn't configure the Be parameter in FRTS. The task said to configure FRTS with CIR of 64k, ac "access-rate" of 96 and Tc of 20 ms. Easy one but I didn't equate access-rate with Be. If I knew that I would have had the Be right. Bc was 1280 so Be was 640. I guess what they are saying is you can burst up to your access-rate which is what most frame providers allow you to do.

-3 task 8.5. This task is ridiculous. It says to configure flow-based wred. Then give EF packets a min threshold of 65, max threshold of 80, then a MPD of...yeah right. You can only flow-based wred or dscp-based. NOT BOTH. Then it says configure the MPD so that packets are twice as likely to be dropped...twice as likely as what?!

Another tasked asked me to enable telnet to the switches, but prevent telnet out. I created an ACL to deny any, then applied it as an access-class outbound. This worked, but the PG used "transport output none" which is a much cleaner solution I presume.

I booked back to back session for today. I like to take my time sometimes while reading DocCD and trying to gain a really in-depth understanding of the solutions. I have about 4 hours left so maybe another post or 2 will come out of it.

IPv6: RIPng, traffic filters and split horizon

R5, R6 and R7 all sit on the same LAN. R6 is also connected to R9. R5 must see this network between R6 and R9 with a next hop of R7, not R6. How can we do it?

Well first we need to disable split horizon on R7. For IPv6 RIP, this is done under the routing process:

IPeR7(config)#ipv6 router rip RIP6
IPeR7(config-rtr)#no split-horizon

Next we need to filter routing updates from R6. What do these RIPng packets look like? We can see through "debug ipv6 rip."

IPeR5#debug ipv6 rip
RIP Routing Protocol debugging is on
IPeR5#
*Nov 3 00:45:44.453: RIPng: response received from FE80::6 on FastEthernet0/0 for RIP6
*Nov 3 00:45:44.453: src=FE80::6 (FastEthernet0/0)
*Nov 3 00:45:44.453: dst=FF02::9
*Nov 3 00:45:44.453: sport=521, dport=521, length=52
*Nov 3 00:45:44.453: command=2, version=1, mbz=0, #rte=2
*Nov 3 00:45:44.453: tag=0, metric=1, prefix=2001:200::/64
*Nov 3 00:45:44.453: tag=0, metric=1, prefix=2001:96::/64

Now we know the source and destination, we can create our filter:

IPeR5(config)#ipv6 access-list RIP-FILTER
IPeR5(config-ipv6-acl)#deny ipv6 FE80::6/128 FF02::9/128
IPeR5(config-ipv6-acl)#permit ipv6 any any
IPeR5(config-ipv6-acl)#int f0/0
IPeR5(config-if)#ipv6 access-group RIP-FILTER in
^
% Invalid input detected at '^' marker.

Whoa! what gives!? This stupid things doesn't let me apply my ACL.

IPeR5(config-if)#ipv6 acc?
% Unrecognized command

Well that's because traffic filtering in IPv6 uses a whole different syntax:

IPeR5(config-if)#ipv6 traffic-filter RIP-FILTER in
IPeR5(config-if)#

BAM!

Let's clear the route table then check our next hop:

IPeR5#show ipv6 route rip | sec exclude Codes:
IPv6 Routing Table - 7 entries
R 2001:96::/64 [120/3]
via FE80::7, FastEthernet0/0
IPeR5#