Hi Rene,
I also got it working on my 1841s. The client kept on throwing up:
Sep 1 07:31:30.408: Vi1 PPP: Outbound cdp packet dropped, NCP not negotiated
And after a bit of research it was suggested to put the no cdp enable command as follows:
interface dialer 1
mtu 1492
encapsulation ppp
ip address negotiated
dialer persistent
dialer pool 1
dialer idle-timeout 0
no cdp enable
!
That fixed it. Thanks for the lesson.
Matt.
Hi, I found this interesting, but Iâm not fully clear on the bba groups vs bba global and the virtual template. I understand the example as it applies to one client, but how does it work if there are two (or more)? How do these configurations change?
Thanks!
Hello Ryan
When creating Broadband Access Group profiles, you can create either a global group or multiple non-global groups. A global group is that which is created using the bba-group ppoe global command just like Rene did in the example. The non-global groups can be created using the command bba-group ppoe group-name where the group name can be whatever you name it. Whether one profile or the other will be used depends on the PPPoE sessions that are established and what Virtual Circuit (VC) classes are used. Those can be further defined in the configuration. You can find more information about these profiles and how to configure them here.
As for the virtual templates, these can be considered the configuration that is inherited by the interface to which the client will connect. This is associated with the bba profile which will be used to connect. Finally, this is all tied together by applying the bba group to the physical interface to which the client will connect.
I hope this has been helpful!
Laz
This is helpful. One question more: can you/would you have a pppoe server-client configuration where both sides take the ip address of the underlying, directly-connected interface using ip unnumbered? EG: two routers connected on G1âG1, and both sides are ip unnumbered to their G1 interface?
Thank you
Hello again Ryan.
Yes, I guess you could do that, but it defeats the purpose of having PPPoE assign IP addresses and creating profiles and so on. And in most cases you wouldnât do that because youâd want to have multiple clients connecting to that one interface on the server and youâd need the multiple IP addresses that PPPoE can provide.
I hope this has been helpful!
Laz
Hello Rene,
I can see that the registration of a client is a timely process. Is the a command that optimizes or speed up the registration to BBA global
Thanks
Hello Rene,
In production, ISP would use fiber incoming line to company with static IP address sometime. Is this PPPoE? For static IP, how to configure on router? Thank you.
-Simon
Hello Simon
PPPoE is used for networks with shared resources such as DSL and Cable.
If you have a fibre connection to your premises, it usually does not use PPPoE. This is a dedicated link (usually metro Ethernet) to the Telcoâs network.
I hope this has been helpful!
Laz
Hi,
I think there is not enough coverage in CCNP ROUTE topics on on PPPoE vpdn and more for the exam topic. Can this be improved as per the exam guide lines
Iâll take a look, see if I need to add anything.
Hello, sir!
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.
Thank!
Best Regard,
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?
Hello Aaron
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!
Laz
Hi @ReneMolenaar,
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 ??
Hello Hussein.
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!
Laz
Hello @lagapidis,
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 !!!
Hello Hussein
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!
Laz
Hello @lagapidis
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 ???