pppoe configuration

That all looks good campared with one I used a while back.

debug ppp neg debug ppp auth

One thing might be that they are using chap and not pap.

If you havent done it before you will have to get debug working.

logg buffered debug datetime ms logg buffered 50000

debug this and that clear int di 1 sh logg

Should do it.

If this was the case, wou;ldn't I then run into an auth issue instead? IMO we don't get this far at the moment. And are you sure that DSL providers are using CHAP for consumer access? Well ... the Netgear seems to know both but how does it know which one to use as it's not configurable?

I'll try some more debugging.

Regards

fw

Hi,

I have little experience with pppoe but a quck search of the Cisco WWW site provided this URL:

Quote:

'In this example, the Cisco DSL router continuously sends PPPoE Active Discovery Initiation (PADI) frames to the ISP with no response. The PADI frame is the first in a series of PPPoE call-setup frames. If your ISP does not respond with a PPPoE Active Discovery Offer (PADO), PPPoE negotiation does not succeed. The only solution for this problem is to contact your ISP'

HTH

Regards

Darren

PPPoE is executed in two stages. The first stage is PPPoE session establishment, and the second stage is the PPP negotiation. PPPoE session must be established prior to the negotiation of standard PPP parameters ( this is when authentication will occur).

It sounds as if the PPPOE discovery stage is not completing

PPPOE discovery stage consists of the following exchanges:

. router sends a PPPoE Active Discovery Initiation (PADI) packet to ISP access device

. ISP access device send a PPPoE Active Discovery Offer (PADO) packet to router

. router sends a The PPPoE Active Discovery Request (PADR) packet to ISp access device

. ISP access device send a PPPoE Active Discovery Session-confirmation (PADS) packet to router

Use the show vpdn command to determine the state of the PPPOE session establishment

I also found that.

That would have been an option unless ...

Merv wrote:

ACK - but why and how does a dumb Netgear do it at exactly the same line?

Regards

fw

not sure if it matter but every PPOE config I have see just has

pppoe enable

you have

pppoe enable group global

what model of Netgear router ?

what are all of the parameters that you set for PPPOE on the the Netgear ?

do you specify a service-name on the Netgear ?

That's a good old FM114P

Just user name and PW

Nope.

TIA

fw

Did you have to register the MAC address of your Netgear with your ISP?

Nope.

1. disconnect cable from router that goes to DSL modem

2 clear interface counters

1. reconnect cable

1. post the output of show interface fa 0/1 after you see PADI timer expired message

Thanks, I'll do that ASAP but it'll take some time as this installation is on a different site and I'll have to talk to my friend there.

Regards

fw

Okay

Also add in a post of show version

It's a 1841 mit 12.4.18 advip - is that what you want? ;)

Regards

fw

make sure the fast ethernet interface is in up and up state

I did a test in my lab and found that debug pppoe packet still spits out padi packet even thou the configured ethernet interface is down

HUB#debug pppoe packet PPPoE control packets debugging is on HUB#

000093: *Mar 1 01:01:27.697: pppoe_send_padi: FF FF FF FF FF FF 00 B0 64 4C E5 40 88 63 11 09 00 00 00 0C 01 01 00 00 01 03 00 04 82 7C 13 20 ... HUB#sh int e 0/0 Ethernet0/0 is up, line protocol is down Hardware is AmdP2, address is 00b0.644c.e540 (bia 00b0.644c.e540) Description: +++ LAN MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 227/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:01:57, output 00:00:05, output hang never Last clearing of "show interface" counters 00:51:05 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 7 packets input, 1288 bytes, 0 no buffer Received 7 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 402 packets output, 24120 bytes, 0 underruns 13 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 14 lost carrier, 0 no carrier --More-- 000094: *Mar 1 01:01:59.801: pppoe_send_padi: FF FF FF FF FF FF 00 B0 64 4C E5 40 88 63 11 09 00 00 00 0C 01 01 00 00 01 03 00 04 82 7C 13 20 ...

Ah, you basically wanted to know if the interface is up? Yes, it is. Even if I have some PPPoE trouble, I'm not a greenhorn ;) ...

I hope to get the debugging results this evening but if it's just the interface state, I can tell you it's ok.

Regards

fw

That was the purpose of the question and the output; but please do post the requested show interface output along with debug ppoe packet output

Is the cable between the DSL modem and teh Cisco router a straight- thru or a crossover cable ?

Is the same cable used to connect DSL modem to the the Netgear router ?

What is the make and model of the DSL modem ?

Who is the ISP?

Can you connect a Windows PC and enable PPPOE client and get access ?

If so use WireShark t

to capture the PPPOE packets sent and received

Basically all the PPPOE PADI packet contains is the MAC address of the PPPOE client and it is sent with a broadcast destination MAC address.

I'll do so.

I'm not 100% sure but I suppose it's straight-thru.

Sure.

It's Sphairon Turbolink AR871C1-B - he got that one for ADSL2+ as a replacement for an Alcatel on the ADSL2 line.

It's local German provider, called m-net.

No, we don't have Billy-OS but a Mac doing the PPPoE stuff does also get access ...

... so it doesn't seem to be a MAC address issue.

Regards

fw

This is all very good info - especially the fact that connecting an Apple MAC using PPPOE also works.