CCIE Routing and Switching Changes Coming In August???

It’s been pretty up and down around here lately.  I totally failed my recent mock lab (downer).  Then I find out that Ethan and Victor are newly minted CCIEs (upper).  And now I hear this:

Thanks for the offer but we’ve already mapped out the v5 CoD to sync with the changes to be announced in August by Cisco for the R&S lab.

Brian Dennis, CCIE4 #2210 (R&S/ISP-Dial/Security/SP)
b—@internetworkexpert.com

Internetwork Expert, Inc.
http://www.InternetworkExpert.com

I was planning on writing a post on the subject of the thread that this nugget is pulled from (I still will once I catch up on about 99 other things), but this really socked me in the gut.  I’ve not been reading GroupStudy for the last couple of weeks (I know how I’ll be spending my lunch break), so there’s probably more information there.  I have no idea what the changes are/will be but at least it has been stated over and over again that changes are not implemented until 6 months after their announcement.  So get that lab scheduled before February of 2009. 

***Update 01 May***

It looks like the thread has been pulled from the forum.  Here’s the short version for those of you who just want the quick and dirty:

Someone posted a response as Brian Dennis to a thread about fact-checking the IE ATCOD course.  Assuming that this actually was Brian (this being the InterTubes it could have been anyone), he mentioned a new version of IEATC being developed to meet some Routing and Switching CCIE changes to be announced in August.  I quoted that in my original posting.

Here’s the longer version of the back-story:

Darby Weaver (4x lab attendee who seems to have purchased tens of thousands of dollars worth of training from most of the major CCIE vendors) posted about fact-checking the IE ATCOD course.  He believes that there are a number of important errors in that course and he had started a thread to document these errors.  Before the thread disappeared, he had only come up with a vague warning against hard-coding ‘everything’ in the lab.  He gave the examples of router-ids and speed/duplex and warned that that there are issues that you can break/induce by doing this.  As with most of his posts the word count was high, but the actionable content was low.  As well as I can recall (and I’ll be the first to admit my memory is not perfect) IE does not tell you to hard-code everything in the lab.  What they do say is that IF you are given an option of hard-coding a setting versus letting a dynamic protocol set it for you (trunk encapsulation for example) you are better served by going the 100% route by hard-coding the setting than going the 99.99% route of letting a dynamic protocol work its magic.

The troubling part of Darby’s posting was not that he was fact-checking the IE ATCOD (I believe that he stated that he owed IE a technical review(???) and that’s why Brian’s response begins with “Thanks for the offer”) but that he dropped a few bizarre allegations against (unspecified) CCIE vendors.  The two I remember are 1) A vendor asked him in an email to violate the NDA concerning the Cisco Assessor product, and 2) A vendor (or vendors) tried to get him to disclose other vendors’ training.  He’s made similar allegations about vendor ethics/training errors in the past.  You can check out this post (part way down the page you’ll hit a post that explains why he was kicked off of GroupStudy) in which he makes some vague comments about vendors other than Narbik teaching some (again unspecified) core topic(s?) incorrectly.  He openly threatened to post these errors, but when asked to specify the error(s) he never did.  The same pattern appeared to be taking place in the thread that disappeared.  It’s difficult to determine if he’s really trying to fact-check or just sully some vendors’ reputations.  Either way, the end result was pretty underwhelming considering the original threats.

Someone claiming to be Brian Dennis (Internetwork Expert founder/instructor) posted and said that IE was planning their newest version of the IE ATCOD around changes to the CCIE Routing and Switching track to be announced in August.  I have no way of verifying that this was Brian Dennis, so caveat lector.  Brian also advised Darby that he believed that he had “tool hunter” syndrome and should avoid trying to collect training from multiple vendors (a bit late for that) and instead concentrate on full-scale labs.  Darby’s response to this was something like “Point taken.  I didn’t know you were working on a new version of the COD”.  Today the thread is gone.

I’m a little disapointed because I am interested in any errors in the IE ATCOD course and was planning on following the thread.  I don’t know (nor do I want to speculate on) why the thread disappeared.  I was going to put all of this in a new post, but this seems to have run its course so I’ll just leave it as an ‘addendum’ to this post.

 

Ethan Banks and Victor Cappuccio are CCIEs!!!

Great news!!!  Ethan Banks passed his CCIE Routing and Switching Lab yesterday in RTP on his first attempt!  What an accomplishment!  Surf on over and give him some love.

Hopefully we’re in the midst of a run on CCIE numbers for bloggers.  First Shiran Guez and now Ethan.  Hopefully we’ll see Arden Packeer joining this group and make it three in a row.

Will Ethan have to change his blog name from CCIE Candidate to simply CCIE now? 

***Update 30 April***

When it rains it pours.    Another CCIE blogger has passed the lab. [HT to Marko and Arden]

Victor Cappuccio (A Networker Blog) got his digits yesterday as well.

 

Question Of The Day: 30 April, 2008

Topic: IOS

You need to add multiple lines of configuration to the following interfaces on sw1:

Fa0/1, Fa0/2, Fa0/3, Fa0/5, Fa0/7, Fa0/8, Fa0/10, Fa0/13, Fa0/14, Fa0/15, Fa0/16, Fa0/17

Can you write a single-line interface range command to apply the changes to all of these interfaces at one time?

Click Here For Answer

---

Yesterday’s Question

Question Of The Day: 29 April, 2008 

Topic: OSPF

You have the following configuration on r1.

interface Loopback0
 ip address 1.1.1.1 255.0.0.0
!
router ospf 100
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 10.1.12.1 0.0.0.0 area 0

r2 is seeng the loopback address with a /32 mask:

r2#sh ip route ospf
     1.0.0.0/32is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.1.12.1, 00:00:13, FastEthernet0/0

