IOS Gotcha : Copying configs to flash

This is a particularly nasty gotcha if it getscha.  My lab consists mainly of a stack of six 2611XM routers with various WICs and NMs.  Because they are the XM model, there is plenty of room left over in the flash.   I like to use that to keep copies of all the lab configs, so that I can go back to them quickly.  It can restore the configs of an old lab to the whole stack and have it up and running within 15 minutes.  This is me saving the config of NMC Lab 11:

R3#copy run Lab11.R3.cfg
Destination filename [Lab11.R3.cfg]?
Erase flash: before copying? [confirm]n
Verifying checksum...  OK (0xF433)
4701 bytes copied in 11.611 secs (405 bytes/sec)
R3#

Why oh why is the default to erase the flash before copying?  One slip of the finger, one ENTER too many, and not only have I lost all my library of lab configs, but I have to re-install the IOS as well.  Luckily I keep copies of the configs on my PC as well (by logging the console and doing a term len 0 and a show run) but that does make the process of saving the lab rather longer.

NMC Lab 11 : Redistribution

Here is my redistribution diagram:

 It looks complicated, but in fact it isn’t.  It looks complicated ‘cos I added a lot of information to the diagram as I want along.

Since this lab contains multiple loops and no less than four active redistribution points, we have to be careful with filtering and Administrative Distances.   I look at the filtering first, which prefixes get passed from which domain to which other, then I look at the Administrative Distance to control which routes are preferred at the border routers.  I prefer not to rely on AD to control redistribution; I find the filtering tools such as route maps are better for that.  AD is only relevant at border routers, and I use it to control forwarding preferences.

Controlling redistribution with tags 

Everything gets tagged as it is redistributed, to say where it originally came from.  Once a prefix is tagged, it usually keeps its tag, even through subsequent redistributions.  That way, I can base my filters on the tags.  Any prefix that is not yet tagged must be internal to the domain we are in.  (I use that property later to distinguish RIP native prefixes, rather than have to list them explicitly.)  Here are the tags I have used in this lab:

• Tag 12 = EIGRP 12 native prefixes
• Tag 34 = EIGRP 34 native prefixes
• Tag 110 = OSPF native prefixes
• Tag 120 = RIP native prefixes

Routing domains

Looking at the diagram, we have two transit domains (RIP and OSPF) and two edge domains (EIGRP 10 and EIGRP 34). 

The edge domains only have to send out their native prefixes into the RIP and OSPF.  At first, they will only receive prefixes that are not their own natives.  (Later, I shall look at the possibility of them receiving their own fed-back prefixes to repair them if they are broken.)

Traffic between the edge domains will pass through either RIP or OSPF.  RIP and OSPF will have to pass prefixes through from one edge domain to the other.  One thing I shall not attempt to do (at least for now) is to get the transit domains to repair each other if they are broken.  That would really make it complicated.

Redistribution rules

R1 has no less than six redistribution route-maps.  Only the listed prefixes get redistributed, everything else is implicitly denied.

• RIP–>EIGRP : RIP natives get tagged 120, EIGRP 34 natives keep thier tag.
• OSPF–>EIGRP : OSPF internals get tagged 110, EIGRP 34 natives keep their tag.
• EIGRP–>RIP : EIGRP internals get tagged 12
• OSPF–>RIP : OSPF internals get tagged 110
• EIGRP–>OSPF : EIGRP internals get tagged 12
• RIP–>OSPF : RIP internals get tagged 120

Everything gets tagged, or gets to keep its existing tag. 

I prefer to set redistribution metrics inside the route-map rather than as a default or in the redistribute command.  It is more granular and controllable. 

OSPF and EIGRP have tools to distinguish internal prefixes: match route-type internal.  RIP does not.  How can we distinguish the RIP native prefixes from its externals?  Most NMC answers do this with an access list or prefix list.  I prefer to do it by match tag 0.  They must be RIP natives because they have not been tagged yet.

Since this router touches all three domains (EIGRP 12, RIP, OSPF) there is no point in any of these domains redistributing each others’ prefixes.  The only external prefixes taht need to be redistributed are EIGRP 34 prefixes from the transit domains (RIP and OSPF) to EIGRP 12.

There is an important point to make about “EIGRP 34 natives keep their tag”.  In this particular case, I could get away with:

match tag 34
  set metric 1500 50 255 1 1500

That is, the tag is automatically preserved as you redistribute.  But here is a “gotcha”: that does not apply to prefixes redistributed into RIP.  They lose the tag on the way, so the route-map has to regenerate it.  I make a habit of regenerating the tag in all cases anyway:

