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(0×131,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’).

May 26, 2009

Core Knowledge Question of the Day: 26 May 2009

R1#show frame pvc interface serial 1/0

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

Active     Inactive      Deleted       Static
Local          1            0            0            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 103, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

input pkts 0             output pkts 0            in bytes 0
out bytes 0              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 0         out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 04:48:15, last time pvc status changed 04:48:14

R1#show traffic-shape serial 1/0

Interface   Se1/0
Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
-             128000    960    3840      3840      30        480       BECN

Given the output above, which type of traffic-shaping is configured on interface s1/0?

Highlight for answer: Generic Traffic-Shaping (‘traffic-shape’ command under interface s1/0). We can tell this because the VC(virtual circuit) field in the ‘show traffic-shape serial 1/0′ output is null. This is because GTS does not support per-VC traffic-shaping.

If you answered this correctly then you’re either one smart motherfucker, or you’ve worked through the IE Volume I QoS labs.  :-)

December 16, 2008

Lab Tip: A Use For The Useless Tc Command

CCIE candidates who have spent any time playing with Frame Relay Traffic Shaping know that the ‘frame tc’ command is worthless and that you need to set the Tc by altering the Bc and/or CIR.  But I did discover a use for this command.

Say you get a task like this:

“Use the lowest interval (Tc) available”

If you have this value memorized, then you’re golden.  But if you don’t then you might spend some of your valuable lab time searching the documentation for this value….OR you could turn to the ‘frame tc’ command for help:

Rack1R3(config)#map-class frame TEST
Rack1R3(config-map-class)#frame tc ?
<10-10000>  Tc, milliseconds

Ah.  We can see that the lowest interval available is 10 milliseconds.  The maximum is the insanely high 10,000 milliseconds (10 seconds).

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.

September 21, 2008

IOS error(?) with OSPF point-to-multipoint network in PPPoFR Hub-and-Spoke Topology

How nerdy is that for a blog post title?   :-)

I’ve run up against this issue twice now.  The issue seems to be an order-of-operations issue in IOS with PPPoFR in a hub-and-spoke network running OSPF network type point-to-multipoint.  This is most likely something that you’ll (hopefully) never see in a real network.  If you do, then kick the router (and the architect) really hard and run away quickly.

In this case we’ve configured PPPoFR with R5 as the hub and R1 and R2 as the spokes.  On R5 we have two PPP circuits assigned – one assigned to each hub DLCI – to a single virtual-template.  Something like this:

r5:
int s0/0.1 multipoint <- just to make it more “interesting”   :-)
 frame-relay interface-dlci 501 ppp virtual-template 1
 frame-relay interface-dlci 502 ppp virtual-template 1

Everything was cool until I configured OSPF and noticed that I wasn’t seeing routes from r2:

RSRack12R5#sh ip route os
     128.8.0.0/16 is variably subnetted, 9 subnets, 2 masks
O IA    128.8.136.0/24 [110/2] via 128.8.125.1, 00:39:59, Virtual-Access2
O IA    128.8.63.0/24 [110/11113] via 128.8.125.1, 00:22:43, Virtual-Access2

Looking at the individual routes it looks like the router is sending traffic to r2 which should be going to r1:

RSRack12R5#sh ip route 128.8.136.0
Routing entry for 128.8.136.0/24
  Known via “ospf 100″, distance 110, metric 2, type inter area
  Last update from 128.8.125.1 on Virtual-Access2, 00:40:10 ago
  Routing Descriptor Blocks:
  * 128.8.125.1, from 150.8.1.1, 00:40:10 ago, via Virtual-Access2
      Route metric is 2, traffic share count is 1

RSRack12R5#sh ip route 128.8.125.1
Routing entry for 128.8.125.1/32
  Known via “connected”, distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Virtual-Access1
      Route metric is 0, traffic share count is 1

RSRack12R5#sh int virtual-access 2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 128.8.125.5/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP
  PPPoFR vaccess, cloned from Virtual-Template1
  Vaccess status 0×44
  Bound to Serial0/0.1 DLCI 502, Cloned from Virtual-Template1, loopback not set <-502 is r2
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:00:12, output never, output hang never
  Last clearing of “show interface” counters 02:09:09
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     7938 packets input, 609028 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     7949 packets output, 604952 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

RSRack12R5#p 128.8.136.3

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

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 28 msec 32 msec  <-should go to r1
  2  *