Using only a single command, make it so that r2 sees r1’s Loopback 0 with its configured network mask.

Answer: ip ospf network point-to-point

OSPF treats Loopback interfaces as stub networks and will advertise these networks as host routes (/32) regardless of the ‘native’ network mask. 

r1#show ip ospf interface loopback 0
Loopback0 is up, line protocol is up
  Internet Address 1.1.1.1/8, Area 0 
  Process ID 100, Router ID 1.1.1.1, Network Type LOOPBACK, Cost: 1
 Loopback interface is treated as a stub Host

To avoid this behavior you need to change the OSPF network type of the Loopback interface to point-to-point.  Why point-to-point?  Because it’s the only OSPF network type that IOS will accept for a Loopback interface:

r1(config-if)#ip ospf network non-broadcast
OSPF: Invalid type for interface
      
r1(config-if)#ip ospf network broadcast
OSPF: Invalid type for interface

r1(config-if)#ip ospf network point-to-multipoint
OSPF: Invalid type for interface

r1(config-if)#ip ospf network point-to-multipoint non-broadcast
OSPF: Invalid type for interface

After you change the Loopback interface to an OSPF point-to-point network, you will see the route on r2 as a /8.

r1(config)#interface loopback 0          
r1(config-if)#ip ospf network point-to-point

r1(config-if)#do sh ip os int lo0
Loopback0 is up, line protocol is up
  Internet Address 1.1.1.1/8, Area 0
  Process ID 100, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0×0(0)/0×0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

r2#sh ip route ospf
O    1.0.0.0/8 [110/2] via 10.1.12.1, 00:02:08, FastEthernet0/0

Internetwork Expert Volume II: Lab 5 – Section 7

QoS – 8 Points

7.1 Frame Relay Traffic Shaping

We need to configure FRTS on r1.

AIR = 512Kbps
CIR = 384Kbps
MINCIR = 256Kbps
Be = Up to port speed
Tc = 100ms

We also know that we need to use adaptive shaping.

Bc = CIR * (Tc/1000)
Be = (AR – CIR) * (Tc/1000)

Adaptive Frame Relay Traffic Shaping for Interface Congestion

Frame-Relay Traffic Shaping

We can knock out the easy ones first:

map-class frame-relay FRTS
 frame-relay cir 384000
 frame-relay mincir 256000
 frame-relay adaptive-shaping becn

Now we just need to configure Bc and Be.

Bc = CIR * (Tc/100)
Bc = 384000 * (100/1000)
Bc = 384000 * .1
Bc = 38400

Be = (AR – CIR) * (Tc/1000)
Be = (512000 – 384000) * (100/1000)
Be = (128000) * (.1)
Be = 12800

So our final map-class is:

map-class frame-relay FRTS
 frame-relay cir 384000
 frame-relay bc 38400
 frame-relay be 12800
 frame-relay mincir 256000
 frame-relay adaptive-shaping becn

r1(config#int s0/0
r1(config-if)#frame traffic
r1(config-if)#frame interface-dlci 113
r1(config-fr-dlci)#class FRTS

r1(config-if)#do sh traffic

Interface   Se0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           56000     875    7000      0         125       875       -
104           56000     875    7000      0         125       875       -
105           56000     875    7000      0         125       875       -
113           384000    6400   38400     12800     100       4800      BECN 
102           56000     875    7000      0         125       875       -

IE simply applies the map-class to the interface.  I don’t agree with their solution as all PVCs are affected and not just the PVC to r1.  Of course, only DLCI 113 is actually being used so…..ask your friendly proctor for clarification. 

7.2 RTP Header Compression

Configure the Frame connection between r3 and r4 to support RTP header compression. 

ip rtp header-compression

r3’s s0/0 is a multipoint, physical Frame-Relay interface and we need to configure this only on the DLCI to r4.  I had to peek the answer on this one.

frame-relay map ip rtp header-compression

r3(config-if)# frame-relay map ip 162.1.0.4 304 rtp header-compression ?
  active            Always compress RTP headers
  connections       Maximum number of compressed RTP connections
  passive           Compress for destinations sending compressed RTP headers
  periodic-refresh  Send periodic refresh packets
  <cr>

Ummmm….did this blow away my broadcast capability

Before:
r3(config-if)#do sh run int s0/0:0 | i 162.1.0.4
 frame-relay map ip 162.1.0.4 304 broadcast

After:
r3(config-if)#do sh run int s0/0:0 | i 162.1.0.4
 frame-relay map ip 162.1.0.4 304 rtp header-compression passive connections 15

r3(config)#do sh frame map | sec 162.1.0.4
Serial0/0:0 (up): ip 162.1.0.4 dlci 304(0×130,0×4C00), static,
              CISCO, status defined, active
              RTP Header Compression (enabled), passive (enabled), connections: 15

Make sure that you leave your broadcast keyword in your map:

frame-relay map ip 162.1.0.4 304 broadcastrtp header-compression passive connections 15

Your connections need to match on both sides:

r4(config-if)#do sh run int s0/0 | i header
 frame-relay map ip 162.1.0.3 403 broadcast rtp header-compression connections 15

r3#sh ip rtp header-compression
RTP/UDP/IP header compression statistics:
 DLCI 304        Link/Destination info: ip 162.1.0.4
  Interface Serial0/0:0 DLCI 304 (compression off, Cisco, RTP, passive)
    Rcvd:    0 total, 0 compressed, 0 errors, 0 status msgs
             0 dropped, 0 buffer copies, 0 buffer failures
    Sent:    0 total, 0 compressed, 0 status msgs, 0 not predicted
             0 bytes saved, 0 bytes sent
    Connect: 15 rx slots, 15 tx slots,
             0 misses, 0 collisions, 0 negative cache hits, 15 free contexts

7.3 Bandwidth Limiting

“…Microsoft SQL traffic is limited to an average rate of 256Kbps on r2’s connection to the Frame Realy cloud.”
“Up to 2048 SQL packets in excess of 256Kbps should be queued up by r2 before packet loss occurs.”

Sounds like queueing to me.

“Do not use an access-list to accomplish this.”

That means we’ll be using a class-map with NBAR to match the traffic.

r2(config-cmap)#match protocol ?
—output truncated—
  sqlnet            SQL*NET for Oracle
  sqlserver         MS SQL Server
—output truncated—

We need to match on MICROSOFT SQL:

class-map match-all TASK_73
 match protocol sqlserver

r2(config-if)#policy-map TASK_73
r2(config-pmap)#class TASK_73
r2(config-pmap-c)#shape average 256000
r2(config-pmap-c)#shape ?
  adaptive        Enable Traffic Shaping adaptation to BECN
  average         configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]],
                  send out Bc only per interval
  fecn-adapt      Enable Traffic Shaping reflection of FECN as BECN
  fr-voice-adapt  Enable rate adjustment depending on voice presence
  max-buffers     Set Maximum Buffer Limit
  peak            configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]],
                  send out Bc+Be per interval

