Kevin Dorrell, CCIE #20765

28 Feb 2008

NMC Lab 09

Filed under: General — dorreke @ 22:08

OK, I give up.   I’ve spent too much time on the multicast.  I shall settle for it working, and I shall hold back on trying to fully understand what is going on in this scenario.  Maybe next time round.  It is already 22:00, and I need to get on to other things.

NMC Lab 09.18 – Multicast

Filed under: IP Multicast — dorreke @ 09:12

Started to work on the multicast again yesterday evening, but got hopelessly confused.  So much so I decided not to publish the blog.  Looking at yesterday’s posting, that was confused as well.  I shall have to tackle it with a clearer head.  I must do some multicast reading first though.  Wendell Odom’s CCIE Cert Guide, and Jeff Doyle’s book, Vol 2.  I shall add a few notes here as I go:

Multicast on LAN

  • IN PIM-DM, the winner of the “assert” contention is responsible for trasmitting the stream onto the LAN.  Assert is won by who is closest to the source (but is it pre-emptive?), with lowest IP as tie-breaker.
  • IGMP v1 uses PIM DR to determine who puts the IGMP query on the LAN.  It is the highest ip pim dr-priority, else the highest PIM IP address on the LAN.
  • IGMP v2 uses assert winner to query the LAN.  (Lowest IP as tie-breaker, so tutt’altro che DR).

PIM-SM RP – Rendez-Vous Point

Everyone should know where the RP is, by one of:

PIM-SM Source registration

  • If a router has a source, it sends a PIM register to the RP.  (The PIM register also encapsulates the first packet.  So why do we often not see a response from the RP to that first packet?)
  • If the RP has no listeners for that group, it sends a uncast Register-Stop back to the source.  Source router supresses register messages for 60 seconds.  After 55 seconds it sends a Null register with no packet encapsulated.

 To investigate:

  1. What happens if you declare dense-mode at one end of a link and sparse-mode at the other?

——————- Unfinished ————————

27 Feb 2008

NMC Lab 09.18 – Multicast

Filed under: IP Multicast — dorreke @ 14:10

I set off with good intentions yesterday evening.  Having got full reachability in 2 hours and 20 minutes, I thought I would just knock off the BGP, the IPv6, and the multicast all in one evening.  It wasn’t to be.  I got stuck on the BGP (which I shall write about some other time) and I got stuck on the multicast (which I shall write about now because it is more interesting), and I didn’t even attempt the IPv6.

If anyone reads this posting, it will probably make much more sense if you have the NMC scenario in front of you.  So go out and buy it!  It is not my intention to substitute or plagiarise the excellent labs that NMC produce, but more to use them as a starting point for my learning experience.

As I could tell from the wording of the requirements, the main problem was how to get R7 FRS to respond to the multicast ping.  I knew what the problem was: the FRS has an RPF to the source that points to R4 on VLAN 40, but the multicast stream is coming from R3.  That, and the fact that the FRS does not seem to see the RP.  The FRS is logging something about an “invalid join for 229.17.17.17 from R4”.  (Note to self: Examine this message as see where it comes from, and why FRS thinks it is invalid.)

As usual, I almost got the solution, but not quite.  The first thing I did was to put a static mroute in R4 towards the RP (172.16.106.1) via the FR interface.  That was correct!  The RP turned up in the FRS immediately.  But still no multicast stream.

It was here I made my biggest mistake.  As usual, I did not read the scenario carefully enough.  It says “9.18.5. Do not introduce static mroutes on FRS or create any new interfaces on FRS or R4.  Only configure static mroutes on 1 router in this scenario.”  Instead, I read, “Only configure 1 static mroute in this scenario.”  Which is why I spent the rest of the evening learning the hard way.

The various things I tried were:

  1. Putting ip pim nbma-mode on the FR interfaces … on R1 and R4!  So near and yet so far!
  2. Changing the dr-priority of the three routers concerned: R3, R4 and FRS.
  3. ip mroute 172.16.0.0 255.255.0.0 172.16.10.1 on R4!  So near and yet so far!

By now, I have looked in the Answer Key and groaned.

