We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 605 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)


361 New Members signed up the last 30 days!


100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,

Forum Replies

  1. For non-static clients’ IPs we can use local pools or dhcp:

    ! ------ R2 Client
    interface Dialer0
     ip address dhcp
    ! or
    !ip address negotiated
    ! ------ R1 Server
    ip dhcp excluded-address
    ip dhcp pool PPPoE 
    ! or
    ! ip local pool PPPoE
    interface Virtual-Template1
     peer ip address forced 
     peer default ip address dhcp-pool PPPoE
    ! or
    !peer ip address forced
    !peer default ip address pool PPPoE

    The local pools differ from the DHCP in assigning /32 to the clients.
    The OSPF RFC says that OSPF ignores subnet mask on point-to-point links, however we won’t be able to have adjacency between /24 and /32, since the client finds itself in an isolated network.

  2. 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

  3. 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!


  4. 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!


  5. Hello Hussien

    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!


35 more replies! Ask a question or join the discussion by visiting our Community Forum