Skip navigation
Cisco Learning Home > Certifications > Discussions

_Communities

This Question is Answered 1 Helpful Answer available (2 pts)
2812 Views 3 Replies Latest reply: Apr 26, 2010 6:31 AM by mwhisen RSS

Currently Being Moderated

PPPoFR??

Apr 25, 2010 7:33 PM

mwhisen 46 posts since
Oct 1, 2009

So looking in the blue print I see that this is a topic, and one that I have not worked a lot with. So I created a little scenerio where I would have (3) routers R1, R2, R3 and below is my config

 

! R1
interface Virtual-Template1
ip address 123.123.123.1 255.255.255.0
ppp chap password 0 cisco
!
username R1 password 0 cisco
username R2 password 0 cisco
username R3 password 0 cisco
!
interface Serial0/0/0:0
no ip address
encapsulation frame-relay
frame-relay interface-dlci 102 ppp Virtual-Template1
frame-relay interface-dlci 103 ppp Virtual-Template1
no frame-relay inverse-arp
!

! R2
interface Virtual-Template1
ip address 123.123.123.2 255.255.255.0
ppp chap password 0 cisco
!
username R1 password 0 cisco
username R2 password 0 cisco
username R3 password 0 cisco
!
interface Serial0/0/0:0
no ip address
encapsulation frame-relay
frame-relay interface-dlci 201 ppp Virtual-Template1
frame-relay interface-dlci 203 ppp Virtual-Template1
no frame-relay inverse-arp
!

! R3
interface Virtual-Template1
ip address 123.123.123.3 255.255.255.0
ppp chap password 0 cisco
!
username R1 password 0 cisco
username R2 password 0 cisco
username R3 password 0 cisco
!
interface Serial0/0/0:0
no ip address
encapsulation frame-relay
frame-relay interface-dlci 301 ppp Virtual-Template1
frame-relay interface-dlci 302 ppp Virtual-Template1
no frame-relay inverse-arp
!

 


Now it took a bit longer for the PPP to come up, and I was about to debug ppp auth to see if I had some issue (only thing that I could think about). But everything came up, and once the Virtual-Access interfaces came up I was able to ping the remote site. Now my issue, which I have tried to search on the doc cd unsuccessfully, and have not locate a means under the Virtual-template 1 interface to get the router to ping it's local interface. Maybe that is not a possible goal or even possible.

 

So I turned on (handy in a lab, do not do this on your production network without updating youre resume first! ) debug IP packet... R1, R2, R3

 

I was expecting to see an encapsulation failure, but nope.. Then I checked the counters on the virtual-access 2 and 3. Both show onlu 64 bytes in 4 packets. The S0/0/0:0 does show 582 bytes, some ppp ongoing traffic and what appears as my 500 bytes...

 

Now with ppp, and the output it would APPEAR (seeking validation here) that the packet is being chopped into ppp across both virtual-access interfaces and naturally the other side can not reassemble them? The remote end does not decode the debug ip packet, and counters are not meaningful. Just trying to understand it, so if I am going down a rat hole, I can place some C4 and close it really quick....

 


*Apr 26 02:19:30.959: IP: tableid=0, s=0.0.0.0 (local), d=123.123.123.1 (Virtual-Access3), routed via RIB
*Apr 26 02:19:30.959: IP: s=123.123.123.1 (local), d=123.123.123.1 (Virtual-Access3), len 100, sending.
*Apr 26 02:19:32.959: IP: tableid=0, s=0.0.0.0 (local), d=123.123.123.1 (Virtual-Access2), routed via RIB
*Apr 26 02:19:32.959: IP: s=123.123.123.1 (local), d=123.123.123.1 (Virtual-Access2), len 100, sending.
*Apr 26 02:19:34.959: IP: tableid=0, s=0.0.0.0 (local), d=123.123.123.1 (Virtual-Access3), routed via RIB
*Apr 26 02:19:34.959: IP: s=123.123.123.1 (local), d=123.123.123.1 (Virtual-Access3), len 100, sending.
*Apr 26 02:19:36.959: IP: tableid=0, s=0.0.0.0 (local), d=123.123.123.1 (Virtual-Access2), routed via RIB
*Apr 26 02:19:36.959: IP: s=123.123.123.1 (local), d=123.123.123.1 (Virtual-Access2), len 100, sending.
*Apr 26 02:19:38.959: IP: tableid=0, s=0.0.0.0 (local), d=123.123.123.1 (Virtual-Access3), routed via RIB
*Apr 26 02:19:38.959: IP: s=123.123.123.1 (local), d=123.123.123.1 (Virtual-Access3), len 100, sending.
Success rate is 0 percent (0/5)

 

Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 123.123.123.1/24
  MTU 1500 bytes, BW 100000 Kbit/sec, 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/0:0 DLCI 102, Cloned from Virtual-Template1, loopback not set
  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 00:00:23
  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
     4 packets input, 64 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
     4 packets output, 56 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     2 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

 

R1#sh int s0/0/0:0
Serial0/0/0:0 is up, line protocol is up
  Hardware is GT96K Serial
  MTU 1500 bytes, BW 1536 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  6, LMI stat recvd 6, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:08, output 00:00:02, output hang never
  Last clearing of "show interface" counters 00:01:01
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1152 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     30 packets input, 582 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
     30 packets output, 510 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
  Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags

  • Keith Barker - CCIE RS/Security, CISSP 5,351 posts since
    Jul 3, 2009
    Currently Being Moderated
    1. Apr 25, 2010 9:42 PM (in response to mwhisen)
    Re: PPPoFR??

    mwhisen-

     

    Scott Morris had answered this question somewhere else, and so instead of retyping it all, here it is.

     

    Begin quote:

     

    If you want to ping your local interface there are two methods….

     

    1: Use “ip unnumbered loopback ‘x’” and move the IP to that  loopback.

     

    -or-

     

    2: Use “ppp multilink group ‘x’” and move the IP to  “interface multilink ‘x’”

     

    The “interface multilink” actually allows you to ping it.  Since the  interface is there, and is “up” by virtue of having a participating  Layer2 connection in the bundle, it’s reachable.  It is not dependent on  the template.

     

    Kind of a strange thing in the “order” that IOS looks at things in  determining reachability.  With PPPoFR, you are pulling your address  from the virtual template.  For many things, IOS treats the template  LIKE an interface (hence your show commands) although it really cannot  move traffic.  So when it shows up first in the list of “where is this  IP so I can ping it” nothing actually works.

     

    A multilink interface on the other hand is actually used for moving  IP traffic and passing it off to the bundle member Layer2 links, so it  IS a viable interface and thus you can ping it.

     

    End quote:

     

    Best wishes,

     

    Keith

     

     

    PS Scott, if any of that is not accurate, you can blame it on a lousy cut/paste job by me.  

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,396 posts since
    Oct 7, 2008
    Currently Being Moderated
    Re: PPPoFR??

    heheheh...   No, you're good on that.   I was just going to refer him to the blogs that were done on it!  Has nice configs and stuff to make things prettier!

     

    http://blog.ine.com/2009/12/03/ping-thyself-yet-again-pppofr/

    http://blog.ine.com/2009/12/02/ping-thyself-in-frame-relay/

     

    Scott

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)