An IP packet debug on r5 shows that the IOS does see any problems with shipping the wrong packets to r2:

Sep  4 07:38:04.065: IP: tableid=0, s=128.8.125.5 (local), d=128.8.136.3 (Virtual-Access2), routed via FIB
Sep  4 07:38:04.069: IP: s=128.8.125.5 (local), d=128.8.136.3 (Virtual-Access2), len 100, sending
Sep  4 07:38:04.069:     ICMP type=8, code=0

It looks like the virtual-access interfaces are associated with the wrong DLCIs.  I tried a reload – no change.

I ripped out PPPoFr and readded it:

RSRack12R5#sh ip int br | i Virtu
Virtual-Access1            128.8.125.5     YES TFTP   up                    up

Virtual-Template1          128.8.125.5     YES NVRAM  down                  down

Virtual-Access2            128.8.125.5     YES TFTP   up                    up

Virtual-Access3            unassigned      YES unset  down                  down

RSRack12R5#sh int virtual-acc 1 | i Bound
  Bound to Serial0/0.1 DLCI 501, Cloned from Virtual-Template1, loopback not set
RSRack12R5#sh int virtual-acc 2 | i Bound
  Bound to Serial0/0.1 DLCI 502, Cloned from Virtual-Template1, loopback not set
RSRack12R5#sh int virtual-acc 3 | i Bound
RSRack12R5#

RSRack12R5#sh ip route 128.8.136.3
Routing entry for 128.8.136.0/24
  Known via “ospf 100″, distance 110, metric 2, type inter area
  Last update from 128.8.125.1 on Virtual-Access2, 00:02:18 ago
  Routing Descriptor Blocks:
  * 128.8.125.1, from 150.8.1.1, 00:02:18 ago, via Virtual-Access2  <- should use virtual-access1
      Route metric is 2, traffic share count is 1

Same issue:

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 28 msec 32 msec  <-should go to r1
  2  *  *

The IOS is up to date:

RSRack12R5#sh ver | i IOS|emo
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(10), RELEASE SOFTWARE (fc1)
Cisco 2611XM (MPC860P) processor (revision 3.1) with 127308K/3764K bytes of memory.

I gave up.  I did go back and check my config line by line and everything was in agreement with the IE solution guide.  I looked in my notes and I did not encounter this issue on my last attempt at this lab.  If this were the actual lab I guess that I would rip out the PPPoFR configuration and just use a conventional hub-and-spoke FR network and eat the PPPoFR points.

It appears that I’m not the only person to run up against this issue:

It looks like the fixes are:

1) Reorder the frame-relay maps:

I did that, but IOS puts them back in order:

interface Serial0/0.1 multipoint
 frame-relay interface-dlci 501 ppp Virtual-Template1
 frame-relay interface-dlci 502 ppp Virtual-Template1

But for some reason it fixed the issue:

RSRack12R5#p 128.8.136.3

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

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.1 28 msec 32 msec 29 msec
  2 128.8.136.3 32 msec *  40 msec

This fix does my fucking head in.  I actually stripped out the PPPoFR configuration before and then readded it.  The actual ORDER of configuration is important?  Even though IOS reorders the configuration lines automatically?

Unfortunately this “fix” does not survive a reload:

After reload:
RSRack12R5#p  128.8.136.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.8.136.3, timeout is 2 seconds:

Success rate is 0 percent (0/3)

RSRack12R5#trace  128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 32 msec 28 msec
  2
RSRack12R5#

2) Create a separate virtual-template for each DLCI (I think that this is what I did the first time that I ran through this lab).

interface Serial0/0.1 multipoint
frame-relay interface-dlci 501ppp Virtual-Template1
frame-relay interface-dlci 502ppp Virtual-Template2

interface Virtual-Template1
ip address 128.1.125.5 255.255.255.0
ip ospf network point-to-multipoint
!
interface Virtual-Template2
ip address 128.1.125.5 255.255.255.0
ip ospf network point-to-multipoint

RSRack12R5#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.8.2.2         0   FULL/  -        00:01:59    128.8.125.2     Virtual-Access2
150.8.1.1
         0   FULL/  -        00:01:59    128.8.125.1     Virtual-Access1

Did not work:

RSRack12R5#p  128.8.136.3

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

RSRack12R5#trace  128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 32 msec 33 msec
  2
RSRack12R5#

But if I switch the virtual-template assignment (as suggested in the forum)……still more failure:

interface Serial0/0.1 multipoint
 frame-relay interface-dlci 501ppp Virtual-Template2
 frame-relay interface-dlci 502ppp Virtual-Template1

RSRack12R5#p 128.8.136.3

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

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.229 msec 28 msec 32 msec
  2

Brian Dennis stated that the proctors do not reload your routers before grading, so I guess that I have to count on that being the case if I run across this issue in the lab.

I ran across the same issue on an IPexpert lab (mock lab 3).  I was only getting routes from one spoke in a PPPoFR PPP multilink point-to-multipoint OSPF network…with a fucking virtual link thrown in just to increase the nerdtastic design.  I had to flip the multilink assignment of (many!) frame-relay interfaces and that got is cooking once again:

interface Serial0/1/0
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 205 ppp Virtual-Template2
 frame-relay interface-dlci 206 ppp Virtual-Template1
 frame-relay interface-dlci 215 ppp Virtual-Template2
 frame-relay interface-dlci 216 ppp Virtual-Template1
 frame-relay interface-dlci 225 ppp Virtual-Template2
 frame-relay interface-dlci 226 ppp Virtual-Template1

no frame-relay interface-dlci 205 ppp Virtual-Template2
no frame-relay interface-dlci 206 ppp Virtual-Template1
no frame-relay interface-dlci 215 ppp Virtual-Template2
no frame-relay interface-dlci 216 ppp Virtual-Template1
no frame-relay interface-dlci 225 ppp Virtual-Template2
no frame-relay interface-dlci 226 ppp Virtual-Template1

frame-relay traffic-shaping
frame-relay interface-dlci 205 ppp Virtual-Template1
frame-relay interface-dlci 206 ppp Virtual-Template2
frame-relay interface-dlci 215 ppp Virtual-Template1
frame-relay interface-dlci 216 ppp Virtual-Template2
frame-relay interface-dlci 225 ppp Virtual-Template1
frame-relay interface-dlci 226 ppp Virtual-Template2

April 29, 2008

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,0x4C00), 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

 

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(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

April 10, 2008

Question Of The Day: 10 April, 2008

Topic: Frame Relay Traffic Shaping

The network engineer in charge of r1 recently configured Frame Relay Traffic Shaping.  The remote sites have complained that they are still getting too much traffic ingress on their Frame Relay connections to r1.  You agree to look at his configuration:

map-class frame-relay FRTS
 frame-relay cir 256000
 frame-relay be 12880
 frame-relay mincir 128000
 frame-relay adaptive-shaping becn
!
interface Serial1/0
 ip address 10.1.1.1 255.255.255.0
 encapsulation frame-relay
 frame-relay class FRTS
 frame-relay map ip 10.1.1.2 102 broadcast
 frame-relay map ip 10.1.1.3 103 broadcast
 no frame-relay inverse-arp

r1#sh frame map
Serial1/0 (up): ip 10.1.1.2 dlci 102(0×66,0×1860), static,
              broadcast,
              CISCO, status defined, active
Serial1/0 (up): ip 10.1.1.3 dlci 103(0×67,0×1870), static,
              broadcast,
              CISCO, status defined, active

What is the problem with this configuration?


Yesterday’s Question

Question Of The Day: 09 April, 2008 

 Topic: IP Prefix Lists

Write a single line IP prefix list called “MY_SUBNETS” that will only allow the following subnets:

10.1.1.118/26
10.1.1.118/27
10.1.1.118/28
10.1.1.118/29
10.1.1.118/30

Answer: ip prefix-list MY_SUBNETS 10.1.1.118/26 le 30

When matching on multiple, contiguous IP subnets, your ip prefix-list should be in the form: ip prefix-list NAME permit x.x.x.x/[min mask] le [max mask]

ip prefix-list

 

April 9, 2008

Internetwork Expert Volume III: Lab 5 – Section 3

WAN Technologies - 9 Points

3.1 Hub and Spoke

Strange task:

“Configure a Frame Relay connection between r1, r2, and r5 using multipoint subinterfaces on each router.”
“Do not use Inverse-ARP or more than on frame-relay map command on each router.”

I’m having trouble with only using one frame map statement on r5 (hub).  Can I use PPPoFR?

Hellz yeah I can!!!

I eventually got this correct, but I spent a ton of time running through all of the different varations of Frame Relay in my head and I couldn’t produce on that only used one frame-relay map statement on the hub.  This is a case of me reading too little into the question (it never stated that you needed to use exacly one map, just one or less) as well as not being confident of my PPPoFR implementation.  In the end, you won’t use any frame-relay map statements on any of the routers.

3.2 PPPoFR

More fun with PPPoFR.  Much easier than the last task though.  :-) 

Your connection will not come up until you configure PPP authentication so you may as well skip ahead to task 3.4 right away.

3.3 PPP

“Configure PPP on the Serial connection between r4 and r5 using dialer interfaces.”

Wow.  I had to peek the solution on this one as I haven’t done anything with dialers for ages.

r4(config-if)#do sh run | sec l0/1|Dialer
interface Serial0/1
 no ip address
 shutdown
 dialer in-band
 dialer pool-member 1

 pulse-time 1 <-IOS throws this on by default
interface Dialer0
 ip address 128.1.45.4 255.255.255.0
 encapsulation ppp
 dialer pool 1
 dialer idle-timeout 0
 dialer persistent

In the lab I would have just used PPP encapsution on the links and moved on.  I would have tried to get the points at the end of the lab if I had time.

dialer pool

dialer persistent

dialer pool-member

dialer in-band

r5#sh dialer

Se0/1 – dialer type = IN-BAND SYNC NO-PARITY
Dialer pool 1, priority 0
Idle timer (never), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Interface bound to profile Di0
Time until disconnect never

Connected to <unknown phone number>

Di0 – dialer type = DIALER PROFILE
Idle timer (never), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Number of active calls = 1

Dial String      Successes   Failures    Last DNIS   Last status
r5#

3.4 PPP Authentication

Authenticate the PPPoFR connection we configured in task 3.2 using PAP.  r6 should not authenticate BB1.

interface Serial0/0
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 301 ppp Virtual-Template1
!
interface Virtual-Template1
 ip address 54.1.8.6 255.255.255.0
 ppp authentication pap
 ppp pap sent-username ROUTER6 password 0 CISCO

That’s not working:

*Mar  8 03:56:12.058: Vi1 PAP: Using hostname from interface PAP
*Mar  8 03:56:12.058: Vi1 PAP: Using password from interface PAP
*Mar  8 03:56:12.058: Vi1 PAP: O AUTH-REQ id 11 len 18 from “ROUTER6″
*Mar  8 03:56:12.062: Vi1 PAP: I AUTH-REQ id 11 len 14 from “BB1″
*Mar  8 03:56:12.062: Vi1 PAP: Authenticating peer BB1
*Mar  8 03:56:12.062: Vi1 PPP: Sent PAP LOGIN Request
*Mar  8 03:56:12.062: Vi1 PPP: Received LOGIN Response FAIL
*Mar  8 03:56:12.062: Vi1 PAP: O AUTH-NAK id 11 len 26 msg is “Authentication failed”

No clue.  I looked at the solution guide and the only difference was that IE did not use ‘ppp authentication pap’

r6(config)#int virtual-tem 1
r6(config-if)#no ppp authen pap
r6(config-if)#
*Mar  8 04:28:40.518: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

*Mar  8 04:29:28.846: Vi1 PPP: Using default call direction
*Mar  8 04:29:28.846: Vi1 PPP: Treating connection as a dedicated line
*Mar  8 04:29:28.846: Vi1 PPP: Session handle[BA0003AB] Session id[934]
*Mar  8 04:29:28.846: Vi1 PPP: Authorization required
*Mar  8 04:29:44.958: Vi1 PPP: No authorization without authentication
*Mar  8 04:29:44.958: Vi1 PAP: Using hostname from interface PAP
*Mar  8 04:29:44.958: Vi1 PAP: Using password from interface PAP
*Mar  8 04:29:44.958: Vi1 PAP: O AUTH-REQ id 166 len 18 from “ROUTER6″
*Mar  8 04:29:44.962: Vi1 PAP: I AUTH-ACK id 166 len 5
*Mar  8 04:29:45.962: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

Really??? That was the issue?

Ummm….of course it was.  DOH!!!  I can’t believe that I fucked this up.  One of the requirements is that r6 should not authenticate BB1.  By configuring ‘ppp authentication pap’ on r6 that is exactly what I was trying to do.  Another time-wasting task.  This one was my fault though. 

 

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)

Next Page »

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 111 other followers