cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10225
Views
35
Helpful
20
Replies

NEED HELP! CONFIGURING PPPOE SERVER ON A CISCO ROUTER

MOMO
Level 1
Level 1

Hi,

 

I'm trying to simulate a PPPoE Server-SOHO Clients network in my lab and I can't make it to work. I'm not sure if I am missing something, so I badly need your help.

 

Here's the setup:

Cisco 2600 router is to be configured as PPPoE Server. One ethernet port of the router is connected to the Internet source, while the second ethernet port is connected to a Cisco switch that is also connected to 2 Windows computers (that will be used as PPPoE clients).

 

My problems:

1. PPPoE clients are not getting the correct subnet mask; instead of /24, clients are getting /32.

2. Clients do not have (or not receiving) default gateway. The only info they get from the DHCP server are: IP address, subnet mask (which is incorrect), and DNS server.

 

Below is the router config:

!
hostname PPPoE_Server
!
!
ip dhcp excluded-address 192.168.10.1 192.168.10.5
!
!
ip dhcp pool PPPoE_Clients
  network 192.168.10.0 255.255.255.0
  default-router 192.168.10.1
  dns-server 8.8.8.8
!
!
username MOMO password 123456789
!
!
bba-group pppoe PPPoE_LAB
  virtual-template 1
!
!
interface FastEthernet0/0
  description INTERNET_SOURCE
  ip address 172.16.255.254 255.255.255.0
  ip nat outside
  duplex auto
  speed auto
!
!
interface FastEthernet0/1
  no ip address
  duplex auto
  speed auto
!
!
interface FastEthernet0/1.30
  description SIMULATION_PPPoE
  encapsulation dot1Q 30
  ip nat inside
  ip virtual-reassembly
  pppoe enable group PPPoE_LAB
!
!
interface Virtual-Template1
  ip address 192.168.10.1 255.255.255.0
  peer default ip address dhcp-pool PPPoE_Clients
  ppp authentication chap callin
!

 

Will really appreciate it if you can help me.

 

 

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Momo,

1. PPPoE clients are not getting the correct subnet mask; instead of /24, clients are getting /32.

This is expected. Keep in mind that this is still PPP protocol, just carried on top of Ethernet framing. In PPP, a netmask has no meaning - that is why it is called "point-to-point". From the viewpoint of each client, there is just the client and the PPPoE access concentrator, so the client uses a netmask of /32 for itself. This is completely okay and just the way it is supposed to be.

2. Clients do not have (or not receiving) default gateway. The only info they get from the DHCP server are: IP address, subnet mask (which is incorrect), and DNS server.

I believe that they actualy receive their default gateway, but if you are using Windows as clients, these often do not display the IP default gateway address for PPPoE connections properly. Either way, they should install the default route through the PPPoE connection.

Checking through your configuration, there is a couple of changes I would like to propose:

hostname PPPoE_Server
!
ip dhcp excluded-address 192.168.10.1 192.168.10.5
!
ip dhcp pool PPPoE_Clients
  network 192.168.10.0 255.255.255.0
  default-router 192.168.10.1
  dns-server 8.8.8.8
!
username MOMO password 123456789
!
bba-group pppoe PPPoE_LAB
  virtual-template 1
!
interface FastEthernet0/0
  description INTERNET_SOURCE
  ip address 172.16.255.254 255.255.255.0
  ip nat outside
  duplex auto
  speed auto
!
interface FastEthernet0/1
  no ip address
  duplex auto
  speed auto
!
interface FastEthernet0/1.30
  description SIMULATION_PPPoE
  encapsulation dot1Q 30
  ip nat inside
  ip virtual-reassembly
  pppoe enable group PPPoE_LAB
!
interface Loopback0
ip address 192.168.10.1 255.255.255.255
!
interface Virtual-Template1 ip address 192.168.10.1 255.255.255.0
ip unnumbered Loopack0
ip nat inside
ip mtu 1492
ip tcp adjust-mss 1452
ppp mtu adaptive
peer default ip address dhcp-pool PPPoE_Clients ppp authentication chap callin