shape max-buffers

r2(config-pmap-c)#shape max-buffers 2048

r2(config-pmap-c)#int s0/0/0.1
r2(config-subif)#service-policy output TASK_73

r2(config-subif)#do sh policy-map int s0/0/0.1

 Serial0/0/0.1

  Service-policy output: TASK_73

    Class-map: TASK_73 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol sqlserver
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
           256000/256000    1984   7936      7936      31        992

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         0         0         0         0         no

    Class-map: class-default (match-any)
      23 packets, 2598 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

 

Internetwork Expert Volume II: Lab 5 – Section 6

IPv6 – 12 Points

6.1 IPv6 Addressing

Very basic IPv6 addressing task.

6.2 IPv6 over Frame Relay

Easy IPv6 over Frame Relay task. 

The IE solution configured a link-local address on r1 and r3.  I did not.  This is a point-to-point connection so I saw no need for a link-local address.

Task 6.2

I did configure the link-local addresses on r2, r3, and r4 (along with frame maps) but it looks like those addresses and maps were not needed (actually, they used them later in the BGP IPv6 sections).

6.3 IPv6 BGP Advertisements

6.4 IPv6 BGP Summarization

6.5 IPV6 BGP

Since IPv6 BGP is not on the exam I simply read the solution guide for task 6.3 – 5 and configured my routers to match.

Question Of The Day: 29 April, 2008

Topic: OSPF

You have the following configuration on r1.

interface Loopback0
 ip address 1.1.1.1 255.0.0.0
!
router ospf 100
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 10.1.12.1 0.0.0.0 area 0

r2 is seeng the loopback address with a /32 mask:

r2#sh ip route ospf
     1.0.0.0/32is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.1.12.1, 00:00:13, FastEthernet0/0

Using only a single command, make it so that r2 sees r1’s Loopback 0 with its configured network mask.

Click Here For The Answer

---

Yesterday’s Question

Question Of The Day: 28 April, 2008 

Topic: Frame Relay Traffic Shaping

Here is the current configuration for r1’s Frame Relay connection:

interface Serial1/0
 no ip address
 encapsulation frame-relay
!
interface Serial1/0.12 point-to-point
 ip address 10.1.12.1 255.255.255.0
 frame-relay interface-dlci 102

Configure r1 to match this output:

r1#show traffic-shape

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

Answer:

map-class frame-relay FRTS
 frame-relay cir 512000
 frame-relay bc 51200
 frame-relay be 25600
 frame-relay adaptive-shaping becn
!
interface Serial1/0
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial1/0.12 point-to-point *
 ip address 10.1.12.1 255.255.255.0
 frame-relay interface-dlci 102
  class FRTS

* There are actually three ways to apply this map-class to achieve the output in the question:

1)  Apply it to DLCI 102 only (method shown above).  Configure frame-relay traffic-shaping on the physical interface.  The subinterface will inherit that setting.  Next, configure the FRTS class under the frame-relay interface-dlci command.

interface Serial1/0
 frame-relay traffic-shaping
interface Serial1/0.12 point-to-point
 frame-relay interface-dlci 102
  class FRTS

2)  Configure frame-relay traffic-shaping on the physical interface.  The subinterface will inherit that setting.  Next, configure the FRTS class on the subinterface with the frame-relay class command.  This will apply the FRTS map-class to all DLCIs assocatiated with the s1/0.12 subinterface.  Since we’re using a point-to-point subinterface (only one DLCI allowed) we achieve the same results as method 1.  Keep in mind that if this is a multipoint subinterface this method would apply the map-class to all DLCIs associated with that subinterface.

interface Serial1/0
 frame-relay traffic-shaping
interface Serial1/0.12 point-to-point
 frame-relay class FRTS

3)  Configure frame-relay traffic-shaping on the physical interface.  The subinterface will inherit that setting.  Next, configure the FRTS class on the physical interface with the frame-relay class command.  All subinterfaces will inherit this map-class.  In our example we only have a single subinterface configured so this will achieve the same result as methods 1 and 2. 

interface Serial1/0
 frame-relay traffic-shaping
 frame-relay class FRTS

The biggest ‘gotcha’ with FRTS on subinterfaces is that you need to turn frame-relay traffic-shaping on for the physical interface.  If we add another subinterface to serial1/0 then we’ll end up with that subinterface inheriting a default frame-relay map-class (methods 1 and 2) or the FRTS map-class (method 3).

Methods 1 and 2:
r1(config-subif)#do sh traffic

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

