This week, I want to concentrate some effort on understanding QoS, particularly shaping and policing.  I am fed up with losing 2 to 8 points every time I do a mock lab because I have not got a firm grasp of the subject.  Sometimes I muddle through.  I know the commands, and usually I can match up the parameters in the requirements with the parameters of some command or other, but I am not confident.

I read the chapter in the Wendell Odom book this morning.  It all seemed to make sense, but it left me wondering about two points:

1. If you are traffic-shaping, and you have a frame in the queue that is longer than B_C+B_E, and the bucket overflows at B_C+B_E, how do you ever get enough tokens in the bucket to transmit it?
2. If CB policing replenishes the bucket(s) with a prorata number of tokens according to how long ago was the last frame transmitted, if there is a long silence so the last frame transmitted was a very long time ago, then is the bucket replenished with an enormous number of tokens.  Doesn’t that make the traffic very very bursty?
3. On page 566, he states “FRTS cannot classify traffic in order to shape a subset of traffic on a particular VC.”  But you can specify a service-policy within a map-class.  And in the corresponding policy map, you can specify policing under the class-default.  So what happens if you try and specify other classes in the policy map?

No doubt these things will become clearer as I read more.

Cisco Documentation

• Cisco IOS WAN Configuration Guide : Frame Relay
• Cisco IOS QoS Configuration Guide : Shaping and Policing

Cisco Tech Notes

• Configuring Frame Relay Traffic Shaping on 7200 Routers and Lower Platforms.

• Configuring Packet Marking on Frame Relay PVCs

Books and Course Notes

• CCIE R&S Exam Certification Guide, Wendel Odom, 2nd edition, pages 565 – 570.
• CCIE Practical Studies Volume I, Karl Solie, pages 363-369
• Cisco : “Implementing Cisco QoS”, version 2.1, module 7 “Understanding Traffic Policing and Shaping”, esp. Lesson 4 “Configuring Class-Based Shaping on Frame Relay Interfaces”

Practical examples 

• DOiT Labs 6, 8, 18, 20
• CCIE Practical Studies Volume I, Karl Solie, Lab 14 on pages 382 – 391

 If you want to skip the blah-blah, you may want to go directly to the table below.  You will then want to read the blah blah to see what it is about.

 I’m not sure how much sense I made in yesterday’s posting.  The point was that we had a Frame Relay multipoint interface with a bridge-group on it.  Spanning Tree assumes that all devices on a segment can see each other’s broadcasts.  But this is not so with FR-MP or physical.

It got me thinking.   Frame Relay multipoint and physical interfaces are great for CCIE scenario writers.  They have so many issues.  That is because they are NBMA.  Many many protocols assume a multi-access segment is a broadcast segment.  NBMA breaks this rule because as often as not there is no visibility from spoke to spoke.  Most of the literature says “Here is a technology X.  This is how you configure it.  BTW, there is a special requirement for NBMA networks, and you have to do this … “.

I want to look at it from a different angle.  I want to make a list the things that NBMA cannot do, and how you can get round it for each technology.  I want to be able to say “OK, we have a FR multipoint.  They have obviously specified that in order to mess something up.  Which technologies are likely to be impacted?

So here is the list:

Can anyone suggest anything to add to the list?

These issues are not limited to Frame Relay multipoint.  I have seen NMC labs where they contrive to turn an Ethernet segment into a NBMA segment, typically by creating unicast peering between routers on the Ethernet, and therefore not allowing them full-mesh.

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.

Took a day out of work today to see what I could get out of Lab 8.  Once again, the lab caught me unawares in several places.  Here are some of the lessons:

8.1.4. PPP over Frame Relay

I had not done a PPP over Frame Relay before.  It is an interesting technique involving configuring a Virtual-Template interface that then spawns a Virtual-Access interface when it connects.  Here for the Cisco Configuration guide.

One configuration “gotcha” caught me out.  I have tripped over so many “gotchas” in the past that I have decided to make a list of them (top right, under “pages”) and write a small posting on each.

