How to configure pppoe server with multiple clients??
My cisco router model is : ASR 1001, ios 15.x
I had searched online, they guided to configure with ATM interface.
Does is other way to configure not using ATM interface.
The example from this lesson works, if you update the client pool:
ip local pool CLIENT 192.168.12.100 192.168.12.200
So it has always been my understanding that the #ppp chap callin command, was reserved for the calling device(Client) , yet in this configuration it’s placed on the Server (called) device is there a reason for this?
When a device receives an inbound PPP connection request, it will challenge the initiating device with either a
ppp authentication chap or a
ppp authentication chap callin The difference is that when the
callin keyword is used, the initiating router doesn’t challenge the router it is connecting to. In other words, the
callin keyword asks the router being connected to to authenticate itself.
Cisco actually has an excellent explanation:
When two devices normally use CHAP authentication, each side sends out a challenge to which the other side responds and is authenticated by the challenger. Each sides authenticates one another independently. If you want to operate with non-Cisco routers that do not support authentication by the calling router or device, you must use the ppp authentication chap callin command. When using the ppp authentication command with the callin keyword, the Access Server will only authenticate the remote device if the remote device initiated the call (for example, if the remote device “called in”). In this case, authentication is specified on incoming (received) calls only.
This was taken from this Cisco documentation.
I hope this has been helpful!
When I am doing a PPPoE home lab using EVE-NG I notice that PPPoE Session established without changing MTU and it’s work normally with MTU of 1500 bytes size in both virtual-template and dialer interfaces and I also see in PPP debug that both PPPoE server and client are negotiate to use MRU of 1500 bytes, so if you do not mind I really need to know what happened behind the scenes and how this possible since the maximum MRU size that PPP accept is 1492 bytes ??
I notice also that the ping is falling when I try to pinging the remote peer with size of 1493 and df-bit flag set and it success when the df-bit flag not set and that mean the fragmentation occur when the size is above 1492 bytes and not above 1500 bytes !!! So again if you do not mind I need to know why the fragmentation occur when the size is above the 1492 bytes and not above 1500 bytes ??? notice that the IP MTU is 1500 bytes in both virtual-template and dialer interfaces.
Ping falling prove that the maximum MRU size that PPP accept is 1492 bytes ?? correct me if I wrong ??
What you are describing is a point that is often misunderstood and it is good that you bring it up. If you have an MTU of 1500 bytes on the dialler and virtual template and you are running PPPoE, then any and all packets that are 1492 bytes and smaller will be transmitted successfully and any of size larger than 1500 will be fragmented and will pass (if the DF bit is set to 0).
The problem arises when there are packets of sizes 1493 to 1500. In this case, the virtual template and dialler will allow it through without fragmenting it but the PPPoE limitation of 1492 will drop it.
During your testing, most of the packets that were sent were of sizes smaller than 1492 so you didn’t detect any problems. MTU problems will usually show themselves as intermittent connectivity or parts of web pages not showing up, or slow traffic and broken image links. These are very difficult to diagnose.
I hope this has been helpful!
Thanks for your answer, know I know there is PPPoE limitation so if the packet size is above 1492 bytes it will be dropped but in my LAB I sent a test ping with packet size above 1492 bytes and it is go through to the destination and return reply without problem, so how this can be happened since the limitation of PPPoE will not allow packet size above 1492 bytes ?? notice that the MTU and IP MTU in both virtual-template and dialer interfaces are 1500 bytes and also my test ping was sent without df-bit set !!!
In your previous message you mentioned:
Based on this, the pings were failing at a size of 1493. In any case, I suggest you do a ping sweep with progressively larger ping MTU sizes to see at what point the MTU blocks the transmission (remember to keep DF bit set to 1). For more information about ping sweeps, take a look at this:
Also, please confirm from which and to which device you are pinging and you are able to successfully ping with frames large than 1492 bytes.
I hope this has been helpful!
My LAB contain only two routers one is the PPPoE server and the other is PPPoE client :-
And yes you are right based on my previous message the pings were failing at a size of 1493 bytes and this happened only when DF-bit set to 1, so this mean the fragmentation occur when the packet size is above 1492 bytes and as I know the IP MTU command tell the router at which size in bytes the IP packet should be fragment and since the IP MTU on both virtual-template and dialer interfaces are 1500 bytes why the fragmentation occur when the packet above the 1493 bytes and not above 1500 bytes ??
How can ping sweeps help me to figure out this ?? as I know the ping sweep increase the packet size progressively to see at which point the fragmentation occur but I already know that it’s occur at 1492 !!
If my question not clear let me know ???
Note that it is not only the IP MTU command that tells the router at which size in bytes the IP packet should be fragmented. Fragmentation can also occur due to the (default) MTU size defined on the PPPoE.
Once again, if you have an MTU of 1500 bytes on the dialer and virtual template and you are running PPPoE, then any and all packets that are 1492 bytes and smaller will be transmitted successfully. BUT, any of size larger than 1492 will be fragmented and sent or, if the DF bit is set to 1 will be dropped. The default IP MTU of 1500 on the virtual template and dialer is never actually invoked, because the smaller MTU of 1492 that is the default limit of PPPoE will always take precedence, just because it is smaller.
This is why packets above 1492 are being fragmented (or dropped in case DF=1) and not at 1500.
I hope this was helpful!
I was hoping someone could help me understand why my PPPoE connection keeps “flapping” in my lab
I am using the dialer persistent, dialer idle-timeout 0 and, no cdp enable commands.
(idk why i would need to disable cdp but I seen it earlier in this thread)
Everything works like normal but after some time my PPPoE link breaks and then re-establishes. I have the configuration of the clients dialer and fast ethernet interface below.
Also i am using 7200 routers in gns3 with the image: c7200-adventerprisek9-mz.152-4.S3
interface Dialer1 mtu 1492 ip address negotiated encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer persistent ppp chap hostname CUSTOMER ppp chap password 0 CISCO no cdp enable interface FastEthernet0/0 no ip address duplex full pppoe enable pppoe-client dial-pool-number 1
If someone could explain to me why this is happening or teach me what I can do to prevent this from happening I would greatly appreciate it. Also I can provide the Server config if you like but I dont think it is necessary (but then again what do I know i am asking for help )
PS does anyone have configuration examples of how to set the same topology up using the vpdn commands on the client?
I’d start with a couple of debug commands:
- debug ppp
- debug dialer
- debug pppoe
That should show something when it’s flapping. About VPDN, I just checked but I don’t think you can do this for PPPoE on the client. Here’s what I have on IOS 15:
Client(config)#vpdn enable Client(config)#vpdn-group MY_GROUP Client(config-vpdn)#request-dialout Client(config-vpdn-req-out)#protocol ? l2tp Use L2TP
I looked around to see if there is anything for IOS 12.4 but I don’t think so. On the ASA, it seems to be possible:
Rene thank you very much for this clarification. This makes much more sense now!
I followed your instructions and have no connectivity between my two 2811 routers each using f0/1 interfaces.
Debug pppoe commands on client shows:
R3# *Aug 9 23:36:32.747: padi timer expired *Aug 9 23:36:32.747: Sending PADI: Interface = FastEthernet0/1 *Aug 9 23:36:32.747: pppoe_send_padi: contiguous pak, size 60 FF FF FF FF FF FF 00 1C 58 6A 3E 91 88 63 11 09 00 00 00 10 01 01 00 00 01 03 00 08 36 00 00 01 00 00 06 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The same debug pppoe commands on server yield nothing
R3#sh ip int br Interface IP-Address OK? Method Status Protocol FastEthernet0/0 unassigned YES NVRAM administratively down down FastEthernet0/1 unassigned YES manual up down ATM0/0/0 unassigned YES NVRAM administratively down down Serial0/2/0 10.2.3.1 YES NVRAM up up Serial0/2/1 10.2.1.1 YES NVRAM up up FastEthernet0/1/0 unassigned YES unset up down FastEthernet0/1/1 unassigned YES unset up down FastEthernet0/1/2 unassigned YES unset up down FastEthernet0/1/3 unassigned YES unset up down Dialer1 unassigned YES manual up up Virtual-Access1 unassigned YES unset up up Vlan1 unassigned YES unset up down
R1#sh ip int br Interface IP-Address OK? Method Status Protocol FastEthernet0/0 unassigned YES NVRAM administratively down down FastEthernet0/1 unassigned YES manual up down ATM0/0/0 unassigned YES NVRAM administratively down down Serial0/2/0 10.1.3.1 YES manual up up Serial0/2/1 10.2.1.2 YES NVRAM up up FastEthernet0/1/0 unassigned YES unset up down FastEthernet0/1/1 unassigned YES unset up down FastEthernet0/1/2 unassigned YES unset up down FastEthernet0/1/3 unassigned YES unset up down Virtual-Access1 unassigned YES unset up up Virtual-Access2 unassigned YES unset down down Virtual-Template1 192.168.12.2 YES manual down down Vlan1 unassigned YES unset up down
I think there may be an issue with the protocol of Fa0/1 being down on both the client and server?
You’ve already focused in on the piece of info that’s important here: Status up and Protocol down. Now for a PPPoE situation, this is usually due to PPP configurations on the two ends of the link being incorrect. Check usernames and passwords, dial pool configs and the lot. Take a look at the available configs on the lesson page and verify that all is correct. If all else fails, check your physical cable as well, and make sure it is good and functioning correctly. If you still have problems, please share your configs on each end.
I hope this has been helpful!
Can yo describe an example of PPPoE server and Client configuration, when the client is given 2 addresses IPv4 and IPv6 (dual stack)? How works process of prefix deligation for lan part of network (topology PC(LAN)-Client(CPE)-ISP(Router)). Thanks.
In order to show how to add IPv6 to an existing PPPoE IPv4 implementation, it would take a whole new lesson. Maybe we can suggest it to Rene as a Lesson Idea to do that at some point? For the time being, let me give you a brief summary.
The first thing you would do is create a local IPv6 pool for the PPPoE server similar to the following:
ipv6 local pool PPPOE_IPv6POOL 2001:ABCD:1234:1::/60 64
This means that the pool has a prefix of /60 from which sub-prefixes of length 64 will be delegated.
Next, in the Virtual Template, the following should be added:
ipv6 address FE80::10 link-local ipv6 nd ra lifetime 21600 ipv6 nd ra interval 4 3 ipv6 enable peer default ipv6 pool PPPOE_POOL6
Note here that for IPv4, the IPv4 address to be assigned to the client is negotiated, where for IPv6 it negotiates only the interface identifier, the prefix information is performed through SLAAC. The
ipv6 nd ra commands are used to indicate the usefulness of the router as a default router on this interface. SLAAC will use this as the default gateway for any assigned IPv6 addresses.
On the client side, you should add on the Dialer interface:
ipv6 address FE80::20 link-local ipv6 address autoconfig default ipv6 enable
This results in an address assigned to the client with the associated default gateway using SLAAC.
With this configuration, both IPv4 and IPv6 will use the same PPP session. Now if you want to use prefix delegation for clients on the inside of the CPE, it would be a good idea to use DHCPv6 instead of SLAAC.
More about prefix delegation can be found here:
I hope this has been helpful!
Mine also keeps flapping and I did it exactly like in the example. I also tried using
dialer persistent dialer pool 1 dialer idle-timeout 0
to see if I could resolve to problem, but it didnt.
from debug ppp I saw that my client makes a request to terminate the connection. Why would this happen?
Can you share the specific output from your debugs?
Ok now I know pppoe is used to tunnel ppp frames in Ethernet frames…over Ethernet connections.
But I am not getting how ppp was used in dial up connections? Do we use Serial ports in dial up.?.
And how these connections or ports got changed in dsl so that we need to have pppoe…
Also how ppp is supported on telephone line both in dial up and dsl connections???
I am basically confused with connections from client device to modem and then over to isp with telephone lines…