Interface   Se1/0.13
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           56000     875    7000      0         125       875       -  

Method 3:
r1(config-if)#do sh traffic

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

Interface   Se1/0.13
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           512000    9600   51200     25600     100       6400      BECN

So how did we reverse-engineer the values for our map-class?  Let’s look at the original output:

r1#show traffic-shape

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

VC= Virtual Circuit (DLCI) = 102
Access-List = access-group assigned to the interface = none
Target Rate= CIR = 512Mbps
Byte Limit= Bc + Be in bytes = 9600 (multiply by 8[bit] to get 76800 which jives with our Bc (51200) + Be (25600))
Sustain bits/int= Bc = 51200
Excess bits/int = Be = 25600
Interval (ms) = Tc in milliseconds = 100 ms
Increment (bytes)= No idea    It looks like it may be the Bc in bytes.
Adapt Active= Adaptive Shaping mechanism (if any) =  BECN (reduce to MINCIR value if a BECN is detected)

From this information we should be able to build our Frame Relay map-class:

map-class frame-relay FRTS
 frame-relay cir 512000 <- Target Rate
 frame-relay bc 51200 <- Sustain bits/int
 frame-relay be 25600 <- Excess bits/int 
 frame-relay adaptive-shaping becn <- Adapt Active

One thing to note is that you cannot determine the MINCIR value from the output provided.  Since we’re using adaptive shaping, there must be a MINCIR value established.  This is the tranmit rate that the interface will use if it detects a BECN.  By default this value is set to half of the CIR.  In our case the CIR is 512000 so our MINCIR is 256000:

r1(config-map-class)#do sh frame pvc 102 | b Shaping
  Shaping adapts to BECN
  pvc create time 00:28:39, last time pvc status changed 00:27:25
  cir 512000    bc 51200     be 25600     byte limit 9600   interval 100
  mincir 256000    byte increment 6400  Adaptive Shaping BECN
  pkts 370       bytes 30031     pkts delayed 0         bytes delayed 0       
  shaping inactive   
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/40, 0 drop, 0 dequeued

I didn’t give that information in this question because the output explicitly shows you the Be and Bc values.    Technically I did not give you sufficient information to complete this task as the MINCIR value could have been set to a non-default value (384000) and you would not have known about it from the output provided.

The second point it that the Interval is derived from the formula (using a little bit of basic algebra):

Bc = CIR * (Tc/1000)
Bc/CIR = Tc/1000
(Bc/CIR)*1000 = Tc
Tc = (Bc/CIR)*1000
Tc = (51200/512000) * 1000
Tc = .1 * 1000
Tc = 100

My point is that you do not need to explicitly set the Tc with the ‘frame-relay tc’ command.  In fact, if you do try to set it after setting Bc and CIR, it will not change your Tc:

Let’s try to change the Tc:
r1(config)#map-class frame-relay FRTS
r1(config-map-class)#frame-relay tc 50r1(config-map-class)#do sh traffic

 

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

As you can see, the Interval does not change.  If we want to set it to 50 ms, then we need to alter the Bc value.  In this case we would just cut it in half:

r1(config)#map-class frame-relay FRTS
r1(config-map-class)#frame-relay bc 25600 
r1(config-map-class)#do sh traffic

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    6400   25600     25600     50        3200      BECN

 

Internetwork Expert Volume II: Lab 5 – Section 5

Exterior Gateway Routing – 10 Points

4.1 BGP Peering

Basic peering task.  Keep in mind that sw3 and sw4 don’t have an IGP running.

I’m still having problems with know when to apply ‘next-hop-self’.  I need to do some more work on BGP.

Task 4.1 – BGP Next-Hop-Self

4.2 AS-Path Manipulation

We need to make sure that the private AS’s do not get outside of AS 300:

Before:
r4#sh ip bgp quote _650.._
BGP table version is 10, local router ID is 150.1.4.4
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.1.9.0/24     162.1.0.3                              0 300 65002 65034 i
*> 150.1.10.0/24    162.1.0.3                              0 300 65002 65034 i
*> 162.1.7.0/24     162.1.0.2                              0 300 65001 i
*> 162.1.18.0/24    162.1.0.3                              0 300 65002 i

r3#sh ip bgp neigh 162.1.0.4 adv
BGP table version is 10, local router ID is 150.1.3.3
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
*> 28.119.16.0/24   162.1.0.4                              0 100 54 i
*> 28.119.17.0/24   162.1.0.4                              0 100 54 i
*> 150.1.9.0/24     162.1.38.8                             0 65002 65034 i
*> 150.1.10.0/24    162.1.38.8                             0 65002 65034 i
*>i162.1.7.0/24     162.1.27.7               0    100      0 65001 i
*> 162.1.18.0/24    162.1.38.8               0             0 65002 i
*> 205.90.31.0      162.1.13.1                             0 200 254 ?
*> 220.20.3.0       162.1.13.1                             0 200 254 ?
*> 222.22.2.0       162.1.13.1                             0 200 254 ?

Total number of prefixes 9

r3(config)#ip as-path access-list 42 perm _650.._
r3(config)#route-map TASK_42 deny 10
r3(config-route-map)# match as-path 42
r3(config-route-map)#route-map TASK_42 perm 1000
r3(config-route-map)#router bg 300
r3(config-router)#neigh 162.1.0.4 route-map TASK_42 out
r3(config-router)#neigh 162.1.13.1 route-map TASK_42 out

After:
r3#sh ip bgp neigh 162.1.0.4 adv
BGP table version is 10, local router ID is 150.1.3.3
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
*> 205.90.31.0      162.1.13.1                             0 200 254 ?
*> 220.20.3.0       162.1.13.1                             0 200 254 ?
*> 222.22.2.0       162.1.13.1                             0 200 254 ?