To shortly sum up the changes:

  • Using "ip nat inside" and "ip virtual-reassembly" directly on Fa0/1.30 is useless because this interface is not an IP-enabled interface at all. With PPPoE, the IP processing is done on the Virtual-Access interfaces that are cloned off the Virtual-Template interface. Therefore, all IP-related configuration regarding NAT, ACLs, etc. must come to the Virtual-Template. Remember: Fa0/1.30 does not carry native IP packets anymore; it carries Ethernet frames that contain a PPPoE header, then a PPP header, and only then the IP header.
  • The usual style of configuring Virtual-Template interface is to have it share an address with a Loopback. The advantage is that the Loopback can be configured with a netmask of /32 which is exactly appropriate for PPP environments. Other interface types won't allow you to be configured with a /32 netmask.
  • Because of added PPPoE and PPP headers, the resulting space for IP packets in an Ethernet frame is smaller by 8 bytes (PPPoE is 6 bytes, PPP is 2 bytes). Therefore, it is necessary to reduce the IP MTU on the interface by 8 bytes to 1500-8 = 1492 bytes. Also, to prevent TCP from generating segments that would need to be fragmented on this router, the "ip tcp adjust-mss" command tells the router to peek into every TCP session, and overwrite the negotiated Maximum Segment Size so that it is never larger than 1452 bytes. The 1452 bytes would be the maximum body size of a TCP segment, and then 20B TCP + 20B IP + 8B PPPoE/PPP is exactly 1500 bytes.
  • The "ppp mtu adaptive" is specifically used with Windows clients - they like to mandate their own PPP MTU, and if the peer does not comply, Windows like to tear down the PPPoE session. The "ppp mtu adaptive" is there to make Windows happy.
  • The "callin" keyword does not make much sense as you never make outbound "calls", so there is no call direction necessary to distinguish.

Try this out - and feel welcome to ask further!

Best regards,
Peter

 

View solution in original post

20 Replies 20

Peter Paluch
Cisco Employee
Cisco Employee

Hi Momo,

1. PPPoE clients are not getting the correct subnet mask; instead of /24, clients are getting /32.

This is expected. Keep in mind that this is still PPP protocol, just carried on top of Ethernet framing. In PPP, a netmask has no meaning - that is why it is called "point-to-point". From the viewpoint of each client, there is just the client and the PPPoE access concentrator, so the client uses a netmask of /32 for itself. This is completely okay and just the way it is supposed to be.

2. Clients do not have (or not receiving) default gateway. The only info they get from the DHCP server are: IP address, subnet mask (which is incorrect), and DNS server.

I believe that they actualy receive their default gateway, but if you are using Windows as clients, these often do not display the IP default gateway address for PPPoE connections properly. Either way, they should install the default route through the PPPoE connection.

Checking through your configuration, there is a couple of changes I would like to propose:

hostname PPPoE_Server
!
ip dhcp excluded-address 192.168.10.1 192.168.10.5
!
ip dhcp pool PPPoE_Clients
  network 192.168.10.0 255.255.255.0
  default-router 192.168.10.1
  dns-server 8.8.8.8
!
username MOMO password 123456789
!
bba-group pppoe PPPoE_LAB
  virtual-template 1
!
interface FastEthernet0/0
  description INTERNET_SOURCE
  ip address 172.16.255.254 255.255.255.0
  ip nat outside
  duplex auto
  speed auto
!
interface FastEthernet0/1
  no ip address
  duplex auto
  speed auto
!
interface FastEthernet0/1.30
  description SIMULATION_PPPoE
  encapsulation dot1Q 30
  ip nat inside
  ip virtual-reassembly
  pppoe enable group PPPoE_LAB
!
interface Loopback0
ip address 192.168.10.1 255.255.255.255
!
interface Virtual-Template1 ip address 192.168.10.1 255.255.255.0
ip unnumbered Loopack0
ip nat inside
ip mtu 1492
ip tcp adjust-mss 1452
ppp mtu adaptive
peer default ip address dhcp-pool PPPoE_Clients ppp authentication chap callin

To shortly sum up the changes:

  • Using "ip nat inside" and "ip virtual-reassembly" directly on Fa0/1.30 is useless because this interface is not an IP-enabled interface at all. With PPPoE, the IP processing is done on the Virtual-Access interfaces that are cloned off the Virtual-Template interface. Therefore, all IP-related configuration regarding NAT, ACLs, etc. must come to the Virtual-Template. Remember: Fa0/1.30 does not carry native IP packets anymore; it carries Ethernet frames that contain a PPPoE header, then a PPP header, and only then the IP header.
  • The usual style of configuring Virtual-Template interface is to have it share an address with a Loopback. The advantage is that the Loopback can be configured with a netmask of /32 which is exactly appropriate for PPP environments. Other interface types won't allow you to be configured with a /32 netmask.
  • Because of added PPPoE and PPP headers, the resulting space for IP packets in an Ethernet frame is smaller by 8 bytes (PPPoE is 6 bytes, PPP is 2 bytes). Therefore, it is necessary to reduce the IP MTU on the interface by 8 bytes to 1500-8 = 1492 bytes. Also, to prevent TCP from generating segments that would need to be fragmented on this router, the "ip tcp adjust-mss" command tells the router to peek into every TCP session, and overwrite the negotiated Maximum Segment Size so that it is never larger than 1452 bytes. The 1452 bytes would be the maximum body size of a TCP segment, and then 20B TCP + 20B IP + 8B PPPoE/PPP is exactly 1500 bytes.
  • The "ppp mtu adaptive" is specifically used with Windows clients - they like to mandate their own PPP MTU, and if the peer does not comply, Windows like to tear down the PPPoE session. The "ppp mtu adaptive" is there to make Windows happy.
  • The "callin" keyword does not make much sense as you never make outbound "calls", so there is no call direction necessary to distinguish.