The best way to look at this is as a starting point for a learning exercise.  These are things to be investigated:

  1. Start with initial conditions of PIM configured on all the routers and the RP sending out its stuff.  Then look at that logging message on FRS and work out where it comes from and why.  I suspect I shall be breaking out my laptop with Ethereal.
  2. In this condition, are the mpackets appearing on VLAN40 at all.  If so, then the FRS is not forwarding them to Lo107 because of the lack of RP.  So, if I join the R7-E0 into the group, would the FRS respond?
  3. Find out about dr-priority, what it means, why it exists, and work out whether it has any effect at all in this scenario at all.
  4. Configure the solution proposed in the Answer Key and the SHOWiT and examine it carefully.  In particular, look at the show ip mroute in R3 to see the nbma-mode in action.
  5. Now, just to be perverse, see if I can do it without any static mroutes at all.  It should be possible like this:
    1. Go to R4 OSPF and lower the AD of 172.16.106.1 to something under 90.  This of course will mean that R4 will start injecting that prefix into the EIGRP.  But that is OK.  We actually want the FRS to use R4 for this prefix, and R3 will ignore it because it has a better internal.
    2. Now, for the RPF on the source, 172.16.11.0/24.  I reckon that should already be on the FR interface, so no change required there.
    3. But R4 is not receiving any multicasts now.  Why not?  Because R3 and R2 are not forwarding them because of their split-horizon thing.  So we need ip pim nbma-mode.  On R2 or R3?  Probably one or the other, but not both.  What will happen if we do put it on both?  Will R4 get two copies of each mpacket?
    4. Alternatively, we could get R3 to prefer the EIGRP route to 172.16.11.0/24.  In that case, R3 should start receiving the stream from VLAN 40, and forwarding it on the FR.  As long as R4 is expecting it from the FR, that should work.

There are so many possible solutions, how come I didn’t hit on any of them?

I guess I’ll have to record Torchwood and watch it some other day.

25 Feb 2008

NMC Lab 09 – The Golden Moment

Filed under: IP Addressing Services, OSPF, Redistribution — dorreke @ 23:48

It’s week 9, so I’m doing NMC Lab 09.  This time I think I have reach the full reachability as fast as I can: 2 hours and 20 minutes.  I was cautious – maybe over cautious – about the redistribution, only redistributing internal routes of each protocol.  (Except for RIP, which is out on a limb and therefore can be redistributed blindly.)  Of course, that left me with a lot of redistributing connected, but that was allowed by the scenario.

R4-Lo104 was the joker in the pack, because there were no instructions.  I redistributed it into both OSPF and EIGRP just for good measure.  I then looked at R3 and decided the 104 subnet would be better handled by EIGRP than OSPF.  In fact, if the R3 chooses the OSPF route to Lo104, then R6 never sees it.  So I punished every OSPF LSA coming from R4 with distance 180 172.16.104.1 0.0.0.0 at R3.  (The 172.16.104.1 being the router ID of R4 … it is only coincidence that it is also the subnet we are trying to manipulate.)  Probably would have been easier if I had just sent it into EIGRP and not to OSPF.

I suspect they wanted me to put the R2-R5 link into OSPF area 12, and use the R2-S1/0 address for the unnumbered reference on the Tunnel.  So just to be perverse, I didn’t do it that way.  Insead, I based my tunnel on R1-L101 and R2-L102, and I activated the OSPF on it with the interface command ip ospf 9 area 12.  That left me free to use whatever area I chose for the R2-R5 link.  I chose area 25, and made a string of virtual links across area 25 and area 51.

 There is something that makes me want to put a virtual link between R1 and R2 across area 12 to leverage that nice fast Ethernet segment rather than going through the Frame Relay.  I’ll bear that in mind if there is any RPF issue in the multicast.

More tomorrow.  The IPv6 and Cat 3560 sections look a bit heavy.  But it’s late now, the rest of the family are in bed already (one with ‘flu) and I need my sleep.

24 Feb 2008

Encouragement

Filed under: General — dorreke @ 21:39

Just got some marvellous news.  One of the active participants of DISCUSSiT, and who I have been discussing the labs with, has just got his ticket.  That has really made my day, and I’ll take it as a good omen for my own studies. 🙂 Although I shall be sorry to see him go from the DISCUSSiT.

Catalyst QoS

Filed under: QoS — dorreke @ 11:10

I’m going to have to get a grip on this QoS stuff.  About three years ago I went on the official Cisco QoS course, but I never got a chance to use it in anger.  I have also been to quite a few Networkers presentations about it, and they all made sense at the time.  but the information did not stick.  In any case, a lot of it has changed, and the 4500, 3560, 3550, 2960, 2950 all use subtly different paradigms.

I’m doing NMC Lab 8.13, and I’m thrashing between the config line and the documentation, but I hope I’m learning something in the process.  I’m feeling the lack of any 3560s.  I have the proper 3550s for CAT1 and CAT2 (albeit with 12.1=), but my CAT3 and CAT4 are 2950s with a 2610 router on a stick behind each one in case there are any layer-3 tasks.  So far, there have not been any, but there has been plenty of QoS and special features.

So far, I tripped over a couple of configuration gotchas.  The first is “let’s put the service policy on the interface first and I’ll define it later”.

