1811 ipsec vpn's

Discussion in 'Cisco' started by mmark751969, May 7, 2009.

  1. mmark751969

    mmark751969 Guest

    I have 6 ipsec vpn tunnels on my 1811 that go to other 1800 series
    routers and p500 series pixes. They have been established for some
    time. Periodically, i'd say about twice a week, they will go down for
    about 1 hour at a time. The tunnell will stay up but traffic will not
    be passing through them. After about an hour, traffic will start
    passing through again. There is a monitoring server behind the 1811
    that continually polls devices behind the other 1800's and pixes,
    about every 2 minutes. When the tunnels stop passing traffic it will
    read those devices as down when they really aren't. What would be
    some recommended methods for keeping these tunnels really up. Thanks
     
    mmark751969, May 7, 2009
    #1
    1. Advertising

  2. mmark751969

    flamer Guest

    On May 7, 1:55 pm, mmark751969 <> wrote:
    > I have 6 ipsec vpn tunnels on my 1811 that go to other 1800 series
    > routers and p500 series pixes.  They have been established for some
    > time.  Periodically, i'd say about twice a week, they will go down for
    > about 1 hour at a time.  The tunnell will stay up but traffic will not
    > be passing through them.  After about an hour, traffic will start
    > passing through again.  There is a monitoring server behind the 1811
    > that continually polls devices behind the other 1800's and pixes,
    > about every 2 minutes.  When the tunnels stop passing traffic it will
    > read those devices as down when they really aren't.  What would be
    > some recommended methods for keeping these tunnels really up.  Thanks


    tunnels only stay up when "interesting traffic" is forwarded on them,
    I would suggest you either look at your timeout values or failing that
    generate traffic to flow across them constantly to keep them alive.

    timeout value is something like this:
    crypto map blah
    set security-association idle-time 86400 <--set to 24 hours.

    Flamer.
     
    flamer , May 8, 2009
    #2
    1. Advertising

  3. mmark751969

    bod43 Guest

    On 8 May, 04:59, "flamer " <>
    wrote:
    > On May 7, 1:55 pm, mmark751969 <> wrote:
    >
    > > I have 6 ipsec vpn tunnels on my 1811 that go to other 1800 series
    > > routers and p500 series pixes.  They have been established for some
    > > time.  Periodically, i'd say about twice a week, they will go down for
    > > about 1 hour at a time.  The tunnell will stay up but traffic will not
    > > be passing through them.  After about an hour, traffic will start
    > > passing through again.  There is a monitoring server behind the 1811
    > > that continually polls devices behind the other 1800's and pixes,
    > > about every 2 minutes.  When the tunnels stop passing traffic it will
    > > read those devices as down when they really aren't.  What would be
    > > some recommended methods for keeping these tunnels really up.  Thanks

    >
    > tunnels only stay up when "interesting traffic" is forwarded on them,
    > I would suggest you either look at your timeout values or failing that
    > generate traffic to flow across them constantly to keep them alive.
    >
    > timeout value is something like this:
    > crypto map blah
    > set security-association idle-time 86400  <--set to 24 hours.


    I think the OP already has regular traffic from a monitoring station.

    Here is an idea:-

    I have seen similar cases where for reasons never determined
    the security association (I prefer that term if no actual "tunnel
    interface" is in use to avoid confusion) could only be initiated by
    traffic in one of the directions. I have configured hundreds of cisco
    IPSEC routers and could find no reason for this in a very few cases.
    I think I went as far as kludging up traffic to keep the SA up
    in at least one case. There are several ways to do the latter on the
    router. SAA, NTP. Remember that the source interface has to be
    in the crypto domain. ntp source vlan 1 perhaps.

    Obviously examine the configs carefully to see if the reason for the
    behaviour can be determined and perhaps troubleshoot with deb
    cry ip sa, deb cry isa.

    I have the idea that specific access lists on the crypto
    maps are a good idea.

    eg
    satellite 1
    permit ip 10.1.1.0 0.0.0.255 192.168.2.0 0.0.0.255

    satellite 2
    permit ip 10.1.2.0 0.0.0.255 192.168.2.0 0.0.0.255

    core - lets cover all the satellites with a single ACL
    permit ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.255.255

    was not a good idea and let to intermittent or mysterious problems.

    Better seemed to be:

    satellite 1
    permit ip 10.1.1.0 0.0.0.255 192.168.2.0 0.0.0.255

    satellite 2
    permit ip 10.1.2.0 0.0.0.255 192.168.2.0 0.0.0.255

    core - let's specify all satellites individually
    permit ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.0.255
    permit ip 192.168.2.0 0.0.0.255 10.1.2.0 0.0.0.255

    i.e. make the crypto access list *entries* at the two sides
    match *EXACTLY* and not merely include each other.
    I think the latter does work at least sometimes though:-(
    Never raised a case or worked it out properly.

    Here is a complete sla example. I find it quite confusing.
    It triggers every minute which seems to be a default.

    track 1 rtr 101 reachability
    delay down 20 up 20
    ip sla 101
    icmp-echo 10.1.1.1
    timeout 1000
    ip sla schedule 101 life forever start-time now
     
    bod43, May 8, 2009
    #3
  4. mmark751969

    mmark751969 Guest

    On May 8, 8:39 am, bod43 <> wrote:
    > On 8 May, 04:59, "flamer " <>
    > wrote:
    >
    >
    >
    >
    >
    > > On May 7, 1:55 pm,mmark751969<> wrote:

    >
    > > > I have 6 ipsec vpn tunnels on my 1811 that go to other 1800 series
    > > > routers and p500 series pixes.  They have been established for some
    > > > time.  Periodically, i'd say about twice a week, they will go down for
    > > > about 1 hour at a time.  The tunnell will stay up but traffic will not
    > > > be passing through them.  After about an hour, traffic will start
    > > > passing through again.  There is a monitoring server behind the 1811
    > > > that continually polls devices behind the other 1800's and pixes,
    > > > about every 2 minutes.  When the tunnels stop passing traffic it will
    > > > read those devices as down when they really aren't.  What would be
    > > > some recommended methods for keeping these tunnels really up.  Thanks

    >
    > > tunnels only stay up when "interesting traffic" is forwarded on them,
    > > I would suggest you either look at your timeout values or failing that
    > > generate traffic to flow across them constantly to keep them alive.

    >
    > > timeout value is something like this:
    > > crypto map blah
    > > set security-association idle-time 86400  <--set to 24 hours.

    >
    > I think the OP already has regular traffic from a monitoring station.
    >
    > Here is an idea:-
    >
    > I have seen similar cases where for reasons never determined
    > the security association (I prefer that term if no actual "tunnel
    > interface" is in use to avoid confusion) could only be initiated by
    > traffic in one of the directions. I have configured hundreds of cisco
    > IPSEC routers and could find no reason for this in a very few cases.
    > I think I went as far as kludging up traffic to keep the SA up
    > in at least one case. There are several ways to do the latter on the
    > router. SAA, NTP. Remember that the source interface has to be
    > in the crypto domain. ntp source vlan 1 perhaps.
    >
    > Obviously examine the configs carefully to see if the reason for the
    > behaviour can be determined and perhaps troubleshoot with deb
    > cry ip sa, deb cry isa.
    >
    > I have the idea that specific access lists on the crypto
    > maps are a good idea.
    >
    > eg
    > satellite 1
    > permit ip 10.1.1.0 0.0.0.255 192.168.2.0 0.0.0.255
    >
    > satellite 2
    > permit ip 10.1.2.0 0.0.0.255 192.168.2.0 0.0.0.255
    >
    > core - lets cover all the satellites with a single ACL
    > permit ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.255.255
    >
    > was not a good idea and let to intermittent or mysterious problems.
    >
    > Better seemed to be:
    >
    > satellite 1
    > permit ip 10.1.1.0 0.0.0.255 192.168.2.0 0.0.0.255
    >
    > satellite 2
    > permit ip 10.1.2.0 0.0.0.255 192.168.2.0 0.0.0.255
    >
    > core - let's specify all satellites individually
    > permit ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.0.255
    > permit ip 192.168.2.0 0.0.0.255 10.1.2.0 0.0.0.255
    >
    > i.e. make the crypto access list *entries* at the two sides
    > match *EXACTLY* and not merely include each other.
    > I think the latter does work at least sometimes though:-(
    > Never raised a case or worked it out properly.
    >
    > Here is a complete sla example. I find it quite confusing.
    > It triggers every minute which seems to be a default.
    >
    > track 1 rtr 101 reachability
    >  delay down 20 up 20
    > ip sla 101
    >  icmp-echo 10.1.1.1
    >  timeout 1000
    > ip sla schedule 101 life forever start-time now- Hide quoted text -
    >
    > - Show quoted text -


    What were some of your ideas to generate traffic from the router to
    keep the sa's up. In one case - i have tried generating traffic from
    the remote end servers. I will try this again but i was wondering
    what you did at the router. Thanks
     
    mmark751969, May 13, 2009
    #4
  5. mmark751969

    alexd Guest

    mmark751969 wrote:

    > On May 8, 8:39 am, bod43 <> wrote:


    >> track 1 rtr 101 reachability
    >> delay down 20 up 20
    >> ip sla 101
    >> icmp-echo 10.1.1.1
    >> timeout 1000
    >> ip sla schedule 101 life forever start-time now


    > What were some of your ideas to generate traffic from the router to
    > keep the sa's up.


    The SLA will do that.

    --
    <http://ale.cx/> (AIM:troffasky) ()
    21:06:50 up 7 days, 23:27, 1 user, load average: 0.16, 0.16, 0.11
    A few flakes working together can unleash an avalanche of destruction
     
    alexd, May 14, 2009
    #5
  6. mmark751969

    mmark751969 Guest

    On May 14, 1:07 pm, alexd <> wrote:
    > mmark751969wrote:
    > > On May 8, 8:39 am, bod43 <> wrote:
    > >> track 1 rtr 101 reachability
    > >> delay down 20 up 20
    > >> ip sla 101
    > >> icmp-echo 10.1.1.1
    > >> timeout 1000
    > >> ip sla schedule 101 life forever start-time now

    > > What were some of your ideas to generate traffic from the router to
    > > keep the sa's up.

    >
    > The SLA will do that.
    >
    > --
    >  <http://ale.cx/> (AIM:troffasky) ()
    >  21:06:50 up 7 days, 23:27,  1 user,  load average: 0.16, 0.16, 0.11
    >  A few flakes working together can unleash an avalanche of destruction


    What necessarily is considered to be 'interesting traffic'. I have
    setup an automated ping script on the remote servers to ping back to
    the monitor server every two minutes. This appeared to have helped
    for some of the tunnels but other continue to go down. This sla
    config appears to be generating icmp traffic from the router like i am
    doing from the servers.
     
    mmark751969, May 18, 2009
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. mak007
    Replies:
    0
    Views:
    1,088
    mak007
    Nov 15, 2006
  2. Pappy
    Replies:
    1
    Views:
    2,379
    Pappy
    Jan 30, 2009
  3. Dinobot

    VPN on a CISCO 1811

    Dinobot, Apr 26, 2009, in forum: Cisco
    Replies:
    0
    Views:
    460
    Dinobot
    Apr 26, 2009
  4. Replies:
    0
    Views:
    5,298
  5. Robert Jacobs

    Site-to-site VPN Cisco 1811 - wireless

    Robert Jacobs, Dec 2, 2009, in forum: Cisco
    Replies:
    5
    Views:
    1,506
    Techno_Guy
    Dec 3, 2009
Loading...

Share This Page