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 0x44
  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

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. 

 

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

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

Internetwork Expert Volume III: Lab 4 – Section 3

WAN Technologies – 11 Points

3.1 Hub and Spoke

For some reason I could not get my Frame Relay hub-and-spoke network to come up.  I quick look at the configuration showed the problem.  This is the fourth initial configuration error:

r3 – Hub:
interface Serial0/0:0
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type ansi <- from initial configuration
interface Serial0/0:0.1 multipoint
 ip address 152.1.123.3 255.255.255.0
 frame-relay map ip 152.1.123.1 301 broadcast
 frame-relay map ip 152.1.123.2 302 broadcast

r3#sh frame lmi | i TYPE
LMI Statistics for interface Serial0/0:0 (Frame Relay DTE) LMI TYPE = ANSI

r2 – Spoke:
r2#sh run | sec Serial0/0/0
interface Serial0/0/0
 no ip address
 encapsulation frame-relay
interface Serial0/0/0.1 point-to-point
 ip address 152.1.123.2 255.255.255.0
 frame-relay interface-dlci 203

r2#sh frame lmi | i TYPE
LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = CISCO

r1 – Spoke
r1#sh run | sec Serial0/0
interface Serial0/0
 no ip address
 encapsulation frame-relay IETF
 frame-relay lmi-type cisco <- from initial configuration
interface Serial0/0.1 point-to-point
 ip address 152.1.123.1 255.255.255.0
 frame-relay interface-dlci 103

r1#sh frame lmi | i TYPE
LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO

I set the LMI type on r3 to cisco (default) as that’s what my Frame Relay switch is running.

frame-relay lmi-type

r3(config-if)#frame lmi-type ?
 cisco
  ansi
  q933a

Nicely played IE.  🙂

task 3.1 : lmi type missing in SG?

3.2 PPPoFR

Crap.  This is another of those subjects that I am weak in.  Luckilly, the IE blog had a recent post that gives a very good overview of how to configure PPPoFR:

Understanding PPP over Frame Relay (PPPoFR)

frame-relay interface-dlci

interface virtual-template

This was actually a very easy configuration as the task did not require PPP authentication.

r4(config)#int virtual-template1
r4(config-if)#ip address 152.1.45.4 255.255.255.0
r4(config-if)#int s0/0
r4(config-if)#frame interface-dlci 405 ?
  ppp       Use RFC1973 Encapsulation to support PPP over FR
  switched  Define a switched DLCI
  <cr>

r4(config-if)#frame interface-dlci 405 ppp ?
  Virtual-Template  Virtual Template interface

r4(config-if)#frame interface-dlci 405 ppp virtual-Template ?
  <1-200>  Virtual-Template interface number

r4(config-if)#frame interface-dlci 405 ppp virtual-Template 1 ?
  <cr>

r4(config-if)#frame interface-dlci 405 ppp virtual-Template 1

r4#show interface virtual-template1
Virtual-Template1 is down, line protocol is down <-expected behavior
  Hardware is Virtual Template interface
  Internet address is 152.1.45.4/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Closed, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input never, output never, output hang never
  Last clearing of “show interface” counters 00:14:45
  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
     0 packets input, 0 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
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

r4#sh int virtual-access1
Virtual-Access1 is up, line protocol is up 
  Hardware is Virtual Access interface
  Internet address is 152.1.45.4/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 0x44
  Bound to Serial0/0 DLCI 405, Cloned from Virtual-Template1, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:00:02, output never, output hang never
  Last clearing of “show interface” counters 00:03:54
  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 2000 bits/sec, 2 packets/sec
  5 minute output rate 2000 bits/sec, 2 packets/sec
     153 packets input, 151680 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
     157 packets output, 151616 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

r4#p 152.1.45.5

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

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

Do the same on r5 (different IP address and DLCI obviously) et voila!

The IE solution show that they used a point-to-point subinterface on r4 (no idea why) but not on r5 for this task.  Again, no idea why?

3.3 Point-To-Point

Basic….except that I expected to be able to ping bb1 (54.1.10.254) after this step.  I’ll need to wait until I do some bridging in section 4.

Task 3.3

3.4 PPP

Basic.

3.5 PPP Authentication

Easy task because you are asked to authenticate each other using a hash (CHAP).
 

Internetwork Expert Volume III: Lab 2 – Section 3

WAN Technologies – 12 Points