CAT2#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
CAT2(config)#int f0/1 
CAT2(config-if)#service-policy input set-af11 
policy map set-af11 not configured 
CAT2(config-if)#end 
CAT2# 
Feb 24 09:57:47.247: %SYS-5-CONFIG_I: Configured from console by console

No, that isn’t just a warning.  It hasn’t remembered it:

CAT2#show run int f0/1 
Building configuration... Current configuration : 150 bytes 
! 
interface FastEthernet0/1 
 description R1-F0/0 
 switchport trunk encapsulation isl 
 switchport trunk allowed vlan 12,16 
 switchport mode trunk 
end CAT2#

 You must define the policy-map first.

The second gotcha was to do with monitoring the DSCP on the QoS:

CAT2#show run int f0/1 
Building configuration... Current configuration : 211 bytes 
! 
interface FastEthernet0/1 
 description R1-F0/0 
 switchport trunk encapsulation isl 
 switchport trunk allowed vlan 12,16 
 switchport mode trunk 
 mls qos monitor dscp 0 10 11 
 service-policy input Set-AF11 
end

Woops, no I didn’t mean 0, 10, and 11.  I meant 12.  OK, I have 8 slots in the stats, so I’ll just add it in:

CAT2#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
CAT2(config)#interface FastEthernet0/1 
CAT2(config-if)#mls qos monitor dscp 0 10 11 12 
QoS: Following DSCPs are monitored already: 0 10 11 
CAT2(config-if)#end 
CAT2# 
Feb 24 10:05:05.824: %SYS-5-CONFIG_I: Configured from console by console

That was just a warning, wasn’t it?

CAT2#show run int f0/1 
Building configuration... Current configuration : 211 bytes 
! 
interface FastEthernet0/1 
 description R1-F0/0 
 switchport trunk encapsulation isl 
 switchport trunk allowed vlan 12,16 
 switchport mode trunk 
 mls qos monitor dscp 0 10 11 
 service-policy input Set-AF11 
end

No, clearly it wasn’t just a warning.  However, you can add the DSCP into the existing monitor list provided you don’t mention any of the existing entries:

CAT2#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
CAT2(config)#int f0/1 
CAT2(config-if)#mls qos monitor dscp 12 
CAT2(config-if)#end 
CAT2# 
Feb 24 10:03:53.589: %SYS-5-CONFIG_I: Configured from console by console

Let’s have a look:

CAT2#show run int f0/1 
Building configuration... Current configuration : 214 bytes 
! 
interface FastEthernet0/1 
 description R1-F0/0 
 switchport trunk encapsulation isl 
 switchport trunk allowed vlan 12,16 
 switchport mode trunk 
 mls qos monitor dscp 0 10 11 12 
 service-policy input Set-AF11 
end

That’s better!

Here is another gotcha.  It seems you cannot set DSCP (on the input service-policy of a 3550) on the class-default.  You can only do that in the classes you have actually defined.  For example, I started with this policy map, applied input from the R6 connection on CAT1:

CAT1#show policy-map Set-AF11 
 Policy Map Set-AF11 
   class  class-default 
   set ip dscp 10

But that didn’t work.  It’s lucky I tested it by monitoring the DSCP on the the R1 connection on CAT2, with show mls qos int Fa0/1 statistics, and doing lots of pings from R6 to R1.  Otherwise I might not have noticed that the service policy was not marking the packets.  What I needed was:

CAT1#show class-map 
 Class Map match-any class-default (id 0) 
   Match any 
 Class Map match-all All-IP (id 1) 
   Match access-group name All-IP CAT1#show policy-map Set-AF11 
 Policy Map Set-AF11 
  class  All-IP 
   set ip dscp 10 
  class  class-default

 Now I can see the markings on R6’s packets at the R1 port.

One thing I did think of was to put mls qos trust dscp on each side of each trunk link.  In my case, that meant only CAT1-F0/13, CAT1-F0/23, CAT2-F0/13, CAT2-F0/23 since it was irrelevant for the CAT3 and CAT4 2950s.  Just to make sure it was necessary, I remove the command from those interfaces and tried pinging from R6 to R1 again.  Sure enough, the AF11 marking had been stripped.  Strangely, the SHOWiT does not do that, so I have asked the question on the DISCUSSiT forum.

23 Feb 2008

OT : Concert

Filed under: General — dorreke @ 23:30

No lab work this evening.  Went to see an amazing performance by the drummers of Kado (Sado, Japan)

IPv6 BGP : Peering across link-local addresses

Filed under: IPv6 — dorreke @ 17:56

I just learned that you can peer IPv6 BGP across link-local addresses, even on a tunnel interface.  This came as a surprise to me.  I had always peered across site local addresses and I had assumed that you could not peer across link-local addresses because they are not unique.