match tag 34
  set tag 34
  set metric 1500 50 255 1 1500

The situation at R3 is exactly the converse of R1:

• RIP–>EIGRP : RIP natives get tagged 120, EIGRP 12 natives keep thier tag.
• OSPF–>EIGRP : OSPF internals get tagged 110, EIGRP 12 natives keep their tag.
• EIGRP–>RIP : EIGRP internals get tagged 34
• OSPF–>RIP : OSPF internals get tagged 110
• EIGRP–>OSPF : EIGRP internals get tagged 34
• RIP–>OSPF : RIP internals get tagged 120

I have treated R2 and R4 as warm-standby redistribution points.  Each has only two redistributions.  R4 is the converse of R2, which looks like this:

• OSPF–>EIGRP : OSPF internals get tagged 110, EIGRP 34 natives keep their tag.
• EIGRP–>OSPF : EIGRP internals get tagged 12

Note that the diagram does not show “EIGRP 34 natives keep their tag”, except as “OSPF ext ?”.  This is because I added it as a refinement during testing.

Administrative Distances at Border Routers

Once I have decided what to redistribute at the active border routers, I then have to look at the routes on the border routers themselves.  This includes both the active border routers (i.e. ones that are doing redistribution) and passive border routers (i.e. ones where two or more routing protocols meet, but that are not doing any redistribution).  The routes at the border routers can be optimised using the Administrative Distances.

Let us look first at the ADs on R1.  I have:

• 90 = EIGRP 12 internal prefixes (default)
• 110 = OSPF internal prefixes (default)
• 120 = RIP prefixes, and EIGRP 34 prefixes via RIP (default)
• 130 = OSPF external prefixes (EIGRP 34 prefixes via OSPF)
• 170 = EIGRP external prefixes (from R2 via EIGRP)

The last of these is the only one that needs to be configured explicitly: distance ospf external 130.  This ensures that R1 uses RIP to get to the EIGRP prefixes rather than going through OSPF, and also ensures that the RIP prefixes do not get dispaced out of R1’s routing table by the same prefix as an OSPF external.  The rest are defaults.  None of the AD=170 prefixes will find their way into the forwarding table unless somethong is broken, because there will always be a better route.

On R3, we have exactly the converse:

• 90 = EIGRP 34 internal prefixes
• 110 = OSPF internal prefixes
• 120 = RIP prefixes, and EIGRP 12 prefixes via RIP
• 130 = OSPF external prefixes (EIGRP 12 prefixes via OSPF)
• 170 = EIGRP external prefixes (from R4 via EIGRP)

Now to look at R2.  As I have already said, R4 is just the converse of R2.  These are the ADs that I chose on R2:

• 90 = EIGRP 12 internal prefixes
• 110 = OSPF internal prefixes
• 170 = EIGRP external prefixes (EIGRP 12 and RIP prefixes via R1) 
• 180 = OSPF external prefixes (EIGRP 12 and RIP prefixes via OSPF)

By putting the OSPF external prefixes down at 180, R2 will prefer to go through EIGRP over the same external prefixes over OSPF.

So, that’s my design for the redistribution scenario.

Additional Challenges

The scenario AK throws out some additional challenges.  The first is “How would it complicate matters if the loopbacks on R6, CAT1 and CAT2 were redistributed into EIGRP as connected routes?”  So let’s try.  Instead of reconfiguring Lo106, I am going to add Lo116 141.11.116.1/24.

As I have been careful about what I redistribute, I am going to have to add it to the route maps EIGRP–>OSPF and EIGRP–>RIP on R1 and R2.  So I shall tag it with 116 as I inject it into EIGRP in the first place, and then use the tag to insert it into the route-maps.  When passing it into RIP and OSPF, I shall re-tag it as 12 because it is effectively part of EIGRP by proxy.

First, let me predict what will happen.  I think the route will get redistributed into OSPF on R1 and end up at AD=180 on R2.  That is fine, because it will have an AD of 170 within EIGRP.  It will also get redistributed into OSPF on R2, and end up on R1 with an AD=130.  That is not so fine, because it means that R1 will prefer to go though OSPF and R2 to get to it.  That is exactly what happened:

