Kevin Dorrell, CCIE #20765

24 Mar 2008

QoS study week

Filed under: Frame Relay, QoS — dorreke @ 12:33

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 BC+BE, and the bucket overflows at BC+BE, 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.

23 Mar 2008

FRTS : Frame-Relay Traffic-Shaping

Filed under: Frame Relay, QoS, WAN — dorreke @ 20:10

Cisco Documentation

Cisco Tech Notes

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

 

07 Mar 2008

Frame-Relay multipoint or physical interfaces

Filed under: Bridging on routers, EIGRP, Frame Relay, IP Multicast, OSPF, RIP — dorreke @ 11:38

 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:

Technology Gotcha Solution
RIP RIP will not normally advertise out an interface it received the route on.  Not a problem in Frame Relay because split-horizon is disabled by default, but is a problem in other NBMA technologies such as X.25. 1. no ip split-horizon on interface (by default in FR)
2. Static neighbor spoke to spoke (TTL=2)
EIGRP EIGRP will not advertise out an interface it received the route on 1. no ip split-horizon eigrp nn on interface
2. Static neighbor spoke to spoke (TTL=2)
OSPF network No LSAs seen spoke-to-spoke 1. ip ospf priority 0 on spokes to force DR on hub
2. ip ospf network point-to-multipoint throughout
OSPF NSSA If one spoke is an ASBR and talks OSPF to the hub, but another spoke does not talk OSPF but has a route to the the prefix, what can happen to the forward address.  Might be unreachable? Still thinking about this !
bridge-group No visibility spoke-to-spoke There will usually be some alternate route between the STP root and the spoke.  Contrive Spanning Tree to block all but one of the circuits on the multipoint and therefore use alternate route.
PIM dense-mode If multicast source is behind the hub, then a prune from one spoke will prune all of them.  If multicast source is on a spoke, then it will not be routed out the same interface to another spoke. Find an alternate route for all but one of the spokes, or even for all of them.  Usually, this can be done with a tunnel, or by leveraging some alternate path to the source.  Use static ip mroute
PIM sparse-mode If multicast source is on a spoke, then it will not be routed out the same interface to another spoke. ip pim nbma-mode.  Or treat in same way as dense mode above.
     

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.

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.

NMC Lab 8

Filed under: BGP, Frame Relay, IP Routing Protocols, PPP, Redistribution, RIP, WAN — dorreke @ 14:31

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.

 

 

Blog at WordPress.com.