Thank you - both are Windows XP machines with no firewall etc. I have tried another machine just to try and see....
Also, I tried the notebooks on a x-over cable back to back and can ping full 1500 no problem... The entire config looks like this: pseudowire-class test encapsulation l2tpv3 sequencing both ip local interface Loopback0 ! interface Loopback0 ip address 192.168.254.1 255.255.255.255 ! interface FastEthernet0/0 ip address 10.0.0.2 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 no ip address duplex auto speed auto no cdp enable xconnect 192.168.254.2 1234 pw-class test ! router ospf 1 log-adjacency-changes redistribute connected subnets network 10.0.0.0 0.0.0.255 area 0 Take care, Paul -----Original Message----- From: Ge Moua [mailto:[email protected]] Sent: Thursday, February 26, 2009 12:51 PM To: Paul Stewart Cc: [email protected] Subject: Re: [c-nsp] l2tpv3 config - MTU question Ok, I see. Are you seeing this with more than one test workstation. I wonder if it is a end-station issue. df=off should allow for large ping payloads what is the syntax you are using on the end-workstation. Regards, Ge Moua | Email: [email protected] Network Design Engineer University of Minnesota | Networking & Telecommunications Services Paul Stewart wrote: > Thank you ... > > Perhaps I should have explained a little more in depth - my problem at this > moment is that with dfbit=off I still cannot do a ping larger than 1472 and > can't understand why it's NOT being fragmented....;) > > Cheers, > > Paul > > > -----Original Message----- > From: Ge Moua [mailto:[email protected]] > Sent: Thursday, February 26, 2009 12:11 PM > To: Paul Stewart > Cc: [email protected] > Subject: Re: [c-nsp] l2tpv3 config - MTU question > > We've got about a half-dozen sites deployed on this, with about 1000 > user base total, and it's running most fine, caveats: > * watch out for VTP as thiere may be some out of order packets that > causes VTP convergence to fail; run the CE side in vtp transparent mode > and add vlan manually > * another trick we've been think about is adjusting MTU on the end > workstations > * mtu 1472 works fine as defrag/frag will happen on the pe/ce equipment; > no worries with running high cpu on end-workstation due to frag/defrag > operations > * "clear ip tra" & "sh ip tra" will show frag stat on routers > > hope this helps. > > Regards, > Ge Moua | Email: [email protected] > > Network Design Engineer > University of Minnesota | Networking & Telecommunications Services > > > > Paul Stewart wrote: > >> Thanks - yes, absolutely and I can figure that into the equation. Been >> reading a lot of discussions in archives and Google about this. I want to >> ensure that however/where we deploy this that we can provide a full 1500 >> > MTU > >> *without* having desktops make MTU adjustments basically.... at the >> > expense > >> of fragmentation and CPU (which we can account for). No matter what I've >> tried so far I can't get a ping through our pair of test routers larger >> > than > >> 1472 though yet.... >> >> This avoids websites being unreachable (Microsoft comes to mind) and other >> MTU annoyances we've encountered over time... >> >> Paul >> >> >> -----Original Message----- >> From: Ge Moua [mailto:[email protected]] >> Sent: Thursday, February 26, 2009 11:50 AM >> To: Paul Stewart >> Cc: [email protected] >> Subject: Re: [c-nsp] l2tpv3 config - MTU question >> >> I was tackling a similar issue over here too, I think it may have to do >> with the fact that l2tpv3 and ethernet headers are taking some of the >> mtu allocation. >> >> Regards, >> Ge Moua | Email: [email protected] >> >> Network Design Engineer >> University of Minnesota | Networking & Telecommunications Services >> >> >> >> Paul Stewart wrote: >> >> >>> Hi folks. >>> >>> >>> >>> I've setup a pair of 1841's back to back for testing l2tpv3 deployment >>> > for > >>> >>> >> a >> >> >>> client.. >>> >>> >>> >>> FastE0/0 from each 1841 is connected to one another at 10.0.0.0/24 - each >>> router has a loopback of 192.168.254.1 and .2 - OSPF is running and am >>> >>> >> able >> >> >>> to successfully ping each other's loopback with redistributed subnets >>> >>> >> etc.. >> >> >>> >>> >>> Configured each router to look like this: >>> >>> >>> >>> pseudowire-class test >>> >>> encapsulation l2tpv3 >>> >>> sequencing both >>> >>> ip local interface Loopback0 >>> >>> >>> >>> interface FastEthernet0/0 >>> >>> ip address 10.0.0.2 255.255.255.0 >>> >>> duplex auto >>> >>> speed auto >>> >>> >>> >>> interface FastEthernet0/1 >>> >>> no ip address >>> >>> duplex auto >>> >>> speed auto >>> >>> no cdp enable >>> >>> xconnect 192.168.254.2 1234 pw-class test >>> >>> >>> >>> Have a notebook hooked up to each FastE0/1 port and assigned 172.16.0.1 >>> >>> >> and >> >> >>> .2 on them. I can ping back and forth proving connectivity etc. >>> >>> >>> >>> My problem/question is how to get a packet of 1500 bytes to transverse >>> > the > >>> link - obviously fragmented but that's ok. In the real-world >>> > deployment > >>> of this setup we are limited to 1500 MTU in most situations and will >>> >>> >> presume >> >> >>> no mini-jumbo support anywhere (from a config perspective at least). >>> >>> >>> >>> In my first config I had Path MTU discovery enabled and could only ping >>> > up > >>> to 1440 bytes. With that disabled I can now ping to 1472 but not beyond. >>> >>> >> >> >>> >>> >>> With Path MTU turned on it looked like this: >>> >>> >>> >>> site2#sh l2tun session all >>> >>> >>> >>> %No active L2F tunnels >>> >>> >>> >>> L2TP Session Information Total tunnels 1 sessions 1 >>> >>> >>> >>> Session id 53211 is up, tunnel id 32076 >>> >>> Call serial number is 1293300000 >>> >>> Remote tunnel name is site1 >>> >>> Internet address is 192.168.254.1 >>> >>> Session is L2TP signalled >>> >>> Session state is established, time since change 00:26:44 >>> >>> 114 Packets sent, 116 received >>> >>> 30446 Bytes sent, 29032 received >>> >>> Last clearing of "show vpdn" counters never >>> >>> Receive packets dropped: >>> >>> out-of-order: 0 >>> >>> total: 0 >>> >>> Send packets dropped: >>> >>> exceeded session MTU: 1 >>> >>> total: 1 >>> >>> Session vcid is 1234 >>> >>> Session Layer 2 circuit, type is Ethernet, name is FastEthernet0/1 >>> >>> Circuit state is UP >>> >>> Remote session id is 22201, remote tunnel id 12358 >>> >>> Session PMTU enabled, path MTU is 1500 bytes >>> >>> DF bit on, ToS reflect disabled, ToS value 0, TTL value 255 >>> >>> No session cookie information available >>> >>> UDP checksums are disabled >>> >>> SSS switching enabled >>> >>> Sequencing is on >>> >>> Ns 114, Nr 116, 0 out of order packets received >>> >>> Unique ID is 1 >>> >>> >>> >>> %No active PPTP tunnels >>> >>> >>> >>> >>> >>> Upon looking further I could see the DF bit on which I believe would >>> >>> >> explain >> >> >>> the 1440 byte limit I hit. But with that disabled I am puzzled or >>> > missing > >>> something as to why I cannot fragment packets up to full 1500? What I >>> > am > >>> missing here? Do I need to make MTU adjustments towards the FastE0/1 >>> interface to force fragmentation before the l2tpv3 tunnel? >>> >>> >>> >>> Thanks in advance, >>> >>> >>> >>> Paul >>> >>> _______________________________________________ >>> cisco-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >>> >>> >> >> > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