R1#show ip route 141.11.116.0
Routing entry for 141.11.116.0/24
  Known via "ospf 11", distance 130, metric 20
  Tag 12, type extern 2, forward metric 64
  Redistributing via eigrp 12, rip
  Last update from 141.11.10.2 on Serial0/0.10, 00:01:38 ago
  Routing Descriptor Blocks:
  * 141.11.10.2, from 141.11.102.1, 00:01:38 ago, via Serial0/0.10
      Route metric is 20, traffic share count is 1
      Route tag 12

The problem is that we have redundant border routers between EIGRP and OSPF.  They should be told not to use each others’ redistrubuted routes.  What I would like to do is this:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router ospf 11
R1(config-router)#distance 180 141.11.102.1 0.0.0.0
R1(config-router)#exit
R1(config)#exit

That would tell R1 to treat any route that originated on R2 as AD=180.  The trouble is that it would also affect 141.11.102.1/24.  That means we would have to solve it by listing the prefix.  Ugh!

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 16 permit 141.11.116.0 0.0.0.255
R1(config)#router ospf 11
R1(config-router)#distance 180 141.11.102.1 0.0.0.0 16
R1(config-router)#^Z
R1#

R1#show ip route 141.11.116.0
Routing entry for 141.11.116.0/24
  Known via "eigrp 12", distance 170, metric 537602560
  Tag 116, type external
  Redistributing via ospf 11, eigrp 12, rip
  Advertised by ospf 11 subnets route-map EIGRP-->OSPF
  Last update from 141.11.16.6 on FastEthernet0/0.60, 00:00:19 ago
  Routing Descriptor Blocks:
  * 141.11.16.6, from 141.11.16.6, 00:00:19 ago, via FastEthernet0/0.60
      Route metric is 537602560, traffic share count is 1
      Total delay is 1000100 microseconds, minimum bandwidth is 5 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
      Route tag 116 R1#show ip route 141.11.102.0
Routing entry for 141.11.102.0/24
  Known via "ospf 11", distance 110, metric 65, type inter area
  Redistributing via eigrp 12, rip
  Advertised by eigrp 12 route-map OSPF-->EIGRP
                rip route-map OSPF-->RIP
  Last update from 141.11.10.2 on Serial0/0.10, 00:00:26 ago
  Routing Descriptor Blocks:
  * 141.11.10.2, from 141.11.102.1, 00:00:26 ago, via Serial0/0.10
      Route metric is 65, traffic share count is 1

But yuk!  An access-list!  Now, I have always said that what I would really like to do is to determine the AD of a route according to its tag.  This is an example where it would have been useful.  I should be able to tell R1 “If OSPF tells you about external routes with a tag of 12 (or perhaps 116), then mark them down to AD=180 because you should already have a better route to them via EIGRP.”

IOS Gotcha : con f

I’m not sure whether this really qualifies as an “IOS Gotcha”.  It is not IOS’s fault, and only someone with fat asychronous fingers like me could trip over it.

The string I most often type when I’m doing a lab is “conf t<ENTER>”.  Well, I wish it was, because very often keystrokes get transposed.  Sometimes I transpose the ‘f’ and the sapce, so it comes out as “con ft”.  Sometimes I traspose the ‘t’ and the <ENTER>, so it comes out as “conf <ENTER>t”.  Sometimes I accidentally type it when I am already in config mode.

It’s no wonder my career as a guitarist never really took off.

Only once have I made all three mistakes in the same command.

Now, I wonder whether a config-register of 0×000f is benign …

IOS Gotcha : no exec

Here is a great one.  I don’t like my console timing out.  Let’s cancel the timeout.  The correct command is exec-timeout 0 0, but you can do it with no exec-timeout.  I’m even lazier:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#line con 0
R2(config-line)#no exec
R2(config-line)#^Z
R2#
*Mar  1 14:37:03.697: %SYS-5-CONFIG_I: Configured from console by console
R2#

Five minutes later, my console times out.  Not only that, but it seems to have locked up.  What is going on? 

Luckily, I am well advanced in my lab, and I can telnet from another router.  Let’s have a look:

R2#show run | sec con
Building configuration...
Current configuration : 4296 bytes
no ip dhcp use vrf connected
 redistribute ospf 100 include-connected
 redistribute connected
control-plane
line con 0
 privilege level 15
 logging synchronous
 no exec
R2#

Ooops!

Normally if a command is ambiguous, the CLI comes back and tells you so.  Not in this case.  Gotcha!
 

IOS Gotcha : no redistribute eigrp 12 subnets route-map EIGRP–>OSPF

This has to be  my favorite IOS gotcha.  I already struggle enough with redistribution without throwing this into the mix.  Here goes …