3.1 Point-To-Point

Simple PTP Frame Relay configuration using the main ints and disabling Inverse-ARP.  This looks like hub and spoke, but there is nothing in the task that say that we need to be able ping from spoke to spoke.

3.2 Point-To-Point

r4 uses two point-to-point subinterfaces while r3 and r5 use main interfaces.  Keep in mind for OSPF.

3.3 Point-To-Point

Use a multipoint subinterface to connect to bb1 on DLCI 101.  Use inverse-arp. 

“Do not diable Inverse-ARP but do not allow r6 to map ununsed DLCI’s using Inverse-ARP.”

DLCIs assigned to the physical interface by defaul, so while our multipoint subinterface will have Inverse-ARP enabled by default we don’t need to do any other tweaking as only DLCI 101 will be assigned to the subinterface.

r6(config-if)#int s0/0/0.1 mul
r6(config-subif)#desc ->bb1 FR DLCI 101
r6(config-subif)#ip add 54.1.4.6 255.255.255.0
r6(config-subif)#frame interface-dlci 101

Weird…Inverse-ARP never worked….so I tried a static map:

interface Serial0/0/0
 no ip address
 encapsulation frame-relay IETF
 frame-relay lmi-type cisco
interface Serial0/0/0.1 multipoint
 description ->bb1 FR DLCI 101
 ip address 54.1.4.6 255.255.255.0
 frame-relay interface-dlci 101

r6(config)#int s0/0/0.1
r6(config-subif)#no frame-relay interface-dlci 101
r6(config-subif)#frame map ip 54.1.4.254 101 broad

r6(config-subif)#do sh frame map
Serial0/0/0.1 (up): ip 54.1.4.254dlci 101(0x65,0x1850), static,
              broadcast,
              IETF, status defined, active 

r6(config-subif)#do p 54.1.4.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 54.1.4.254, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
r6(config-subif)#do p 54.1.4.254

Here’s my problem (from CCOnlineLabs documentation):

INER6 S0/0/0 61  – INEBB1 S0/0 61

DLCI 101 is not available on r6.  I need to use DLCI 61 instead.

After the “fix”:

r6#sh frame map
Serial0/0/0.1 (up): ip 54.1.3.254dlci 61(0x3D,0xCD0), dynamic,
              broadcast,
              IETF, status defined, active

Note the IP address….WTF?!!!

I jumped on bb1 and found out that there is no 54.1.4/0/24 network configured.  Wonderful.

BB1#sh ip int br | i 54.1.4.254
BB1#sh ip int br | i 54.1.3.254
Serial0/0.61               54.1.3.254      YES manual up                    up

BB1#sh frame pvc | i 101
BB1#

Alright….I’m rolling with the 54.1.3.0/24 network….hopefully this doesn’t kick me in the nards once IGP gets routes from bb1.

After changing PTM subint to 54.1.3.6/24:

Serial0/0/0.1 (up): ip 54.1.3.254dlci 61(0x3D,0xCD0), dynamic,
              broadcast,
              IETF, status defined, active

r6#p 54.1.3.254

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

IE solution shows “54.1.1.6/24”  WTF????

Lab02 – Notes on ALL Tasks

(*) Task 3.3: diagram is wrong, R6 has 54.1.1.6/24 ( not 54.1.4.6/24) !!!

HUH???  Forget it.  If something blows up later, I’ll come back to this.

3.4 PPP

‘encap ppp’ on both sides of the link.  That’s it.  Really.

3.5 PPP Authentication

Nice and easy task as we are told to use PAP and have both routers sent their user/pass.  Just remember your ppp pap sent-username command

ppp pap sent-username

Internetwork Expert Volume II: Lab 4 – Section 3

Section 3 – HDLC/PPP – 3 Points

3.1 HDLC/PPP

A poem:

PPP
How I hate thee!

Actually, this task was easy because you are authenticating on both sides of the link.  You just have to watch out as one side uses clear-text password (PAP) and the other uses an MD5 hash (CHAP).  The hardest part is figuring out which side to configure with which authentication.

3.2 Link Efficiency

“Configure r4 and r5 to maximize efficiency on this link by guessing character streams in frames sent over the link.”

I’m thinking that this describes compression.  “guessing character streams” = predictor?   YES!!!

compress

