From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Tue Feb 12 2008 - 09:11:34 ARST
Hi Luan,
2811 was mentioned as an example, Jian Gu did not mention the model of
2800 that he uses. As with any other range, if you pay more you can get
more performance.
I'm aware that clearing the DF bit is required for some types of
traffic, e.g. when performing multiple layers of encryption, but
personally have not found that clearing the bit is a common requirement.
I would be interested to know the traffic types you have for which
setting the IP MTU and TCP MSS is not enough, and clearing the df bit is
still necessary?
When a tunnel is involved, fragmentation of packets from your site is
most likely to occur at your tunnel router, rather than someone elses
router at the other end of a tunnel. If your own edge routers have a
sufficiently low IP MTU and MSS settings then PMTUD should work fine for
devices on your side. If the other sites router blocks all ICMP, then
that will affect PMTUD for devices on their side of the tunnel.
If there is a problem link (with a low MTU) entirely within someone
elses network, and that site blocks all ICMP, then in general I think
people are better off informing the other site and asking them to allow
the correct icmp packets. If they won't do it, drop the MTU on your end
of your tunnel to the size of the bottleneck.
Clearing the bit creates another reason for PMTUD to be broken and
requires modification of all IP packets, i.e. process switching of all
traffic. Then you may need a bigger router.
Paul.
Luan Nguyen wrote:
> Well, in a perfect world, you don't want fragments. But people block icmp
> all the time and break path mtu discovery. So we have to clear the df bit.
> You are lucky not encountering this yet.
> For clients that don't require internet and have serial links, we actually
> will try to set the ip mtu of the tunnel, and the serial interface to 4470
> so you don't need to fragment/resend..etc anything at all :)
>
> We don't even look at 2801 :P. For a little bit more money, you should try
> the 2821. It could do somewhere around 40Mbps. You meant the routing
> protocol neighbors? DMVPN only has one tunnel :P
>
> -lmn
>
> On Feb 12, 2008 12:35 AM, Joseph Brunner <joe@affirmedsystems.com> wrote:
>
>> Why would you clear the df bit?
>>
>> You DON'T WANT FRAGMENTS!!!! perhaps you should put the ip mtu/tcp mss
>> commands on the LAN FACING interface...
>>
>> IMHO the 2801 is the WORST of the bunch... I tried using it as a large
>> scale
>> dmvpn hub... LOL the 2811 actually held up quite nicely, all the way to
>> 20Mbps+ what killed it was the sheer number of dmvpn tunnels...
>>
>> -Joe
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>> Luan
>> Nguyen
>> Sent: Monday, February 11, 2008 9:20 PM
>> To: Paul Cosgrove
>> Cc: Jian Gu; ccie forum
>> Subject: Re: Traffic extremely slow in one direction
>>
>> For me, setting ip mtu, and ip tcp adjust-mss are never enough. I have to
>> clear the df bit as well.
>> access-list 111 permit tcp any any
>> route-map clear-df-bit permit 10
>> match ip address 111
>> set ip df 0
>> int WAN
>> ip policy route-map clear-df-bit
>>
>> On a side note, the 2811 is the worst performer of the 2800 series family
>> of
>> ISR regarding GRE/IPSEC. We had to drop it even with the AIM-VPN/SSL-2
>> card. And don't take performance number for its face value...it's
>> unidirectional and best case scenario. You should take that number divide
>> by 4 to get real world value :)
>>
>> -lmn
>>
>> On Feb 11, 2008 3:30 PM, Paul Cosgrove <paul.cosgrove@heanet.ie> wrote:
>>
>>> Jian Gu wrote:
>>>> hi, all,
>>>>
>>>> I have a real world problem that I am scratching my head to find the
>>> root
>>>> cause. We have a local data center at site A and a remote backup
>> server
>>> at
>>>> site B, site A and site B has its own service provider, the connection
>>>> bandwidth is well above 50M in either site, traffic will traverse a
>>>> GRE/IPsec tunnel which is configured between two 2800 routers, both
>>> routers
>>>> have hardware accelerated IPSec encryption/decrytion module installed.
>>>>
>>>> It is interesting that traffic from site A to site B is extremely
>> slow,
>>>> performance is only around 10s packets/second, but FTP transferring
>> data
>>>> from site B to site A is reasonably fast, which is around 8Mb/sec. I
>> am
>>>> pretty sure service provider of site A is not rate limiting incoming
>>> traffic
>>>> (even it does, noway they will rate limit to 10s packets/sec). What
>>> could be
>>>> the root cause of such poor performance, any server experts here can
>>> give me
>>>> a clue?
>>>>
>>>> Thanks,
>>>> Jian
>>>>
>>>>
>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>> Hi Jian Gu,
>>>
>>> Perhaps you do not notice delay or drops with FTP transfer because you
>>> do not see the individual packets being dropped/retransmitted? With
>>> pings this will be more readily apparent. How are you testing the link?
>>> Which direction does most of the traffic flow in?
>>>
>>> The number of packets per second is very important for encryption, more
>>> so than the throughput in terms of Kbps. Sending lots of small packets
>>> will normally have more of an impact than sending a few large ones (such
>>> as FTP).
>>>
>>> Other than pps, also watch for fragmentation. Check what GRE IP MTU you
>>> are using, as unless your GRE IP MTU allows for the encryption header
>>> being added later your GRE packets will be fragmented.
>>>
>>> GRE adds 24 bytes, IPSEC is variable because of the padding but (I
>>> think) is about 80 bytes.
>>>
>>> Also keep in mind that the router will also have to perform
>>> fragmentation if the incoming IP packet is larger than the GRE IP MTU,
>>> and setting the TCP MSS lower using "ip tcp adjust-mss" can help with
>>> that (but only for TCP). Path MTU discovery on end hosts/servers is
>>> also a good way to reduce fragmentation, and thereby reduce load on the
>>> device.
>>>
>>> According to the folowing link the 2811 is capable of 55 Mbps with AES
>>> or 3DES, but you often have to quite cautious when shown encryption
>>> stats without pps or packet size.
>>>
>>>
>>>
>> http://www.cisco.com/web/partners/downloads/765/tools/quickreference/vpn_per
>> formance_eng.pdf
>>>
>>> Paul.
>>> --
>>> Paul Cosgrove
>>> HEAnet Limited, Ireland's Education and Research Network
>>> 1st Floor, 5 George's Dock, IFSC, Dublin 1
>>> Registered in Ireland, no 275301
>>> tel: +353-1-660 9040 fax: +353-1-660 3666
>>> web: http://www.heanet.ie/
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Paul Cosgrove HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2008 - 16:54:48 ARST