Total number of prefixes 3

r4#sh ip bgp
BGP table version is 14, local router ID is 150.1.4.4
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
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i
*> 205.90.31.0      162.1.0.3                              0 300 200 254 ?
*> 220.20.3.0       162.1.0.3                              0 300 200 254 ?
*> 222.22.2.0       162.1.0.3                              0 300 200 254 ?

My solution works (umm…technically   ), but I’m actually filtering off the routes (which I did not think broke the task).  There’s a much easier way:

neighbor remove-private-as

Usage Guidelines
This command is available for external BGP (eBGP) neighbors only.

When an update is passed to the external neighbor, if the autonomous system path includes private autonomous system numbers, the software will drop the private autonomous system numbers.

If the autonomous system path includes both private and public autonomous system numbers, the software considers this to be a configuration error and does not remove the private autonomous system numbers.

If the autonomous system path contains the autonomous system number of the eBGP neighbor, the private autonomous system numbers will not be removed.

If this command is used with confederation, it will work as long as the private autonomous system numbers follow the confederation portion of the autonomous path.

The private autonomous system values are from 64512 to 65535.

There is a much better solution.  The prefixes are still advertised to the eBGP neighbor but do not show up on the neighbor:

r3#sh ip bgp neigh 162.1.0.4 adv
BGP table version is 10, local router ID is 150.1.3.3
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
*> 28.119.16.0/24   162.1.0.4                              0 100 54 i
*> 28.119.17.0/24   162.1.0.4                              0 100 54 i
*> 150.1.9.0/24     162.1.38.8                             0 65002 65034 i
*> 150.1.10.0/24    162.1.38.8                             0 65002 65034 i
*>i162.1.7.0/24     162.1.27.7               0    100      0 65001 i
*> 162.1.18.0/24    162.1.38.8               0             0 65002 i
*> 205.90.31.0      162.1.13.1                             0 200 254 ?
*> 220.20.3.0       162.1.13.1                             0 200 254 ?
*> 222.22.2.0       162.1.13.1                             0 200 254 ?

Total number of prefixes 9

r4#sh ip bgp neigh 162.1.0.3 routes
BGP table version is 20, local router ID is 150.1.4.4
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.1.9.0/24     162.1.0.3                              0 300 i
*> 150.1.10.0/24    162.1.0.3                              0 300 i
*> 162.1.7.0/24     162.1.0.2                              0 300 i
*> 162.1.18.0/24    162.1.0.3                              0 300 i
*> 205.90.31.0      162.1.0.3                              0 300 200 254 ?
*> 220.20.3.0       162.1.0.3                              0 300 200 254 ?
*> 222.22.2.0       162.1.0.3                              0 300 200 254 ?

Total number of prefixes 7

4.3 BGP Filtering

Configure a new loopback interface on r5 and advertise it into BGP.  r4 should not pass this prefix on.  Configure this on r5.

Use the ‘no-advertise’ BGP community.

set community

(Optional) Well know communities can be specified by using the following keywords:

•internet
•local-as
•no-advertise
•no-export

ip prefix-list TASK_43 seq 5 permit 162.1.15.0/24
!
route-map TASK_43 permit 10
 match ip address prefix-list TASK_43
 set community no-advertise
!
route-map TASK_43 permit 1000
!
router bgp 500
 neighbor 150.1.4.4 send-community  <- don’t forget this line
 neighbor 150.1.4.4 route-map TASK_43 out

r4#sh ip bgp 162.1.15.0
BGP routing table entry for 162.1.15.0/24, version 22
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer)
Flag: 0×880
  Not advertised to any peer 
  500
    150.1.5.5 (metric 66) from 150.1.5.5 (150.1.5.5)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-advertise

IE used an as-path access-list matching ^$ instead of a prefix-list matching the network.  Both methods work, but the IE method would match any additional networks that you decide to advertise on r5 in the future.

4.4 BGP Table Stability

Pretty simple task using BGP dampening on routes learned from BB3 with the variables specified in the task.

bgp dampening

half-life: 15 minutes
reuse: 750
suppress: 2000
max-suppress-time: 4 times half-life

We are asked to set the max-suppress-time to 30 minutes.  This can be usually be done two ways.  Set the max-suppress-time to number of minutes specified, or set the half-life to 1/4 of that amount.  In this task we cannot use 1/4 of the max-suppress-time (30 minutes) for the half-life because it is not a whole number (7.5).

(Optional) Maximum time (in minutes) a route can be suppressed. The range is from 1 to 20000; the default is 4 times the half-life. If the half-life value is allowed to default, the maximum suppress time defaults to 60 minutes. When the max-suppress-time is configured, the maximum penalty will never be exceeded, regardless of the number of times that the prefix dampens. The maximum penalty is computed with the following formula:

Max penalty = reuse-limit *2^(maximum suppress time/half time)

I applied the dampening only to routes from AS 54:

r4(config)#ip as-path access-list 44 permit ^54$
r4(config)#route-map TASK_44 permit 10
r4(config-route-map)#match as-path 44
r4(config-route-map)#set dampening 15 1000 3000 30
r4(config-route-map)#router bgp 100
r4(config-router)#bgp dampening route-map TASK_44

The IE solution applied BGP dampening to all prefixes on r4???

Task 4.4

r4#sh ip bgp dampening parameters
 dampening 15 1000 3000 30 (route-map TASK_44 10)
  Half-life time      : 15 mins       Decay Time       : 370 secs
  Max suppress penalty:  4000         Max suppress time: 30 mins
  Suppress penalty    :  3000         Reuse penalty    : 1000

 

Internetwork Expert Volume II: Lab 5 – Section 3

