CCIE Pursuit Blog

May 27, 2009

Core Knowledge Question of the Day: 27 May 2009

R3#sh frame map
Serial0/0 (up): ip 155.3.0.3 dlci 503(0x1F7,0x7C70), static,
broadcast,
CISCO, status defined, active
TCP/IP Header Compression (inherited), connections: 218959117
RTP Header Compression (inherited), connections: 218959117

R5#sh frame map
Serial1/0 (up): ip 155.1.0.5 dlci 305(0x131,0x4C10), static,
broadcast,
CISCO, status defined, active
TCP/IP Header Compression (enabled), connections: 256
RTP Header Compression (enabled), connections: 256

Given the above output, what is the fundamental difference between the TCP and RTP header compression configurations on R3 and R5?

Highlight for answer: On R3, TCP and RTP header compression have been enabled on the interface level as indicated by the ‘inherited’ description in the ‘show frame-relay map’ output.  On R5 it has been enabled via the frame-relay map map statement(with the keyword ‘compress’).

December 3, 2008

Verify Your FREEK

File under the category of “How the hell did I not see this before?”

I was reviewing some basic Frame Relay labs today and during a FREEK* (Frame-Relay End-to-End Keepalives) and I issued a ‘show frame pvc x’ command:

r1(config-fr-dlci)#do sh frame pvc 102

PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (EEK UP), INTERFACE = Serial0/0.12

I’ve done dozens of FREEK configurations and have never noticed the ‘EEK UP|DOWN’ in the PVC output before.  I suppose that’s because I usually just issue the ‘show frame-relay end-to-end keepalive‘ instead.  That command has a ton more information:

r2#sh frame end-to-end keepalive int s0/0.12

End-to-end Keepalive Statistics for Interface Serial0/0.12 (Frame Relay DTE)

DLCI = 201, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 12,     Receive Sequence Number: 13
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 15,     Total Observed Errors: 0
Monitored Events: 3,         Monitored Errors: 0
Successive Successes: 3,     End-to-end VC Status: UP

RECEIVE SIDE STATISTICS

Send Sequence Number: 13,     Receive Sequence Number: 12
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 15,     Total Observed Errors: 0
Monitored Events: 3,         Monitored Errors: 0
Successive Successes: 3,     End-to-end VC Status: UP

* I’m using the “politically incorrect” name because I really don’t understand why “FREEK” is offensive to anyone.

August 13, 2008

Internetwork Expert Volume II: Lab 12 – Section 8

Section 8 – QoS – 6 Points

8.1 Frame Relay Traffic Shaping

Oooh.  A VoIP issue with an interface running at less than 768K.  Time for some packet interleaving.  🙂

The task tells us that r2 and r4 have been provisioned at 512K and that we should “ensure that neither of these devices send traffic beyond this rate on this circuit.”

We also have this requirement:

“Additional VCs on r4 (DLCIs 401 and 405) should equally share the remaining bandwidth of its T1 interface to the Frame Relay cloud.”

Okay.  That bit confused me.  Basically we need to split the the remaining bandwidth (1544 – 512)/2.  In the end we’re assigning a CIR of 512 to each of the three circuits on int s0/0 of r4.

It’s the last requirement that gives us the most “actionable information”:

“In order to allow VoIP traffic to be interleaved between larger data converstions ensure that the maximum time that it takes to transmit a packet across the Frame Relay network is 10ms.”

All of that just basically means that we need to use a Tc of 10ms.

We aren’t asked to allow a burst, so we can set Be to 0.  Bc can be determined by the following formula:

Bc =  CIR * (Tc/1000)
Bc = 512000 * (10/1000)
Bc = 512000 * .01
Bc = 5120

So our map-class should be:

map-class frame-relay FRTS
 frame-relay cir 512000
 frame-relay bc 5120
 frame-relay be 0

Now we need to enable interleaving:

frame-relay fragment

Rack16R2(config-map-class)#frame ?
  fragment           fragmentation – Requires Frame Relay traffic-shaping to be configured at the interface level

Rack16R2(config-map-class)#frame frag ?
  <16-1600>  Define fragment size, Bytes
  <cr>

Okay.  So how do we come up with this value?  There’s a chart of suggested values in the frame-relay fragement documentation.  As long as the speed is under 768K We just need to convert the Bc of the lowest speed link in the path (in our case both sides are 512K) to bytes (divide by 8):

5120/8 = 640 bytes

So now we have:

map-class frame-relay FRTS
 frame-relay cir 512000
 frame-relay bc 5120
 frame-relay be 0
 frame-relay fragment 640
 frame-relay fair-queue <- IOS added this

Now apply the map-class to the DLCI:

Rack16R2(config)#int s0/0
Rack16R2(config-if)#frame interface-d 204
Rack16R2(config-fr-dlci)#class FRTS

I generally only apply traffic shaping to the specific DLCI, IE likes to apply it to the all DLCIs on the interface.  Ask your proctor. 🙂

Rack16R2(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
201           56000     875    7000      0         125       875       –
203           56000     875    7000      0         125       875       –
205           56000     875    7000      0         125       875       –
213           56000     875    7000      0         125       875       –
204           512000    640    5120      0         10        640       –  

Rack16R2#sh frame pvc 204

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 204, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 1026          output pkts 1092         in bytes 148630
  out bytes 148115         dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 254       out bcast bytes 90472
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 04:09:41, last time pvc status changed 04:08:32
  fragment type end-to-end fragment size 640
  cir 512000    bc   5120      be 0         limit 640    interval 10 
  mincir 256000    byte increment 640   BECN response no  IF_CONG no
  frags 74        bytes 9639      frags delayed 0         bytes delayed 0

  shaping inactive
  traffic shaping drops 0
  Queueing strategy: weighted fair
  Current fair queue configuration:
   Discard     Dynamic      Reserved
   threshold   queue count  queue count
    64          16           0
  Output queue size 0/max total 600/drops 0

One “gotcha” on r4 is that we already have a class applied to DLCI 504:

interface Serial0/0.54 point-to-point
 ip address 129.16.54.4 255.255.255.0
 ip ospf demand-circuit
 frame-relay interface-dlci 405
  class FREEK

We just need to add the additional FRTS configuration to that already existing map-class.  You could create only one additional map-class for both of the remaining DLCIs, but the next task will require two separate map-classes as you will tweak DLCI 402 only.

Rack16R4#sh traffic

Interface   Se0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
403           56000     875    7000      0         125       875       –
413           56000     875    7000      0         125       875       –

Interface   Se0/0.54
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
405           512000    640    5120      0         10        640       –

Interface   Se0/0.124
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
401           512000    640    5120      0         10        640       –
402           512000    640    5120      0         10        640       –

8.2 Priority Queueing

“…configure your network so that all VoIP traffic (UDP 16384 – 32767) coming from VLAN 46 going out the Frame Relay circuit to R2 gets priority over data traffic.”

“VoIP should be allocated a maximum of 192Kbps during periods of congestion on this link.”

It’s nice that IE included the VoIP protocol ports, but you should probably memorized that before the lab.  It’s pretty obvious that we’ll be configuring LLQ and mixing it with the existing FRTS configuration.

ip access-list extended TASK_8_2
 permit udp 129.16.46.0 0.0.0.255 any range 16384 32767

Rack16R4(config)#class-map TASK_8_2
Rack16R4(config-cmap)#match access-group name TASK_8_2

Rack16R4(config-ext-nacl)#policy-map TASK_8_2
Rack16R4(config-pmap)#class TASK_8_2
Rack16R4(config-pmap-c)#prio ?
  <8-2000000>  Kilo Bits per second <- KILO!!!

  percent      % of total bandwidth

Rack16R4(config-pmap-c)#prio 192

Rack16R4(config-pmap-c)#map-class frame-relay DLCI_402
Rack16R4(config-map-class)#service-policy out TASK_8_2

Configure the same thing on r2 (remember to alter the direction of your access-list).

April 28, 2008

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(0x65,0x1850), 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

April 6, 2008

Internetwork Expert Volume II: Lab 9 – Section 2

WAN Technologies – 8 Points

2.1 Partial Mesh

Subinterfaces on r3 and r4 – should I use ptp or ptm?  I read ahead to IGP to see if there’s anything that forces ptm, but I didn’t find anything.  Looks like I can use ptp.

Interesting Frame Relay network.

2.2 Point-to-Point

CCOnlinelabs throws a TON of DLCIs at you:

r3(config-if)#do sh frame pvc | i Serial0/1/0
PVC Statistics for interface Serial0/1/0 (Frame Relay DTE)
DLCI = 311, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 312, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 314, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 315, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 316, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 317, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 318, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 319, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 331, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 332, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 334, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 335, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 336, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 337, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 338, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0
DLCI = 339, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0

interface Serial0/1/0
 description ->FR PTP r5
 ip address 148.1.35.3 255.255.255.0
 encapsulation frame-relay
 shutdown
 no frame-relay inverse-arp IP 311
 no frame-relay inverse-arp IP 312
 no frame-relay inverse-arp IP 314
 no frame-relay inverse-arp IP 316
 no frame-relay inverse-arp IP 317
 no frame-relay inverse-arp IP 318
 no frame-relay inverse-arp IP 319
 no frame-relay inverse-arp IP 331
 no frame-relay inverse-arp IP 332
 no frame-relay inverse-arp IP 334
 no frame-relay inverse-arp IP 335
 no frame-relay inverse-arp IP 336
 no frame-relay inverse-arp IP 337
 no frame-relay inverse-arp IP 338
 no frame-relay inverse-arp IP 339
end

Whew!!!  🙂

 2.3 Point-to-Point

Very easy task.

2.4 Network Redundancy

If line protocol of the Frame-Relay subinterface goes down, then fire up a backup serial interface. 

In this case the subint goes down (but not the phys int) when we shut s0/0/0 on r1:

Serial0/0/0                unassigned      YES unset  up                    up
Serial0/0/0.401            148.1.0.4       YES manual down                  down

So we don’t need to worry about FREEK.

ARRGH!!! I have to use 12.3 documentation because Cisco has royally fucked up the 12.4 docs.

backup interface

backup delay

backup delay {enable-delay-period | never} {disable-delay-period | never}

r4(config-subif)#backup del 0 300

First value is the delay (in seconds) in bringing up the backup, the second value is the delay in dropping the backup when the primary path returns.  (default is 0 seconds for both)

I don’t know of a way of seeing the disable delay (outside of looking at the int config) but the “show backup” command will show the number of seconds remaining on the disable delay after the primary path returns:

r4#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial0/0/0.401     Serial0/1/0           waiting to revert (290 more seconds)

March 17, 2008

Internetwork Expert Volume II: Lab 8 – Section 2

Frame Relay – 9 Points

2.1 Hub-and-Spoke

Easy

2.2 Multilink PPP over Frame-Relay

This is the first PPP multilink over FR task I’ve encountered.  Luckily this is a technology that I use on the job so this was fairly easy.

2.3 Point-to-Point

Easy.  Because we’re using Frame inarp, just need to explicitly turn it off for the other PVCs.

I wasted a ton of time trying to reverse engineer the DLCIs on the CCOnlinelabs equipment.  DLCIs 100 and 62 (the DLCI that they supposed use) do not exist.

I finally had to strip the entire BB1 config off and then just turn on FR with an IP address on s0/0 and do the same on r6.  Frame inarp did it’s magic and you can see the results:

r6:
Serial0/0/0 (up): ip 54.1.2.254 dlci 629(0x275,0x9C50), dynamic,
              broadcast,
              CISCO, status defined, active

bb1:
Serial0/0 (up): ip 54.1.2.6 dlci 926(0x39E,0xE4E0), dynamic,
              broadcast,
              CISCO, status defined, active

So….I have DLCI 629 on r6 with 926 on bb1.  I’ve used CCOnlinelabs before and never had an issue like this.  My guess is that that the pod was set up for another vendor’s workbook.

2.4 Frame Relay Traffic Shaping

This seemed to be a very easy FRTS task. 

Bc = CIR * Tc/1000

Bc = 128000 * 125/1000
Bc = CIR * .125
BC = 16000

Without Bc configured:

r5#sh traffic | i Inter|Acc|VC|501
Interface   Se0/0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
501           128000    2000   128000    0         125       2000      –

With Bc set to 16000:

r5#sh traffic | i Inter|Acc|VC|501
Interface   Se0/0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
501           128000    2000   16000     0         125       2000      –

IE guide says to see explanation for FRTS task in lab 1.

I’ll have to review to find out why we needed to explicitly set the Bc.

Task 2.4

March 1, 2008

Using ‘frame-relay interface-dlci x protocol ip’ To Create Frame Maps

I stumbled across this post about another method to create Frame Relay mappings:

Guys,I’m just going through the [IPexpert] audio bootcamp for Frame-Relay and I’ve come across something I’m not sure of.In the lecure Scott talks about using the “frame-relay interface-dlci protocol ip” command instead of the “frame-relay map” command. I’ve never personally configured this so decided to check it out on the doc cd and found the following under the command reference :-

protocol ip ip-address
(Optional) Indicates the IP address of the main interface of a new router or access server onto which a router configuration file is to be automatically installed over a Frame Relay network. Use this option only when this device will act as the BOOTP server for automatic installation over Frame Relay.

Has anybody actually used this command before? I would try myself but my racks elsewhere at the moment. I’m sure Scott is correct and that Cisco are merely making a recommendation and that it’s not to be used in every day practice for replacing the frame map command.p.s. Couldn’t find any reference to the command in the config guide on the doc cd?

This command is used for auto-install over Frame Relay.  Further down the postings a user showed a successful Frame mapping using this command.  The one caveat is that it only works on point-to-point subinterfaces.

***Updated 02 March***

See comments about the configuration example in the Sadikhov forum.

February 18, 2008

Internetwork Expert Volume II: Lab 12 – Section 3

Section 3 – Frame Relay – 8 Points

3.1 Hub-and-Spoke

Basic hub and spoke configuration with the additional requirement of turning on CDP.

3.2 Point-To-Point

Very basic configuration.

3.3 Keepalives

This is the first lab where I’ve had to configure Frame Relay End-To-End keepalives.  Time to get my FREEK on.  🙂

Key phrases:

“having r4 and r5 poll each other”
“the other side’s interface is up and reachable every 15 seconds”

frame-relay end-to-end keepalive mode

frame-relay end-to-end keepalive timer

Defaults
Send timer: 10 seconds
Receive timer: 15 seconds

r5(config)#map-class frame KEEPALIVES
r5(config-map-class)#frame end-to-end keepalive mode bidirectional
r5(config-map-class)#frame end-to-end keepalive timer send 15

* Receive timer is 15 by default so we don’t need to configure it.

r5(config-map-class)#int s0/0.54
r5(config-subif)#frame-relay interface-dlci 504
r5(config-fr-dlci)#class KEEPALIVES

Damn my fat fingers.  I accidentally typed a subinterface that did not exist – which brought it into existence  😦

r4(config-map-class)#int s0/0.15
% Incomplete command.

r4(config-subif)#do sh ip int br
Serial0/0.15               unassigned      YES unset  up                    up

r4(config-subif)#no int s0/0.15
Not all config may be removed and may reappear after reactivating the sub-interface

I see a reload in my future.  😦

r4#sh frame end keep

End-to-end Keepalive Statistics for Interface Serial0/0 (Frame Relay DTE)

DLCI = 405, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 255,      Receive Sequence Number: 255
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 1,       Total Observed Errors: 0
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

RECEIVE SIDE STATISTICS

Send Sequence Number: 255,      Receive Sequence Number: 255
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 1,       Total Observed Errors: 0
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

3.4 Point-to-Point

Very basic configuration.

January 30, 2008

Internetwork Expert Volume II: Lab 6 – Section 2

WAN Technologies – 7 Points

2.1 Hub-and-Spoke

This was a simple Frame Relay Hub-and-Spoke configuration using physical interfaces and frame maps.  The only “twist” is the last subtask:

“Do not send any redundant broadcast traffic from the spokes to the hub.”

You only need to add the ‘broadcast’ keyword to the frame map to the hub router on the spokes:

r5(spoke):
interface Serial0/0
 ip address 191.17.125.5 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 191.17.125.1 501 broadcast <- to the hub
 frame-relay map ip 191.17.125.2 501
<-to other spoke
 no frame-relay inverse-arp

Also, IE has the interface up so Frame Relay Inverse ARP is already running:

r1(config-if)#do sh frame map
Serial0/0 (up): ip 191.17.125.2 dlci 102(0x66,0x1860), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 191.17.125.5 dlci 105(0x69,0x1890), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 191.17.34.3 dlci 103(0x67,0x1870), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 191.17.34.4 dlci 104(0x68,0x1880), dynamic,
              broadcast,, status defined, active

Use your favorite method to clear the dynamic Frame Relay mappings.  I ususally reload the routers.

2.2 Point-To-Point

“When r3 pings its own IP address, these packets should be sent to r4 and redirected back.”

This task was pretty easy for me because of all of the times that I have accidentally created a frame map with my local IP address instead of the far end IP address,  🙂

Before:
r3(config-if)#do sh run int s1/0
interface Serial1/0
 ip address 191.17.34.3 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 191.17.34.4 304 broadcast
 no frame-relay inverse-arp

r3(config-if)#do ping 191.17.34.3

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

r3(config-if)#do sh ip route 191.17.34.3
Routing entry for 191.17.34.0/24
  Known via “connected”, distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Serial1/0
      Route metric is 0, traffic share count is 1

r3(config-if)#do sh frame map
Serial1/0 (up): ip 191.17.34.4 dlci 304(0x130,0x4C00), static,
              broadcast,
              CISCO, status defined, active

After:
r3(config-if)#int s1/0
r3(config-if)#frame map ip 191.17.34.3 304
r3(config-if)#do sh frame map
Serial1/0 (up): ip 191.17.34.3 dlci 304(0x130,0x4C00), static,
              CISCO, status defined, active
Serial1/0 (up): ip 191.17.34.4 dlci 304(0x130,0x4C00), static,
              broadcast,
              CISCO, status defined, active

r3(config-if)#do p 191.17.34.3

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

2.3 Point-to-Point

“Configure the Frame Relay connection between r6 and bb1 using PVC 51 on r6’s main Serial interface.”
“Do not allow r6 to send Frame Relay Inverse-ARP requests on any other circuits assigned to this interface.”

While this task does not explicly tell you which method to use to map the IP address to the DLCI, the second subtask makes it sound like we are supposed to allow Frame Relay Inverse-ARP create our mapping on DLCI 51, but not the rest of the PVCs.

r6(config-if)#do sh frame pvc | i DLCI|Serial0/0
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 51, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0
DLCI = 201, DLCI USAGE = UNUSED, PVC STATUS = DELETED, INTERFACE = Serial0/0
DLCI = 301, DLCI USAGE = UNUSED, PVC STATUS = DELETED, INTERFACE = Serial0/0
DLCI = 401, DLCI USAGE = UNUSED, PVC STATUS = DELETED, INTERFACE = Serial0/0

r6(config-if)#no frame inverse-arp ip ?
  <16-1007>  Set DLCI for inverse ARP

  vc-bundle  vc-bundle

r6(config-if)#no frame inverse-arp ip 100
r6(config-if)#no frame inverse-arp ip 101
r6(config-if)#no frame inverse-arp ip 201
r6(config-if)#no frame inverse-arp ip 301
r6(config-if)#no frame inverse-arp ip 401

r6#sh frame map
Serial0/0 (up): ip 54.17.3.254 dlci 51(0x33,0xC30), dynamic
              broadcast,, status defined, active

2.4 PPP

An easy task asking you to configure header compression.  One twist:

“Allow for the maximum number of TCP sessions to be compressed over this link.”

ip tcp header-compression

ip tcp compression-connections

r1(config-if)#ip tcp ?
  adjust-mss               Adjust the mss of transit packets
  compression-connections  Maximum number of compressed connections
  header-compression       Enable TCP header compression

r1(config-if)#ip tcp compression-connections ?
  <1-256>  Number of connections

r1(config-if)#ip tcp compression-connections 256

r3#sh ip tcp header-compression
TCP/IP header compression statistics:
  Interface Serial1/2 (compression on, VJ)
    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: 256 rx slots, 256 tx slots,
             0 misses, 0 collisions, 0 negative cache hits, 256 free contexts

January 12, 2008

Internetwork Expert Volume II: Lab 4 – Section 2

Section 2 – Frame Relay – 6 Points

2.1 Hub-and-Spoke

Basic Hub-and-Spoke with the spokes using subinterfaces and the hub using the physical interface.

I found my third error during this task (interfaces swapped on r2).

The IE solution guide has “no frame-relay inverse-arp” configured under the physical interfaces on r1 and r3.  This is unnecessary.

2.2 Point-To-Point

Another easy Frame Relay configuration.  The only twist is that instead of giving you a series of subtasks, you are asked to configure Frame Relay to match the output of the “show frame map” command on r4 and r5.  Of course, IE already has Frame Relay running with Inverse-ARP enabled, so your initial Frame maps will be a mess:

r4#sh frame map
Serial0/0 (up): ip 141.1.54.5 dlci 405(0x195,0x6450), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 141.1.123.1 dlci 401(0x191,0x6410), dynamic,
              broadcast,
              CISCO, status defined, active
Serial0/0 (up): ip 141.1.123.2 dlci 402(0x192,0x6420), dynamic,
              broadcast,, status defined, active

2.3 Point-To-Point

Another simple Frame Relay configuration.

“Do not allow r6 to send Frame Relay Inverse-ARP requests out this interface for any protocol.”

In short, “no frame-relay inverse-arp”  🙂
 

Next Page »

Blog at WordPress.com.