It is interesting that the example in the Cisco doument has three levels of interface: a physical interface, a point-to-point subinterface that defines the DLCI, and the PPP Virtual-Template.  The NMC answer key has only two: they go straight from the physical interface to the Virtual-Template.  Pros and Cons of each approach? 

One thing I did not manage to do: to get R3 and R4 to ping their own addresses on the PPP link.  They could each ping their partner’s address, but not their own.  I spent a long time trying to get this to work before giving up and looking at the AK.  Then I find that their solution doesn’t reach those addresses either.  They might have said so!  I have asked the question on the DISCUSSiT forum, but there seems to be less and less activity there.

Redistribution into RIP

Beware any border router that has two interfaces in the RIP domain; there could be an internal loop within the RIP domain.  In particular, beware of injecting any external route that has an AD more than 120.  The injected route will go round the loop, and appear at the other interface with a greater hop count, but an AD of 120, where it will overwrite the original injected route.  The route can thrash.  Or not … if you are lucky, the updates will go both ways round the loop and meet on some other non-border router, where they are safe.  There is a similar lesson in Lab 23, but with a rather simpler loop.

8.7. BGP

I have already had a good rant about the apalling contradictory requirements of this section.  Now I must concentrate of what I can learn from this section:

• A BGP speaker, even if a route reflector, will not send a prefix to a neighbor that is in that same cluster as the one he learned it from.  The scenario leverages this behavior in an unusual way by deliberately using the feature to break reachability.
• A route reflector will not touch next-hop information.  Eeven if it has next-hop-self configured, that does not apply to reflected routes.  (The scenario was not intended to teach that but a screw-up in my topology led me down that path.)
• Interestingly, because next-hop is not touched as the route propagates along the AS 100 chain, the traffic itself takes a shortcut CAT1-R3-R4-CAT2.

I implemented the solution proposed in the AK, and it seemed to work OK.  Then, just to be perverse, I looked around for other solutions that ignored various bits of the requirements.  (Well, their solution ignores requirement 8.7.4., so I felt at liberty to keep 8.7.4 and to ignore something else instead.)  BTW, this section won’t make much sense unless you have the scenario in front of you.

I thought I would try peering R3-CAT2 and R4-CAT1.  That should inject the routes into AS 100 by two different ways, and is not expressly forbidden by the scenario.  My problem was which addresses to peer.  I had no luck peering the loopback addresses, because those have multiple paths, some going back the way you came.  I tried peering with the addresses on the 172.16.34.0/24 link, but had not luck with that either.  For some reason it does not like peering from a Virtual-Template address:

R3#
Feb 20 15:57:15.760: BGP: 172.16.46.20 active open failed - update-source Virtual-Template1
is not available, open active delayed 25730ms (35000ms max, 28% jitter)

So, I settled on these peerings:

• CAT1 (172.16.38.10) <–> R4 (172.16.46.4)
• CAT2 (172.16.46.20) <–> R3 (172.16.38.3)

Really perverse, I know.  It almost worked as well.  The only thing that didn’t work was that if I take down the peering R5<–>R3, then R5 can no longer reach 100.100.100.1.  Conversely, if I take down the peering R2<–>R4, then R2 can no longer reach 200.200.200.1.  R2 is rejecting the route to 200.200.200.0/24 because it has the same cluster-id.  Or maybe FRS is not sending it, I’m not sure.

I’ve had enough of this BGP scenario for now.  If I get time I shall try some other techniques.  I thought of making AS100 a confederation with a different AS on each router in the chain, and give R2 and R5 the same AS number.  That should do the 8.7.7. trick.  Another possiblity is to mark the route with a community that would make R2 / R5 drop it.  But that’s enough for now.

8.8. VPN

Got this bit OK, but 20 minutes was a little longer than I should have taken over it.  I must be geting tired.  The issue was to keep the infrastructure RIP routes seperate form the VPN RIP routes in R3.  (I thought they were going to implement virtual routers at some point?)  They defined the infrastructure routes as everything except the sepcific VPN routes.  I defined the infrastructure as 172.16.0.0/16 and the VPN as 10.10.0.0/16.  Six of one and half-a dozen of the other I suppose.