The story so far is that this lab has multiple loops and no less than four active redistribution points.  I have already redistributed OSPF onto EIGRP, and I have prepared a filter route-map for distributing EIGRP into OSPF.  This is what I have so far:

R2#show run | sec ospf
 ip ospf network point-to-point
 ip ospf 11 area 2
 ip ospf network point-to-multipoint
 ipv6 ospf 100 area 25
 redistribute ospf 11 route-map OSPF-->EIGRP
router ospf 11
 router-id 141.11.102.1
 log-adjacency-changes
 network 141.11.10.0 0.0.0.255 area 0
 distance ospf external 180
 redistribute ospf 100 include-connected
ipv6 router ospf 100
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute connected
 redistribute bgp 100 metric 20

(BTW, I have done another posting about the dangers of the “section” filter.)

So let’s do the redistribution:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router ospf 11
R2(config-router)# redistribute eigrp 12 subnets route-map EIGRP-->OSPF
R2(config-router)#^Z
R2#

So far so good.  So I go off and have a look at the routes on the other routers, and I see I have got it almost right, but not quite.  Let’s remove the redistribution while I think about it.  As you know, to negate a command, you just put “no” in front of it.  So up-arrow through the config commands, and do this:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router ospf 11
R2(config-router)#no redistribute eigrp 12 subnets route-map EIGRP-->OSPF
R2(config-router)#^Z
R2#

Suddenly all hell breaks loose on the other routers.  All the routes go unstable, and I have lots and lots of output fom my debug ip routing.  What has happened?  Here’s what:

R2#show run | sec ospf
 ip ospf network point-to-point
 ip ospf 11 area 2
 ip ospf network point-to-multipoint
 ipv6 ospf 100 area 25
 redistribute ospf 11 route-map OSPF-->EIGRP
router ospf 11
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute eigrp 12
 network 141.11.10.0 0.0.0.255 area 0
 distance ospf external 180
 redistribute ospf 100 include-connected
ipv6 router ospf 100
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute connected
 redistribute bgp 100 metric 20
R2#

We are still redistributing EIGRP 12 into OSPF, but we have removed the route-map filter.

The correct way to remove the redistribution would have been no redistribute eigrp 12.

P.S. Re-reading this, I can see that I have chosen a less-than-ideal example.  But it still illustrates the point that the no redistribute protocol route-map route-map command does not remove the redistribution but simply opens it up.  The example is less than ideal because in this case it has also removed the “subnets” keyword, and so is unwittingly quite benign.  If I had chosen an EIGRP or RIP example, it would have been much more of a problem.

IOS Gotcha : section filter

The first one is to do with the “section” filter.  I read about the “section” filter on a blog a few weeks back, and I have been using it extensively since.  It is one of the most useful features I have seen in a long time.  But you have to be careful how you interpret its output.  Let’s check the eigrp process on R2, NMC lab 11:

R2#show run | section eigrp
router eigrp 12
 redistribute ospf 11 route-map OSPF-->EIGRP
 network 141.11.25.0 0.0.0.255
 auto-summary
 redistribute eigrp 12 subnets route-map EIGRP-->OSPF

Aaagh!  How did that happen?  When I was configuring, I must have thought I was in the OSPF section, but instead, accidentally redistributed EIGRP into itself.  I didn’t know you could do even that.  Let’s remove it:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router eigrp 12
R2(config-router)#no redistribute eigrp 12
redistribution of "eigrp" via "eigrp" not allowed
R2(config-router)#

Sure.  That makes sense in itself.  But it still seems to be there: 

R2#show run | section eigrp
router eigrp 12
 redistribute ospf 11 route-map OSPF-->EIGRP
 network 141.11.25.0 0.0.0.255
 auto-summary
 redistribute eigrp 12 subnets route-map EIGRP-->OSPF

 Gotcha!  It’s an artifact of the “section” filter.  The rogue redistribute was in the OSPF section all along.  It just happened to string-match “eigrp”.

Here is another example from the same router:

 R2#show run | section ospf
 ip ospf network point-to-point
 ip ospf 11 area 2
 ip ospf network point-to-multipoint
 ipv6 ospf 100 area 25
 redistribute ospf 11 route-map OSPF-->EIGRP
router ospf 11
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute eigrp 12 subnets route-map EIGRP-->OSPF
 network 141.11.10.0 0.0.0.255 area 0
 distance ospf external 180
 redistribute ospf 100 include-connected
ipv6 router ospf 100
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute connected
 redistribute bgp 100 metric 20