Interior Gateway Routing – 20 Points

3.1 OSPF

You need to configure OSPF over the partial-mesh Frame Relay cloud, but you cannot change the OSPF network type on r3:

r2(config-router)#do sh ip os int s0/0/0.1 | i Type
  Process ID 100, Router ID 150.1.2.2, Network Type POINT_TO_POINT, Cost: 64

r3(config-router)#do sh ip os int s0/0:0 | i Type
  Process ID 100, Router ID 150.1.3.3, Network Type NON_BROADCAST, Cost: 65

r4(config-router)#do sh ip os int s0/0 | i Type
  Process ID 100, Router ID 150.1.4.4, Network Type NON_BROADCAST, Cost: 65

r5(config-router)#do sh ip os int s0/0 | i Type
  Process ID 100, Router ID 150.1.5.5, Network Type NON_BROADCAST, Cost: 65

So all that really means is that you’ll need to use the OSPF non-broadcast network type.  You’ll also need to configure neighbor statements.  Since r3 is the only device with direct connections to all of the other routers, you’ll want to make it the DR.

r3(config-router)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.2.2         0   FULL/DROTHER    00:01:46    162.1.0.2       Serial0/0:0
150.1.5.5         0   FULL/DROTHER    00:01:51    162.1.0.5       Serial0/0:0
150.1.4.4         0   FULL/DROTHER    00:01:51    162.1.0.4       Serial0/0:0

The only point that I wasn’t clear on was whether or not to establish a neighbor relationship between r4 and r5.  I did not configure them as peers, but I would have clarified this with the proctor.  If you were to peer these routers then you would need to make one of them the DR so you would need to remove the ‘ip ospf priority 0′ on one of the routers.  You would also need to configure a neighbor statement on the DR.

The IE solution did not peer these routers.

3.2 OSPF

Configure OSPF area 27 on sw1 and then ensure that the only OSPF route it will see is a default route generated by r2.  This sounds like a totally stubby area:

Before:
sw1#sh ip route os
     162.1.0.0/24 is subnetted, 5 subnets
O IA    162.1.55.0 [110/66] via 162.1.27.2, 00:00:15, Vlan27
O IA    162.1.0.0 [110/65] via 162.1.27.2, 00:00:15, Vlan27
O IA    162.1.5.0 [110/66] via 162.1.27.2, 00:00:15, Vlan27
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
O IA    150.1.5.5/32 [110/66] via 162.1.27.2, 00:00:15, Vlan27
O IA    150.1.4.4/32 [110/66] via 162.1.27.2, 00:00:15, Vlan27
O IA    150.1.3.3/32 [110/66] via 162.1.27.2, 00:00:15, Vlan27
O IA    150.1.2.2/32 [110/2] via 162.1.27.2, 00:00:15, Vlan27

After:
r2(config)#router os 100
r2(config-router)#area 27 stub no-summary

sw1(config)#router os 100
sw1(config-router)#area 27 stub

sw1#sh ip route os
O*IA 0.0.0.0/0 [110/2] via 162.1.27.2, 00:00:41, Vlan27

3.3 EIGRP

“Enable EIGRP on all interfaces of sw2, but do not use redistribution or more than one network statement to accomplish this.”

sw2(config)#ip routi
sw2(config)#router ei 200
sw2(config-router)#net 0.0.0.0

sw2(config-router)#do sh ip ei int
IP-EIGRP interfaces for process 200

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Vl8                0        0/0         0       0/10           0           0
Vl88               0        0/0         0       0/10           0           0
Fa0/15             1        0/0         1       0/10          50           0
Po32               0        0/0         0       0/10           0           0
Lo0                0        0/0         0       0/10           0           0

3.4 EIGRP

Configure EIGRP to use bandwidth, delay, and load to compute the EIGRP metric.  Bandwidth should be three times more significant than either delay or load.

metric weights (EIGRP)

Command Defaults
tos: 0
k1: 1
k2: 0
k3: 1
k4: 0
k5: 0

You need to be careful with these k-values.  You can use the EIGRP metric equation to decipher which k-value refers to with metric variable:

If k5 equals 0, the composite EIGRP metric is computed according to the following formula:

metric = [k1 * bandwidth + (k2 * bandwidth)/(256 - load) + k3 * delay]

If k5 does not equal zero, an additional operation is performed:

metric = metric * [k5/(reliability + k4)]

k1 = bandwidth
k2 = load
k3 = delay

sw2(config-router)#metric weights 0 3 1 1 0 0

r3(config-router)#do sh ip proto | i EIGRP metric
  EIGRP metric weight K1=3, K2=1, K3=1, K4=0, K5=0

3.5 Default Routing

Configure r3 to adverise a default route to the rest of the OSPF network.

“In order to help prevent traffic black holses ensure that r3 drops traffic for all destinations it does not have a longer match for.”

default-information originate (OSPF)

The software still must have a default route for itself before it generates one, except when you have specified the always keyword.

(Optional) Always advertises the default route regardless of whether the software has a default route.

The IE solution guide has a nice write up about the benifits and pitfalls of the ‘always’ keyword.

3.6 Routing Redundancy

Configure r5 to use the PTP serial interface (no advertised into any IGP) if the Frame Relay connection is lost.  You are allowed to use static routes to accomplish this.

Sounds like a floating static route to me (I wish I would have recognized this on a recent Mock Lab…oh well).

r5(config)#ip route 0.0.0.0 0.0.0.0 162.1.45.4 111

r4(config)#do sh ip route | i via 162.1.0.5
O       162.1.55.0/24 [110/66] via 162.1.0.5, 00:11:12, Serial0/0
O       162.1.5.0/24 [110/66] via 162.1.0.5, 00:11:12, Serial0/0
O       150.1.5.5/32 [110/66] via 162.1.0.5, 00:11:12, Serial0/0

