From: Joseph Brunner (joe@affirmedsystems.com)
Date: Tue Feb 12 2008 - 05:15:25 ARST
You know;
The more I study the Security IE, the more I want to STOP and DO The Service
Provider IE.
I feel like I have no nucking fidea what is going on in the world anymore...
I read something on ACS and IPS on the path to completing the written,
realize that I don't know something about VPLS, stop for a day and end up
reading something from JUNIPER on configuring VPLS between the M-Series and
the E-Series...
Scott, get ready... you're going to have this happen to you soon...
+^{
Helppppppppppp
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Luan
Nguyen
Sent: Tuesday, February 12, 2008 1:21 AM
To: Joseph Brunner
Cc: Paul Cosgrove; Jian Gu; ccie forum
Subject: Re: Traffic extremely slow in one direction
I never look, but i don't think it will fragment above 1500. Besides, the
ethernet LAN is still 1500 MTU. Setting higher MTU on the tunnel and the
serial just make the packets flow by without any problem after adding on all
the extra header and encryption...not necessarily mean packet size = 4470.
People could get a private frame link and we'll give them GET-VPN if they
want encryption with it. But some want internet link, 'cuz it's cheaper i
think, but they don't want their remote sites to do split tunnel - force
everything to the central site, so they get DMVPN with IPSEC over internet
link :)
-lmn
On Feb 12, 2008 1:09 AM, Joseph Brunner <joe@affirmedsystems.com> wrote:
> Does the crypto accelerator have the ability to encrypt and decrypt a
> packet with an mtu of 4470? Or will it fragment anything above 1500?
>
>
>
> And why are you guys running crypto in the first place on a non-internet
> link? IMHQ?
>
>
>
> >So we have to clear the df bit.
>
>
>
> Perhaps you don't have this luxury if you're a SP, but I would have forced
> the sys admins to change their boxes MTU before I allowed any fragments on
> my tunnel. LOL
>
>
>
> -Joe
>
>
> ------------------------------
>
> *From:* Luan Nguyen [mailto:luan.m.nguyen@gmail.com]
> *Sent:* Tuesday, February 12, 2008 1:03 AM
> *To:* Joseph Brunner
> *Cc:* Paul Cosgrove; Jian Gu; ccie forum
>
> *Subject:* Re: Traffic extremely slow in one direction
>
>
>
> 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<http://www.cisco.com/web/partners/downloads/765/tools/quick
reference/vpn_performance_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
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2008 - 16:54:48 ARST