6 Replies Latest reply: Aug 20, 2010 5:41 AM by toor RSS

    Ipsec bandwith problem

    nature

      Hello everyone

      I hope U are doing  well

      I have got one problem with ipsec isakamp

      so I have 100 mb  speed with my branch office its  work good without ipsec I mean when I  remove crypto map  from interface it work as usual but with crypto map bandwith is very low  about  5mb between branch office   and  Core

      what can be the  problem is there any idea?

       

      here is  my config file:

         Branch Office: cisco 2811

      crypto isakmp policy 1
      hash md5
      authentication pre-share
      !
      crypto isakmp policy 2
      hash md5
      authentication pre-share
      crypto isakmp key 6 (preshared) address xxx.xxx.xxx.xxx
      crypto isakmp key 6 (preshared) address xxx.xxx.xxx.xxx
      !
      crypto isakmp peer address xxx.xxx.xxx.xxx
      !
      crypto isakmp peer address xxx.xxx.xxx.xxx
      !
      !
      crypto ipsec transform-set cardipsec esp-aes esp-md5-hmac
      !
      crypto map (name) 2 ipsec-isakmp
      set peer xxx.xxx.xxx.xxx
      set transform-set cardipsec
      set pfs group1
      match address 102
      !
      crypto map (name) 1 ipsec-isakmp
      set peer xxx.xxx.xxx.xxx
      set transform-set cardipsec
      set pfs group1
      match address 101
      !
      !
      !
      interface FastEthernet0/0
      no ip address
      duplex auto
      speed auto
      !
      interface FastEthernet0/0.1
      description Wan to local$ETH-LAN$

      encapsulation dot1Q 59
      ip address xxx.xxxx.xxxx.xxxx  255.255.255.0

      no snmp trap link-status

      crypto map (name)
      !
      interface FastEthernet0/0.2
      description Millic
      encapsulation dot1Q 127
      ip address xxx.xxx.xxx.xxx 255.255.255.128

      no snmp trap link-status
      crypto map (name)
      !
      interface FastEthernet0/1
      description local
      ip address xxx.xxx.xxx.xxx 255.255.255.252 secondary
      ip address xxx.xxx.xxx.xxx 255.255.255.252 secondary
      ip address xxx.xxx.xxx.xxx.xxx 255.255.255.0
      ip access-group 2 in

      duplex auto
      speed aut

       

       

       

       

       

      Core side: 3com router

       

      ike peer (peer name)
      pre-shared-key (preshared)
      remote-address xxx.xxx.xxx.xxx  xxx.xxx.xxx.xxxx
      local-address xxx.xxx.xxx.xxx

       

      ipsec card-proposal cardipsec
      use encrypt-card 5/0
      esp encryption-algorithm aes 128

       

      ipsec policy(name) 1 isakmp
      security acl 3101
      pfs dh-group1
      ike-peer (name)
      proposal cardipsec

        • 1. Re: Ipsec bandwith problem
          Conwyn

          Hi Nature

           

          Does the 3Com support ESP-NULL. It might be worth trying it to see if it an encryption engine processing problem.

           

          Regards Conwyn

          • 2. Re: Ipsec bandwith problem
            nature

            Thanks

            3com encrypt card support up to 188 mb and  cisco 2811 support 55mb

            I think  problem is crypto card that  doesn;t support,  what do u think? how  can I  check  it?

            • 3. Re: Ipsec bandwith problem
              toor

              This could also be fragmentation problem. Do your end-user devices support PMD?

               

              Regards,

               

              Toor

              • 4. Re: Ipsec bandwith problem
                nature

                Sorry I don't exactly  understand  what did U  mean

                Can U explain

                Thanks

                • 5. Re: Ipsec bandwith problem
                  Conwyn

                  Hi Nature

                   

                  PMTUD (Path MTU discovery) adjusts the maximum IP size so it does not fragment

                   

                  Regards Conwyn

                   

                  [http://www.cisco.com/en/US/docs/security/vpn_modules/misc/Archive_-6342/6342prep.html ]

                  Fragmentation

                  Avoid fragmentation at all costs. Packet reassembly is resource intensive from a CPU and memory allocation perspective, and decreases network performance. Allowing fragmented packets into your network also creates security concerns. Fragmented IPSec packets require reassembly before the packets can undergo integrity validation and decryption.

                  Fragmentation can typically be avoided, as it usually occurs when an encapsulated packet, sent over a tunnel, is too large to fit on the smallest link on the tunnel path. As long as filtering does not block the Internet Control Message Protocol (ICMP) messages, path maximum transmission unit discovery (PMTUD) will determine the maximum MTU that a host can use to send a packet through the tunnel without causing fragmentation.

                  To allow PMTUD in your network, do not filter ICMP message Type 3, Code 4. If ICMP filtering occurs and is out of your administrative control, you will have to either manually set the MTU lower on the VPN termination device and allow PMTUD locally, or clear the Don't Fragment (DF) bit and force fragmentation. In this scenario, packets generated by hosts that do not support PMTUD, and have not set the DF bit in the IP header, will undergo fragmentation before IPSec encapsulation. Packets generated by hosts that do support PMTUD will use it locally to match the statically configured MTU on the tunnel. If you manually set the MTU on the tunnel, you must set it low enough to allow packets to pass through the smallest link on the path. Otherwise, the packets that are too large to fit will be dropped, and if ICMP filtering is in place, no feedback will be provided.

                  Remember that multiple layers of encapsulation will add layers of overhead to the packet. For example, GRE and ESP tunneling protocols are used together frequently. In this scenario, GRE adds 24 bytes of overhead to the packet before it undergoes encapsulation again by ESP. ESP, when using 3DES and SHA, then adds 56 bytes of additional overhead. Use of ESP and GRE to support PMTUD reduces the likelihood of fragmentation.

                  Depending on the VPN termination device, the manner in which you should set the MTU on the tunnel varies. Options include changing the MTU through the tunnel interface (routers), the TCP maximum segment size (firewalls), policy routing (routers), clear/set/copy DF bit (routers), OS application level (VPN clients), and physical/logical interfaces (any VPN device).

                  • 6. Re: Ipsec bandwith problem
                    toor

                    Hi Conwyn, Nature,

                     

                    Yes, that is what I've had in mind. Here is one more article regarding packet fragmentation and IPSec: http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/vspa/configuration/guide/ivmvpnb.html

                     

                    Regards,

                     

                    Toor