R2#

It looks like I have accidentally redistributed a non-existant OSPF 100 process into OSPF 11.  Of course (?) I haven’t.  The command in red is actually in the router BGP section under the IPv6 address-family.  Let’s try and remove it:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router ospf 11
R2(config-router)#no redistribute ospf 100
R2(config-router)#^Z
R2#

That seems to have done the trick:

 R2#show run | section ospf
 ip ospf network point-to-point
 ip ospf 11 area 2
 ip ospf network point-to-multipoint
 ipv6 ospf 100 area 25
 redistribute ospf 11 route-map OSPF-->EIGRP
router ospf 11
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute eigrp 12 subnets route-map EIGRP-->OSPF
 network 141.11.10.0 0.0.0.255 area 0
 distance ospf external 180
 redistribute ospf 100 include-connected
ipv6 router ospf 100
 router-id 141.11.102.1
 log-adjacency-changes
 redistribute connected
 redistribute bgp 100 metric 20
R2#

Oh!  It’s still there!  Duh!  Gotcha!

[OT] Car keys, multiple-choice exams, SLAs, and censorship

A man comes out of a pub late one evening, and on his way to his car, he drops his keys.  Two minutes later, his friend comes out of the pub and sees him scrabbling about under a street lamp.

“What are you doing crawling around like that?”

“Oh, I’ve dropped my car keys and I can’t find them anywhere.”

“OK, I’ll help you find them”

Five minutes later, the pair have still not found the car keys.

“I give up.  Are you sure this is where you dropped them?”

“No, I dropped them over there on the other side of the road, but the light is so much better here.”

That story sums up what I think is wrong with multiple-choice exams.  We have multiple choice exams because they generate a metric that is easy to measure.  What we rarely think about is whether that metric measures anything useful.  Multiple-choice exams are great for finding out if you can recognise the right answer when it is put in front of you.  Sometimes, they only measure whether you can recognise wrong answers as wrong.  How useful is that in real life?

For that reason I applaud the move towards simulations in the CCNA and CCNP exams, and the lab format of the CCIE exam.  Whatever their shortcomings, these exam formats measure something much more useful than multiple-choice does.

The story about the car keys has much wider implications than just multiple-choice exams.  So often, we make meaningless measurements just because the real measurement is too difficult.   It applies to SLAs at all levels.  Recently, I saw one of those cleaning rotas in a restroom (or “toilet”, if you happen to be European).  The idea was evidently to assure that they had been cleaned and inspected to a sufficiently high standard.  Some enterprising cleaners must have been very keen to show their enthusiasm for the quality of their service, because they had signed off the whole week in advance.  You see, what was being measured was not the cleanliness of the bathroom, but the signatures on the docket.

From my European perspective, this phenomenon sticks out like a sore thumb when I watch clips from some US TV shows.  You know, where they bleep out certain words.  Often they are right to do so.  I presume the censors have a list of banned words, and those words must not appear in the show under any circumstances.  But in my view, there are certain circumstances where the words are not gratuitous, but are appropriate in the context.  But they get bleeped out anyway, because they are that particular word.  It is easier to test whether the word appears than it is to decide whether the use of the word is appropriate.

There is an example in the Avril Lavigne song “My Happy Ending”.  There is a relatively mild word, used in a metaphorical sense, that has been bleeped or blanked out of the YouTube clips.  In my view, that word is entirely appropriate to the context of the song.  I’m not arguing that the word should be allowed because it is mild.  I am arguing that the word is entirely appropriate in the context, and therefore should be allowed.  Its removal diminishes the content of the song.

We sometimes forget that a word has no power in itself, but only in the idea that it communicates.  If the word communicates nothing, then it is gratuitous.  If it communicates something, then it is significant, and may even be appropriate.  Censoring on the basis of a word list, you give power to the word when it is used gratuitously.

Before anyone points it out, I am aware that we have to sensitive to cultural context.  Having lived in UK for many years, and Italy for many years, I know that there are certain subjects and phrases that are taboo in Italian but not in English, and vice versa.  Most offense is caused when innocent phrases are translated (or mistranslated) literally.  (I must tell the story about “eventually”, or the one about the “preservative-free food” some time.)

This evening I shall blog about CCIE labs!

IOS Gotcha : IPv6 address

This is a gotcha that almost anyone who has ever configured IPv6 has tripped over.  One thing it is easy to forget in the heat of the moment is that an interface can have as many IPv6 addresses as you want.

If you are used to configuring IPv4, you are probably used to changing the IP address of an interface and having it do exactly that.  So:

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#int Lo7
R7(config-if)#ip address 192.168.7.1 255.255.255.0
R7(config-if)#exit
R7(config)#exit
R7#
*Mar  1 00:02:27.467: %SYS-5-CONFIG_I: Configured from console by console
R7#
R7#show run int Lo7
Building configuration... Current configuration : 65 bytes
!
interface Loopback7
 ip address 192.168.7.1 255.255.255.0
end

Oops, I meant 192.168.17.1:

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#int Lo7
R7(config-if)#ip address 192.168.17.1 255.255.255.0
R7(config-if)#exit
R7(config)#exit
R7#
*Mar  1 00:04:13.351: %SYS-5-CONFIG_I: Configured from console by console
R7#show run int Lo7
Building configuration... Current configuration : 66 bytes
!
interface Loopback7
 ip address 192.168.17.1 255.255.255.0
end

That’s better.  Now let’s try the same thing in IPv6:

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#int Lo7
R7(config-if)#ipv6 address fec0::7:1/124
R7(config-if)#^Z
R7#
*Mar  1 00:06:49.107: %SYS-5-CONFIG_I: Configured from console by console
R7#show run int Lo7
Building configuration... Current configuration : 94 bytes
!
interface Loopback7
 ip address 192.168.17.1 255.255.255.0
 ipv6 address FEC0::7:1/124
end

Oops, I actually meant FEC7::7:1/124.  FEC0::7:1/124 should have been somewhere else in the topology. Let’s change it:

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#int Lo7
R7(config-if)#ipv6 address fec7::7:1/124
R7(config-if)#^Z
R7#
*Mar  1 00:08:29.679: %SYS-5-CONFIG_I: Configured from console by console
R7#

OK, that’s changed it, hasn’t it?  Let’s check:

R7#show run int Lo7
Building configuration... Current configuration : 122 bytes
!
interface Loopback7
 ip address 192.168.17.1 255.255.255.0
 ipv6 address FEC0::7:1/124
 ipv6 address FEC7::7:1/124
end

You see how it hasn’t changed the IPv6 address?  It has just added an extra one.  A real “gotcha”.

Ramblings on 172.16.23.20

I’m sitting here clicking around, posting a few things on NetPro, and generally benefiting from other people’s lab experiences.  I enjoy answering questions on NetPro and DISCUSSiT, because it is a great way to learn.  When you try and explain something, it’s then that you realise where the holes are in your own understanding.  That’s the benefit of blogging too.

One of the pages I clicked to was my own blog stats.  I get around 20 – 40 hits per day.  I am sure other blogs get many hundreds of times that, and quite deservedly so.  But I am still honoured that someone or somebot decided to navigate to my pages.

The most amusing thing I find in the blog stats are the lists of search terms that people used to find my blog.  I kind of feel a certain responsability for that.  If someone had typed “teach me BGP” into Google and landed on my pages, I feel that maybe I should have something relevant to say about it.  It might even be good revision and consolidation for me.  But there are so many search terms that it is a quandry which ones to write about.

The most startling search term was “172.16.23.20″.  I guess someone had that address in their network and wanted to know who owned it.  (If you are reading this, 172.16.23.20 is part of a “free-for-all” allocation of IP address space.  Any site can use that address, and it is not routable on the Internet.  For more details, see RFC-1918.)  What really astounded me was how they could possibly have found me just on a mention of that address in a blog page, and in a debug output at that.  So I typed it into Google, and guess what … I was the first hit!

So, Ethan may be the first for “CCIE Candidate”, and deservedly so.  But it seems for this 15-minutes I am the world authority on 172.16.23.20.

11.13 Multicast MVR

Spent an hour or so trying to get MVR working.  I did manage to get a response in the end, but the whole feature does not seem to be very reliable.  One minute it works, one minute it doesn’t.  I tried  running it over a trunk, but that did not seem to work at all, and just got me a spurious entry in the MAC forwarding table that I cannot shift:

CAT2#show mac-address-table multicast
Vlan    Mac Address       Type       Ports
----    -----------       ----       -----
  10    0100.5e0b.0b0b    USER       Fa0/7
  40    0100.5e0b.0b0b    USER       Fa0/4, Fa0/7

After that, the original ping would not work until I removed the config, shut and no shutted a few port, said a few magic words (swore at it).  Then it worked again.  But the spurious entry is still there.

I really do not think this is going to come up in the exam.  If it does, at least I know where to look for it in the doc.