(OTOH, I should not have been surprised.  After all, IPv6 OSPF can form adjacencies across link-local addresses, so why not BGP).

So, if you are going to peer to, say, fe80::5, how does the router know which interface to connect through?  Wel, in the example in this lab, we specify the update source too, so I am guessing that it uses that to determine which interface to connect through.

This has some strange implications.  Suppose you have two link-neighbors, but they both have the address fe80::2.  You can only peer with one of them.  For the other one, you would have to use a unique address.

Futhermore,  if your neighbor is a link-local address, then the update source must be mandatory.

The wierd and wonderful world of IP6!

Redistribution

Filed under: IP Routing Protocols, Redistribution — dorreke @ 06:47

One topic that wastes a lot of my time during CCIE practice labs is redistribution.  The issues often catch me unawares.  I wonder whether I can improve my performance by changing my approach.

So far, my method has been “detect, diagnose, and fix”.  Detect by setting debug ip routing and by examining routing tables.  Diagnose by looking at the symptoms to try and to figure out what is going on.  Fix by filtering and by manipulating distances.   It is the diagnose bit that takes the time.

Many people emphasise prevention.  This is largely based on making sure you don’t redistribute more than is absolutely necessary.  That helps, but it does not guarantee there will be no issues.

I want to see if I can benefit from a topology-based issue-spotting approach.  I’m sure that the successful CCIE condidates have a wide experience to draw on: that they can recognise certain situations and instinctively know how to deal with them.  I would like to build up a repertoire of issues that I can address before they trip me up.

For each case, I want to list:

  • the alarm bells that should have alerted me to the impending issue
  • the contributary factors, the circumstancial evidence
  • the modus operandi of the issue
  • the tools and techniques for fixing it.

For example, I tripped over an issue in NMC Lab 08 that could briefly described like this:

Name: RIP border loop 

Alarm bell: Border router with two “neighbors” (i.e. next-hops) in RIP domain

Contributary factors: Route injected into RIP at AD > RIP (120)

Modus operandi: Bidirectional route feedback within RIP, leading to race condition, and possibly overwriting the injected route at the border router.

Tools and techniques: Try not to inject route at AD > RIP.  If that is not possible, filter routes coming into border router from the RIP neighbors to allow only RIP native routes.

 Here is another one:

Name: OSPF<–>RIP, redundant BR (I need a more succinct name for this one)

Alarm bell: Two border routers between OSPF and RIP

Contributary factors: None – this situation is already the issue itself

Modus operandi: Bistable sub-optimal routing for RIP-native routes. (One border router will route RIP routes correctly, the other will route them via the OSPF external route.)  Possible race condition if both are redistributing OSFP<–>RIP.

Tools and techniques:  Each border router punishes OSPF external routes from the other by setting AD > RIP (120).  Filter redistributed routes to prevent RIP routes finding their way back into RIP.

For each of these cases, I would like to write a posting with a lot more detail under each of the four headings.

20 Feb 2008

IOS Gotcha : Frame Relay and PPP

Filed under: Frame Relay, PPP, WAN — Tags: , , — dorreke @ 20:00

frame-relay interface-dlci 304 ppp  

This is the first of a series of postings I intend to write covering some IOS “gotchas”: pitfalls for the unwary in the CLI.

Suppose you have configured the Virtual-Template, configured the Frame Relay subinterface, but you have forgotten to specify the PPP, so you have something like this:

interface Serial0/0.34 point-to-point 
 frame-relay interface-dlci 304 
 end

You then realize you mistake and try and add on the PPP stuff:

R3#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
R3(config)#interface Serial0/0.34 point-to-point 
R3(config-subif)#frame-relay interface-dlci 304 ppp Virtual-Template1 
R3(config-fr-dlci)#end 
R3#

Has it taken it? No it hasn’t!

R3#show run int S0/0.34 
Building configuration... Current configuration : 80 bytes 
! 
interface Serial0/0.34 point-to-point 
 frame-relay interface-dlci 304 
end

If you want to add the PPP stuff, you have to remove the interface DLCI, and then put it back again with the PPP link:

R3#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
R3(config)#interface Serial0/0.34 point-to-point 
R3(config-subif)#no frame-relay interface-dlci 304 
R3(config-subif)#frame-relay interface-dlci 304 ppp Virtual-Template1 
R3(config-fr-dlci)#end 
R3#

Now we have it:

R3#show run int S0/0.34 
Building configuration... Current configuration : 99 bytes 
! 
interface Serial0/0.34 point-to-point 
 frame-relay interface-dlci 304 ppp Virtual-Template1 
end

The moral of the story is to make no assumptions, and always look at your running configuration after you have configured it.

Older Posts »

Create a free website or blog at WordPress.com.