r4(config)#ip route 162.1.55.0 255.255.255.0 162.1.45.5 111
r4(config)#ip route 162.1.5.0 255.255.255.0 162.1.45.5 111
r4(config)#ip route 162.1.5.5 255.255.255.255 162.1.45.5 111

r4(config)#router os 100
r4(config-router)#redist static subnets

Let’s test this by shutting down r5’s connection to the Frame cloud:
r5(config)#int s0/0
r5(config-if)#shut

r5#sh ip route | b Gate
Gateway of last resort is 162.1.45.4 to network 0.0.0.0 

     162.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       162.1.45.4/32 is directly connected, Serial0/1
C       162.1.45.0/24 is directly connected, Serial0/1
C       162.1.55.0/24 is directly connected, FastEthernet0/1
C       162.1.5.0/24 is directly connected, FastEthernet0/0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.5.0 is directly connected, Loopback0
S*   0.0.0.0/0 [111/0] via 162.1.45.4 

I did run into a problem with connectivity between r3 and r5:

r3#p 162.1.55.5

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

r3#p 162.1.5.5

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

r3#p 162.1.45.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 162.1.45.5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

r3#p 150.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

r3#sh ip route 162.1.45.5
% Subnet not in table

Makes sense since it’s not being advertised via an IGP (we’ll take care of this during the redistribution task).

r3#sh ip route 150.1.5.5
Routing entry for 150.1.0.0/16
  Known via “eigrp 200″, distance 90, metric 207460, type internal
  Redistributing via eigrp 200
  Last update from 162.1.38.8 on FastEthernet0/0, 00:53:52 ago
  Routing Descriptor Blocks:
  * 162.1.38.8, from 162.1.38.8, 00:53:52 ago, via FastEthernet0/0
      Route metric is 207460, traffic share count is 1
      Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Ummmm…..I think I missed a “no auto-summary” somewhere. 

sw2(config-router)#do sh run | b router ei
router eigrp 200
 network 0.0.0.0
 metric weights 0 3 1 1 0 0
 auto-summary

sw2(config-router)#router ei 200
sw2(config-router)#no au

I’ve been doing that a lot lately. 

r3#sh ip route 150.1.5.5
% Subnet not in table

That’s odd, I thought that I had a floating static route to the loopback on r4:

r4#sh run | i ip route
ip route 162.1.5.0 255.255.255.0 162.1.45.5 111
ip route 162.1.5.5 255.255.255.255 162.1.45.5 111
ip route 162.1.55.0 255.255.255.0 162.1.45.5 111

Damn these fat fingers!!!!

r4(config)#no ip route 162.1.5.5 255.255.255.255 162.1.45.5 111
r4(config)#ip route 150.1.5.5 255.255.255.255 162.1.45.5 111

r3#sh ip route | i 150.1.5.
O E2    150.1.5.5/32 [110/20] via 162.1.0.4, 00:00:33, Serial0/0:0

r3#p 150.1.5.5

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

Much better.

3.7 RIPv2

Easy RIP task.  One slight twist:

“As an additional security precaution configure r1 and r6 so that no unautorized devices can receive RIP updates sent out on VLAN 162.”

neighbor (RIP)

The IE solution guide has r6 advertising VLAN 6 into RIP although it is not mentioned in the task (although it does look like it should be advertised into RIP based on the IGP drawing).

3.8 IGP Redistribution

“Redistribute in the minumum places necessary to gain full reachability thoughout the network.”
“Routers in the OSPF domain should have the miniumum amount of routes neeeded to reach the RIP routes learned from bb3.”
“Do not overlap any address space to accomplish this.”

If you hadn’t figured out that they were asking for a summary route that last requirement kind of makes it obvious.

r4#sh ip route rip
     31.0.0.0/16 is subnetted, 4 subnets
R       31.3.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       31.2.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       31.1.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       31.0.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
     30.0.0.0/16 is subnetted, 4 subnets
R       30.2.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       30.3.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       30.0.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       30.1.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0

We can try to do this with a single summary but we’ll be overlapping address space, so we need two /14 summaries:

r4(config)#router os 100
r4(config-router)#summary-address 30.0.0.0 255.252.0.0
r4(config-router)#summary-address 31.0.0.0 255.252.0.0

r4#sh ip os sum

OSPF Process 100, Summary-address

30.0.0.0/255.252.0.0 Metric 16777215, Type 0, Tag 0
31.0.0.0/255.252.0.0 Metric 16777215, Type 0, Tag 0

The redistribution task was fairly easy.  There are no mutiple points of mutual redistribution between two protocols.  The only ‘gotcha’ is to remember to advertise the s0/1 interface into OSPF on r4.  This will ensure that we have reachability to 162.1.45.5 if the s0/0 interface goes down on r5 (task 3.6)

With r5’s s0/0 shut down:
r3#p 162.1.45.5

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

The IE solution guide has some strangeness on r3:

Task 3.8 on solution guide Why only VLAN162 in

Internetwork Expert Volume II: Lab 5 – Section 2

Bridging and Switching – 16 Points

2.1 VLAN Assignments

Easy enough task with all four switches running in VTP Transparent mode.  I actually finished all of the Layer 2 tasks (including Frame Relay) and then came back to this task to see which VLANs would need to be added.  The only connection that was not working was r4 (fa0/0 in VLAN4 on sw2) to BB3 (VLAN 4 on sw3).  There was no direct trunk between sw2 and sw3 so I need to add VLAN 4 to sw1:

sw1(config)#vlan 4
sw1(config-vlan)#exit

r4#p 204.12.1.254

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

The IE solution is missing VLAN 2005 on sw1.

