how-to block ads
! Last configuration change at 22:55:44 EST Sun Feb 10 2002
! NVRAM config last updated at 22:55:55 EST Sun Feb 10 2002
no service pad
service timestamps debug uptime
service timestamps log uptime
boot system flash:c806-k9osy6-mz.122-4.YA.bin
clock timezone EST -5
clock summer-time EDT recurring
ip dhcp excluded-address 10.1.1.1
ip dhcp pool LOCALPOOL
network 10.1.1.0 255.255.255.0
ip ssh time-out 120
ip ssh authentication-retries 3
description Inside interface facing private network
ip address 10.1.1.1 255.255.255.0
ip nat inside
ip tcp adjust-mss 1492
no cdp enable
hold-queue 32 in
hold-queue 100 out
description Outside interface talking PPPoE
no ip address
ip nat outside
pppoe-client dial-pool-number 1
no cdp enable
ip address negotiated
ip mtu 1492
ip nat outside
dialer pool 1
no cdp enable
ppp authentication pap callin
ppp pap sent-username
ip nat inside source route-map nonat interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 Dialer1
no ip http server
ip pim bidir-enable
access-list 1 permit 10.1.1.0 0.0.0.255 log
access-list 102 permit ip 10.0.0.0 0.255.255.255 any
no cdp run
route-map nonat permit 10
match ip address 102
line con 0
exec-timeout 120 0
line vty 0 4
access-class 1 in
exec-timeout 0 0
scheduler max-task-time 5000
ntp clock-period 17176001
* Setting routes using interface name instead of using Next Hop IP Address
Notice the ip route 0.0.0.0 0.0.0.0 Dialer1 route statement which uses interface name to send packets instead of using Next Hop IP address (i.e. ip route 0.0.0.0 0.0.0.0 22.214.171.124).
Dialer interface isn't a multi-access broadcast medium. They're point-to-point, and thus, you know exactly where to send the packet -- that is, put it on the wire and the single thing on the other end will deal with it. And in almost all dialer cases, PPP replaces that route once the link is up. The interface route is there to trigger the dialer -- in the dark days of dial-up, DSL interfaces trigger the dialer as soon as they sync so the route in unnecessary.
Broadcast medium such as Ethernet obviously is multi-access domain and is not point-to-point. Having interface name as destination to forward packets create Proxy ARP, which is setting up situation where the router is basically blindly asking "hey, who can get a packet to XXX" and trusting the first thing to answer. Back in the 80's and early 90's, that's the way things were done. The Internet was tiny, and many networks weren't connected.
Doing that today is suicide. The insecurity of such a mechanism should be obvious. The practical limitation is one of ARP Cache lookups, as you will now have an arp entry for Each. And. Every. Internet. Address. You might not realize just how many hosts you talk to every day. There have been far too many "my internet is slow" complaints from people who have done this.
* MTU Size regarding PPPoE over ATM/DSL
This FAQ provides a guaranteed working config for anyone using any ADSL PPPoE connectivity types such as Ameritech ADSL for their circuit provider and Megapath.net for ISP. It took 2 calls 2 cisco and weeks of fighting with ISP tech support, but there was a valuable lesson learned about ADSL PPPoE specifically.
The MTU on the dialer interface should be 1492 as PPPoE adds an 8 byte encapsulation header. The key is setting ip tcp adjust-mss 1440 on the inside ethernet interface. You will find many different suggestions and recommendations out there. Some will say 1492 or 1460. Some will even say 1452. 1452 MSS is pretty much the standard for DSL with a PPPoE transport. Normal MSS is 1500 bytes. But you have to account for the 40 byte IP header and the 8 byte PPPoe header. That gets you to 1452.
Following is from the mouth of Cisco, "If you have ADSL running PPPoE and run into problems resolving DNS, adjust your MTU on your ethernet interface using the command ip tcp adjust-mss 1452. This is because PPPoE requires more bits in the header packet than any other type of circuit."
The last bit of optimization is a little more subtle and is a debatable topic. As the PPPoE traffic is carried over ATM cells, it has to be chopped up before it can be transmitted. ATM cells are 53 bytes long and have a 5 byte header. So a total of 48 bytes of payload. If you were to take 1452 bytes of data and split it up across 48 byte payloads. You would come up with 30.25 cells. The .25 is a 12 byte remainder that would have to be sent in a separate ATM cell. ATM cells are always 53 bytes. So the payload would have to be stuffed with an additional 36 bytes of null data for that last chunk. So to be completely optimized you would set the MSS to 1440 to eliminate those wasted 36 bytes.
Adjusting MTU size was news to a lot of people, but the minute we did it all general connectivity problems were fixed. With this in mind, note that MTU size should not be too big in order to avoid general connectivity issue. Similarly MTU size should not be too small in order to avoid ineffective traffic flow. Feel free to experiment to set MTU size to either 1452 or 1440 to see which size brings you the most suitable result.
»VPN & Frags