r5(config-if)#compress ?
  lzs        lzs compression type
  mppc       MPPC compression type
  predictor  predictor compression type
  stac       stac compression algorithm
  <cr>

r5#p 141.1.45.5 re 10 size 1500

Type escape sequence to abort.
Sending 10, 1500-byte ICMP Echos to 141.1.45.5, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 20/21/24 ms

r5#sh compress detail
 Serial0/1
         Software compression enabled
         uncompressed bytes xmt/rcv 31472/31478
         compressed bytes   xmt/rcv 4251/4268
         Compressed bytes sent:      4251 bytes   0 Kbits/sec  ratio: 7.403
         Compressed bytes recv:      4268 bytes   0 Kbits/sec  ratio: 7.375
         1  min avg ratio xmt/rcv 6.826/7.056
         5  min avg ratio xmt/rcv 5.575/6.513
         10 min avg ratio xmt/rcv 5.575/6.513
         no bufs xmt 0 no bufs rcv 0
         resyncs 0
         Compression   Protocol used: Predictor 1
         Decompression Protocol used: Predictor 1

A Couple Of Must Read Posts

While blog surfing today, I came across two really excellent posts explaining a couple of “obscure” technologies.  These are must reads for CCIE candidates:

Internetwork Expert Blog:

Understanding PPP over Frame Relay (PPPoFR)– a great tutorial on PPPoFR, including when and why you would use it in the “real world.”

CCIE Candidate

area nssa translate type7 suppress-fa– Ethan Banks shares a great scenario concerning what happens when two area 0 ABRs border an NSSA area.  Who handles the 7-to-5 LSA translation?  If an ABR learns a route as an N1 from an NSSA, and the same route as an E1 from another neighbor – which does it prefer?  This is a great scenario to mock up in Dynamips.

Internetwork Expert Volume III: Lab 1 – Section 3

3 WAN Technologies

3.1 Hub and Spoke

This was an easy Hub and Spoke configuration.  The only gotcha is that the initial configurations have some of the FR ports configured with an IP address and opened up.  That means that FR Inverse-ARP is in play:

Before configuration:

r5(config)#do sh run int s0/0
interface Serial0/0
 ip address 140.1.245.5 255.255.255.0
 encapsulation frame-relay
end

r5(config)#do sh frame map
Serial0/0 (up): ip140.1.245.2 dlci 502(0x1F6,0x7C60), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 140.1.245.4 dlci 504(0x1F8,0x7C80), dynamic,
              broadcast,, status defined, active 

3.2 Point-To-Point

This was a very basic point-to-point Frame Relay configuration.

3.3 PPP Authentication

PPP is usually a time-waster for me.  I have boned up on the topic a bit and this task was very basic, so I had little trouble except for my own undoing: 

r5:
username r4 password 0 CISCO
!
interface Serial0/1
 description ->r4 PTP DTE PPP
 ip address 140.1.45.5 255.255.255.0
 encapsulation ppp
 ppp authentication chap

Debugging ppp authentication:
*Mar  1 04:14:18.396: Se0/1 PPP: Authorization required
*Mar  1 04:14:18.400: Se0/1 CHAP: O CHALLENGE id 13 len 23 from “r5”
*Mar  1 04:14:18.400: Se0/1 CHAP: I CHALLENGE id 19 len 23 from “r4”
*Mar  1 04:14:18.404: Se0/1 CHAP: Using hostname from unknown source
*Mar  1 04:14:18.404: Se0/1 CHAP: Using password from AAA 
*Mar  1 04:14:18.404: Se0/1 CHAP: O RESPONSE id 19 len 23 from “r5”

The link would not come up.  The fact that it was trying to use an AAA password made me suspect that I had misconfigured the password.  Close, I actually mucked up the username on r4:

r4(config-if)#do sh run | i username
username r4password 0 CISCO

r4(config-if)#no username r4 password 0 CISCO
r4(config)#user r5pass CISCO
r4(config)#
*Mar  1 04:15:26.552: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up

This is what the debug looks like when PPP CHAP authentication is successful:

Se0/1 PPP: Using default call direction
Se0/1 PPP: Treating connection as a dedicated line
Se0/1 PPP: Session handle[C1000004] Session id[62]
Se0/1 PPP: Authorization required
Se0/1 CHAP: O CHALLENGE id 56 len 23 from “r5”
Se0/1 CHAP: I CHALLENGE id 62 len 23 from “r4”
%LINK-3-UPDOWN: Interface Serial0/1, changed state to up
Se0/1 CHAP: Using hostname from unknown source
Se0/1 CHAP: Using password from AAA
Se0/1 CHAP: O RESPONSE id 62 len 23 from “r5”
Se0/1 CHAP: I RESPONSE id 56 len 23 from “r4”
Se0/1 PPP: Sent CHAP LOGIN Request
Se0/1 PPP: Received LOGIN Response PASS
Se0/1 PPP: Sent LCP AUTHOR Request
Se0/1 PPP: Sent IPCP AUTHOR Request
Se0/1 LCP: Received AAA AUTHOR Response PASS
Se0/1 IPCP: Received AAA AUTHOR Response PASS
Se0/1 CHAP: O SUCCESS id 56 len 4
Se0/1 CHAP: I SUCCESS id 62 len 4
Se0/1 PPP: Sent CDPCP AUTHOR Request
Se0/1 PPP: Sent IPCP AUTHOR Request
Se0/1 CDPCP: Received AAA AUTHOR Response PASS
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up

Internetwork Expert Volume III: Lab 3 – Section 3

3 WAN Technologies

3.1 Point-to-Point

This is a fairly easy task.  You just need to disable Frame Relay Inverse-ARP for all DLCIs except for certain DLCIs.  You’ll need to see which PVC are present on router and then explicitly disable Frame Relay Inverse-ARP for the ones that you do not want to dynamically create a Frame Relay map:

r4(config)#do sh frame pvc | i DLCI
DLCI = 401, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
DLCI = 402, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
DLCI = 403, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
DLCI = 405, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
DLCI = 413, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0

r4(config)#int s0/0
r4(config-if)#no frame inv ip 401
r4(config-if)#no frame inv ip 402
r4(config-if)#no frame inv ip 403
r4(config-if)#no frame inv ip 405

r4#sh frame map
Serial0/0(up): ip 190.1.34.3 dlci 413(0x19D,0x64D0), dynamic,
              broadcast,
              CISCO, status defined, active

3.2 Multipoint

“Configure the routers so that if the DLCIs between them change to inactive or deleted status the interfaces used for the Frame Relay link are brought down.”

Isn’t this just saying to use physical interfaces?

I used the physical interfaces, but IE used point-to-mulitpoint subinterfaces.  I don’t see the difference.  Maybe some future task(s) affect this choice?

3.3 Point-To-Point

Nothing to say about this very basic Frame Relay point-to-point subinterface configuration.

3.4 PPP

“Configure PPP on the Serial connection between r4 and r5.”
“To ensure connectivity across this Serial connection, do not disable the peer neighbor router generated by PPP.”

Note that the connected interfaces are NOT in the same IP subnet.  BUT you will have a host route installed on each side of the link:

r4#sh ip route | i 10.5.5.5
C       10.5.5.5/32 is directly connected, Serial0/1

r5#sh ip route | i 10.4.4.4
C       10.4.4.4/32 is directly connected, Serial0/1

Note that only the host route is installed:

r4#sh ip route 10.5.5.0
% Subnet not in table

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

This is a normal function of PPP.  There is a default command of “peer neighbor-route” configured when you enable PPP.  The trick is not how to enable this feature, but rather how to disable it:

r4(config)#int s0/1
r4(config-if)#no peer neighbor-route
r4(config-if)#do clear ip route *
r4(config-if)#do sh ip route 10.5.5.5
% Subnet not in table

r5(config)#int s0/1
r5(config-if)#no peer neighbor-route
r5(config-if)#do clear ip route *
r5(config-if)#do sh ip route 10.4.4.4
% Subnet not in table

3.5 PPP Authentication

This is a pretty straightforward task that requires you to use PAP with “ppp pap sent-username“on r5.

“r5 should not authenticate r4.”

This means that you only need to turn PAP authentication on for r4.  R5 will send a username and password to r4.  r4 will authenticate r5, but r5 will not authenticate r4.

r4#sh run | sec user|Serial0/1
username ROUTER5 password 0 CISCO
!
interface Serial0/1
 ip address 10.4.4.4 255.255.255.0
 encapsulation ppp
 ppp authentication pap

r5:
interface Serial0/1
 ip address 10.5.5.5 255.255.255.0
 encapsulation ppp
 ppp pap sent-username ROUTER5 password 0 CISCO