2.2 Etherchannel

Easy EtherChannel task.

2.3 Load Distribution

Configure an EtherChannel so that it is optimized for multiple clients behind sw1 reaching a single server behind sw2.

We can use the example cited here:

Load Balancing and Forwarding Methods

port-channel load-balance

We want sw1 (workstations) to use source-based forwarding and sw2 (single server) to use destination-based forwarding.  This will most widely balance our traffic.

dst-ip
 Load distribution is based on the destination host IP address.
 
dst-mac
 Load distribution is based on the destination host MAC address. Packets to the same destination are sent on the same port, but packets to different destinations are sent on different ports in the channel.
 
src-dst-ip
 Load distribution is based on the source and destination host IP address.
 
src-dst-mac
 Load distribution is based on the source and destination host MAC address.
 
src-ip
 Load distribution is based on the source host IP address.
 
src-mac
 Load distribution is based on the source MAC address. Packets from different hosts use different ports in the channel, but packets from the same host use the same port.

Do we want to source on MAC or IP address????

sw2(config)#port-channel load-balance ?
  dst-ip       Dst IP Addr
  dst-mac      Dst Mac Addr
  src-dst-ip   Src XOR Dst IP Addr
  src-dst-mac  Src XOR Dst Mac Addr
  src-ip       Src IP Addr
  src-mac      Src Mac Addr

Task 2.3

For this task traffic from the file server located behind BB2 will be sent across the trunk with the source MAC address of BB2’s Ethernet interface and source IP address of this server. By default all of this traffic would use only one of the Etherchannel trunk links since the default is to load balance based on the source MAC address. With IP address destination based load balancing enabled on SW2 this traffic will now be distributed across both links. Traffic destined to BB2 will have the same source MAC address of R1, the same destination MAC address of BB2 and the same destination IP address, so we need IP address source based load balancing on SW1.

sw1#show etherchannel load-balance
EtherChannel Load-Balancing Operational State (src-ip):
Non-IP: Source MAC address
  IPv4: Source IP address
  IPv6: Source IP address

sw2#show etherchannel load-balance
EtherChannel Load-Balancing Operational State (dst-ip):
Non-IP: Destination MAC address
  IPv4: Destination IP address
  IPv6: Destination IP address

2.4 CAM Table Maintenance

“…configure sw2 so that it discards inactive entries from VLAN 8 and VLAN 88 after 10 seconds.”

mac address-table aging-time

Defaults
The default is 300 seconds.

sw2(config)#mac-address-table aging-time 10 vlan 8
sw2(config)#mac-address-table aging-time 10 vlan 88

sw2#sh mac address-table aging-time
Vlan    Aging Time
—-    ———-
   1     300
  27     300
   4     300
 162     300
   8      10
  88      10

2.5 EtherChannel

Basic layer 3 EtherChannel.  You get to set up an EtherChannel with only one connection. 

 

Internetwork Expert Volume II: Lab 5 – Section 1

WAN Technologies – 9 Points

1.1 Partial Mesh Frame Relay

IE switched up the order in this lab and started with Frame Relay.  I skipped ahead and did section 2 (Bridging and Switching) first and then returned to this section.

Easy task.  First time that I’ve seen IE use a dedicated DLCI between two spokes (well…’would be spokes’).

“Traffic from r5 destined for r2 should transit r4.”

Traffic will follow this path:

R5 (504) -> (405) r4 (403) -> (304) r3 (302) -> (203) r2.

r5#trace 162.1.0.2

Type escape sequence to abort.
Tracing the route to 162.1.0.2

  1 162.1.0.48 msec 4 msec 4 msec
  2 162.1.0.3 4 msec 4 msec 4 msec
  3 162.1.0.28 msec *  4 msec

1.2 Point-to-Point Frame Relay

Easy task.

1.3 Point-to-Point Frame Relay

Interesting task.  You need to match this Frame mapping on r6:

r6#sh frame map
Serial0/0.1(up): ip 54.1.1.254 dlci 101(0×65,0×1850), dynamic,
              broadcast,, status defined, active

So you need to use a subinterface as well as Frame Inverse-ARP.  That means that you’ll need to use a multipoint subinterface as inarp will not run on a point-to-point subinterface.

r6#sh run | sec l0/0
interface Serial0/0
 no ip address
 encapsulation frame-relay
interface Serial0/0.1 multipoint
 ip address 54.1.1.6 255.255.255.0
 frame-relay interface-dlci 101

1.4 PPP

“…configure r4 and r5 to support reliable transport over the circuit.”

???

A quick search of the (12.3) Master Command Index for the term ‘reliable’ pulled this up:

ppp reliable-link

You can use the show interface command to determine whether LAPB has been established on the link. You can troubleshoot PPP reliable link by using the debug lapb command and the debug ppp negotiations, debug ppp errors, and debug ppp packets commands.

r4#sh int s0/1 | sec LAPB
  LAPB DTE, state CONNECT, modulo 8, k 7, N1 12048, N2 3
      T1 3000, T2 0, interface outage (partial T3) 0, T4 0, PPP over LAPB
      VS 3, VR 3, tx NR 3, Remote VR 3, Retransmissions 0
      Queues: U/S frames 0, I frames 0, unack. 0, reTx 0
      IFRAMEs 19/19 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0, loopback not set

r5#sh int s0/1 | sec LAPB
  LAPB DCE, state CONNECT, modulo 8, k 7, N1 12048, N2 3
      T1 3000, T2 0, interface outage (partial T3) 0, T4 0, PPP over LAPB
      VS 0, VR 0, tx NR 0, Remote VR 0, Retransmissions 0
      Queues: U/S frames 0, I frames 0, unack. 0, reTx 0
      IFRAMEs 32/32 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0, loopback not set