Try this out - and feel welcome to ask further!

Best regards,
Peter

 

Hi Peter,

 

Thank you so much for your prompt reply. I will surely try your proposed changes and give you feedback. What I'm trying to accomplish here is to simulate the connection with DSL ISP, where, using PPPoE protocol, we can connect our regular home routers to their modems.

You're welcome.

In your case, based on what you said you want to achieve, there is no need to see the /24 mask on client side. You can leave as is and just add the ppp ipcp route default to get the default route.

As I mentioned, having a /24 mask instead of standard /32 is useless except in certain circumstances.

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hi Peter,

 

I implemented the changes you proposed and here are my observations:

 

1. Windows PPPoE clients connected directly to the PPPoE server get IP address, /32 subnet mask, and DNS address thru DHCP, but no default gateway. However, everything seems to work perfectly and online.

 

2. When I connected Linksys and Netgear home routers (as PPPoE client), they were able to connect to the PPPoE server. They get IP address, /32 subnet mask, correct default gateway, but no DNS address. Homes routers are online. Hosts behind the home routers can ping public IP addresses (therefore they are online), but they cannot translate the the domain names. However, everything works perfectly if I set static DNS on the home routers.

 

I'm still currently researching/investigating what may have caused why home routers cannot get DNS address (thru DHCP) from PPPoE server.

 

 

 

UPDATE: I added the following configuration and it seems to address the problem with home routers. But i'm still observing the connection.

!

interface Virtual-Template1

   ppp ipcp dns 8.8.8.8

!

 

If you have an idea, please let me know. I would really appreciate it.

 

Hi

The config i have was between Cisco devices.
For Linksys and netgear devices everything is ok.
For Windows, this is a default behavior. Can you do a route print to validate that is accessing internet through the pppoe connection?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hi Francesco,

 

You mean route print of Windows clients connected 1)directly to the PPPoE server, and 2)through the homes routers?

From home routers you said it was ok.
I meant the route print from windows machines

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Actually, there were no problems with any Windows clients connected directly to the PPPoE server. These clients do have 1) IP address, 2) /32 subnet mask, and 3)DNS address. All of them were online with no problem.

 

Problems are with those clients connected through the home routers (Linksys and Netgear) to connect to the PPPoE server. It turned out that home routers that were connected to the PPPoE server were only getting 1)IP address, 2) /32 subnet mask, and 3)default gateway. They do not get DNS address from the PPPoE server. Hence, clients behind the home routers cannot resolve domain names.

 

This problem was resolved using the following options:

1. Setting static DNS on the home routers.

2. Configuring 'ppp ipcp dns x.x.x.x' command under Interface Virtual-template

Ok then no issue anymore?

Please don't forget to rate useful answers

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Actually, I still have issues and these are:

 

1. Why are home routers, which are connected directly to PPPoE server, not getting DNS address? Please note that Windows clients that are connected directly to the same PPPoE server are able to get DNS address.

2. Is setting 'ppp ipcp dns x.x.x.x' on the PPPoE server's Interface Virtual-template1 okay to fix the DNS issue?

 

Hope that you can clarify this issue.

For DNS, on cisco devices (client devices), you need to configure ip dns server and ppp ipcp dns request.
You need to check on your home routers if there's such setting to request dns server from PPP connection

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Francesco Molino
VIP Alumni
VIP Alumni

Hi
Without doing anything, you'll always see a /32 mask requested through ppp when using ip address negotiated on the client side.

To get a /24, you need to:

 

On Server side:
interface Virtual-Template1
ppp ipcp mask 255.255.255.0

 

On Client side:
ip dhcp pool LOCAL
import all
origin ipcp
!
interface Dialer1
ip address pool LOCAL
encapsulation ppp
dialer pool 1
ppp chap hostname MOMO
ppp chap password 0 123456789
ppp ipcp mask request --> Be able to get the right subnet mask
ppp ipcp route default --> Be able to get the default route

 

The DHCP pool configured locally isn't giving any IPs to the client but just here to negotiate the right parameters like mask


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hello Francesco,

A nice and insightful response!

One thing: Indeed, with ppp ipcp netmask, we can pass a different mask to the clients, but it won't make any difference as far as data flows are concerned. Because of PPPoE, communication between hosts associated to the same access concentrator (AC) will still need to go through the AC, regardless of the netmask, so changing it won't accomplish anything.

Do you personally see any value in sending a non-/32 netmask to PPPoE clients?

Best regards,
Peter

Hi Peter

I don't know what is the real use-case for MOMO but in certain design if you want to add OSPF peering, it will be useful getting the right subnet mask.

But honestly, in my whole life, even working for ISP, using such configuration it was very rare. I used that only 2 times in very specific designs.

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco