NAT to two ISPs on one router

Discussion in 'Cisco' started by Vincent C Jones, Jul 21, 2004.

  1. Trying to set up a fully redundant ISP connection using low cost DSL. No
    problem detecting link down with SAA (ping based routing), but a real
    problem getting NAT to bahave.

    When the active link goes down, the default route switches
    automagically, but it is only useable for new connections until a "clear
    ip nat trans *" is executed. I know how to reduce the timeout on
    translations, but that is not a generic solution because I cannot
    guarantee a time gap between attempts greater than typical (yet alone
    worst case) keepalive intervals.

    The problem appears to be that once a translation is assigned, the ip
    nat source route statements are ignored. That is, the "ip nat source
    route" statements are only checked if there is not already a translation
    assigned to the address. As a result, the classic trick of assigning the
    NAT based on the outbound interface only works for the initial
    assignment and unless the translations are manually cleared, will not
    switch the NAT to match the remaining interface.

    Short of running a daemon on a local PC, is there any way to
    automatically force the NAT translations to be reassigned before they
    have timed out?

    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
     
    Vincent C Jones, Jul 21, 2004
    #1
    1. Advertising

  2. Vincent C Jones

    sriggs Guest

    Pay the extra money and get a small block of IP addresses from one of
    the ISPs and NAT to that address

    (Vincent C Jones) wrote in message news:<cdlrkg$7vk$>...
    > Trying to set up a fully redundant ISP connection using low cost DSL. No
    > problem detecting link down with SAA (ping based routing), but a real
    > problem getting NAT to bahave.
    >
    > When the active link goes down, the default route switches
    > automagically, but it is only useable for new connections until a "clear
    > ip nat trans *" is executed. I know how to reduce the timeout on
    > translations, but that is not a generic solution because I cannot
    > guarantee a time gap between attempts greater than typical (yet alone
    > worst case) keepalive intervals.
    >
    > The problem appears to be that once a translation is assigned, the ip
    > nat source route statements are ignored. That is, the "ip nat source
    > route" statements are only checked if there is not already a translation
    > assigned to the address. As a result, the classic trick of assigning the
    > NAT based on the outbound interface only works for the initial
    > assignment and unless the translations are manually cleared, will not
    > switch the NAT to match the remaining interface.
    >
    > Short of running a daemon on a local PC, is there any way to
    > automatically force the NAT translations to be reassigned before they
    > have timed out?
     
    sriggs, Jul 22, 2004
    #2
    1. Advertising

  3. There are a wide range of solutions if I am willing to change
    the parameters. Buying a block of fixed IP addresses is one way to
    eliminate the need for a second NAT definition, as is adding a NAT
    firewall on one (or both) of the DSL lines. Another workaround is
    to add a monitoring box onto the local LAN to track the changes and
    clear the NAT translation table. A much cheaper work around is to
    forget Cisco and use a Symantec 200R, which does the job without
    any kludges or static IPs (but I don't want to start a round of
    "Here's what's wrong with the Nexland/Symantec boxen" flames,
    suffice it to say you get what you pay for).

    Meanwhile, the original question remains unanswered, which is
    "Can this common SOHO requirement be met with a single Cisco box?"

    Vincent C Jones

    In article <>,
    sriggs <> wrote:
    >Pay the extra money and get a small block of IP addresses from one of
    >the ISPs and NAT to that address
    >
    > (Vincent C Jones) wrote in message news:<cdlrkg$7vk$>...
    >> Trying to set up a fully redundant ISP connection using low cost DSL. No
    >> problem detecting link down with SAA (ping based routing), but a real
    >> problem getting NAT to bahave.
    >>
    >> When the active link goes down, the default route switches
    >> automagically, but it is only useable for new connections until a "clear
    >> ip nat trans *" is executed. I know how to reduce the timeout on
    >> translations, but that is not a generic solution because I cannot
    >> guarantee a time gap between attempts greater than typical (yet alone
    >> worst case) keepalive intervals.
    >>
    >> The problem appears to be that once a translation is assigned, the ip
    >> nat source route statements are ignored. That is, the "ip nat source
    >> route" statements are only checked if there is not already a translation
    >> assigned to the address. As a result, the classic trick of assigning the
    >> NAT based on the outbound interface only works for the initial
    >> assignment and unless the translations are manually cleared, will not
    >> switch the NAT to match the remaining interface.
    >>
    >> Short of running a daemon on a local PC, is there any way to
    >> automatically force the NAT translations to be reassigned before they
    >> have timed out?



    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
     
    Vincent C Jones, Jul 22, 2004
    #3
  4. Vincent C Jones

    Ivan Ostres Guest

    In article <cdogfh$5pp$>,
    says...
    > There are a wide range of solutions if I am willing to change
    > the parameters. Buying a block of fixed IP addresses is one way to
    > eliminate the need for a second NAT definition, as is adding a NAT
    > firewall on one (or both) of the DSL lines. Another workaround is
    > to add a monitoring box onto the local LAN to track the changes and
    > clear the NAT translation table. A much cheaper work around is to
    > forget Cisco and use a Symantec 200R, which does the job without
    > any kludges or static IPs (but I don't want to start a round of
    > "Here's what's wrong with the Nexland/Symantec boxen" flames,
    > suffice it to say you get what you pay for).
    >
    > Meanwhile, the original question remains unanswered, which is
    > "Can this common SOHO requirement be met with a single Cisco box?"
    >
    > Vincent C Jones
    >


    AFAIK, the answer is no. I've fixed thing like that using one of
    possible solutions that you mentioned above (using a PC that's running a
    script that does the job).

    Even bigger problem I had was connecting site-to-site VPN when there are
    dynamic addresses on both sites (DSL) using dynDNS service. I've even
    ask at TAC and they said that they can't answer that :). So, I've took
    two boxes from Bintec and for now, things look fine.... Seems that Cisco
    just sucks for such SOHO jobs.

    --
    -Ivan.

    *** Use Rot13 to see my eMail address ***
     
    Ivan Ostres, Jul 22, 2004
    #4
  5. Vincent C Jones

    Hansang Bae Guest

    > > (Vincent C Jones) wrote in message news:<cdlrkg$7vk$>...
    > >> Trying to set up a fully redundant ISP connection using low cost DSL. No
    > >> problem detecting link down with SAA (ping based routing), but a real
    > >> problem getting NAT to bahave.
    > >>
    > >> When the active link goes down, the default route switches
    > >> automagically, but it is only useable for new connections until a "clear
    > >> ip nat trans *" is executed. I know how to reduce the timeout on
    > >> translations, but that is not a generic solution because I cannot
    > >> guarantee a time gap between attempts greater than typical (yet alone
    > >> worst case) keepalive intervals.
    > >>
    > >> The problem appears to be that once a translation is assigned, the ip
    > >> nat source route statements are ignored. That is, the "ip nat source
    > >> route" statements are only checked if there is not already a translation
    > >> assigned to the address. As a result, the classic trick of assigning the
    > >> NAT based on the outbound interface only works for the initial
    > >> assignment and unless the translations are manually cleared, will not
    > >> switch the NAT to match the remaining interface.
    > >>
    > >> Short of running a daemon on a local PC, is there any way to
    > >> automatically force the NAT translations to be reassigned before they
    > >> have timed out?


    One thing that might do the trick (since you're already using SAA, ping
    based routing) is to enable HSRP with interface tracking. On dual box
    setups, the NAT table is supposed to be somewhat stateful.

    I know there won't be another router to pick up the HSRP status, but
    perhaps the act of 'failing' over will refresh the NAT tables?


    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Jul 23, 2004
    #5
  6. Vincent C Jones

    Jon Lawrence Guest

    Vincent C Jones wrote:
    > There are a wide range of solutions if I am willing to change
    > the parameters. Buying a block of fixed IP addresses is one way to
    > eliminate the need for a second NAT definition, as is adding a NAT
    > firewall on one (or both) of the DSL lines. Another workaround is
    > to add a monitoring box onto the local LAN to track the changes and
    > clear the NAT translation table. A much cheaper work around is to
    > forget Cisco and use a Symantec 200R, which does the job without
    > any kludges or static IPs (but I don't want to start a round of
    > "Here's what's wrong with the Nexland/Symantec boxen" flames,
    > suffice it to say you get what you pay for).
    >
    > Meanwhile, the original question remains unanswered, which is
    > "Can this common SOHO requirement be met with a single Cisco box?"
    >
    > Vincent C Jones
    >
    > In article <>,
    > sriggs <> wrote:
    >
    >>Pay the extra money and get a small block of IP addresses from one of
    >>the ISPs and NAT to that address
    >>
    >> (Vincent C Jones) wrote in message news:<cdlrkg$7vk$>...
    >>
    >>>Trying to set up a fully redundant ISP connection using low cost DSL. No
    >>>problem detecting link down with SAA (ping based routing), but a real
    >>>problem getting NAT to bahave.
    >>>
    >>>When the active link goes down, the default route switches
    >>>automagically, but it is only useable for new connections until a "clear
    >>>ip nat trans *" is executed. I know how to reduce the timeout on
    >>>translations, but that is not a generic solution because I cannot
    >>>guarantee a time gap between attempts greater than typical (yet alone
    >>>worst case) keepalive intervals.
    >>>
    >>>The problem appears to be that once a translation is assigned, the ip
    >>>nat source route statements are ignored. That is, the "ip nat source
    >>>route" statements are only checked if there is not already a translation
    >>>assigned to the address. As a result, the classic trick of assigning the
    >>>NAT based on the outbound interface only works for the initial
    >>>assignment and unless the translations are manually cleared, will not
    >>>switch the NAT to match the remaining interface.
    >>>
    >>>Short of running a daemon on a local PC, is there any way to
    >>>automatically force the NAT translations to be reassigned before they
    >>>have timed out?

    >
    >
    >

    I have a very similar problem. The nat doesn't drop back to the
    redundant connection (which is to a different ISP)
    sriggs - how would a block of ip addresses solve anything. We're talking
    about redundant connections to seperate ISPs, the block of IP's would
    only be routable over one of the ISP's.

    When I initially tested this in the lab (using a 1721 with 1enet & a
    WIC-1T) everything worked perfectly - ie if the 1enet was the primary
    connection, and that was diconnected then the nat correctly worked
    across the wic-1t - with no problems.
    Once I tried it in the field using a DSL connection (wic-1adsl) as the
    primary and the 1enet as the backup, the nat wouldn't drop back to the
    1enet if the dialer1 interface was down even though the routing did.

    Is this something to do with the adsl ?

    Surely, if a connection drops there must be a way of clearing the nat
    tanslations.

    TIA
    Jon
    --
    remove goaway for email
     
    Jon Lawrence, Jul 23, 2004
    #6
  7. Jon Lawrence <> wrote:
    >Vincent C Jones wrote:
    >> There are a wide range of solutions if I am willing to change
    >> the parameters. Buying a block of fixed IP addresses is one way to
    >> eliminate the need for a second NAT definition, as is adding a NAT
    >> firewall on one (or both) of the DSL lines. Another workaround is
    >>

    >I have a very similar problem. The nat doesn't drop back to the
    >redundant connection (which is to a different ISP)
    >sriggs - how would a block of ip addresses solve anything. We're talking
    >about redundant connections to seperate ISPs, the block of IP's would
    >only be routable over one of the ISP's.


    If you have a block of IPs, you use those for the inside addresses
    and you configure that ISP's interface as inside rather than of
    outside, so there is no opportunity for NAT to get confused (except
    for some older IOS releases which would NAT before checking if the
    packet was being routed to an outside interface.)

    >When I initially tested this in the lab (using a 1721 with 1enet & a
    >WIC-1T) everything worked perfectly - ie if the 1enet was the primary
    >connection, and that was diconnected then the nat correctly worked
    >across the wic-1t - with no problems.


    A good sign. It implies that the NAT is at least smart enough to cancel
    NATs to an interface which is down (which, unfortunately, never happens
    on an Ethernet link to DSL or Cable, and can't be depended on even with
    a real DSL link).

    >Once I tried it in the field using a DSL connection (wic-1adsl) as the
    >primary and the 1enet as the backup, the nat wouldn't drop back to the
    >1enet if the dialer1 interface was down even though the routing did.
    >
    >Is this something to do with the adsl ?
    >
    >Surely, if a connection drops there must be a way of clearing the nat
    >tanslations.


    This appears to be the case, the problem is that SAA only drops the
    static route and the interface is still considered up. This is tricky,
    because the interface needs to stay up so SAA can detect when it starts
    working again. What is needed is for NAT to track SAA.

    >TIA
    >Jon


    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
     
    Vincent C Jones, Jul 24, 2004
    #7
  8. In article <>,
    Hansang Bae <> wrote:
    >> > (Vincent C Jones) wrote in message news:<cdlrkg$7vk$>...
    >> >> Trying to set up a fully redundant ISP connection using low cost DSL. No
    >> >> problem detecting link down with SAA (ping based routing), but a real
    >> >> problem getting NAT to bahave.
    >> >>
    >> >> When the active link goes down, the default route switches
    >> >> automagically, but it is only useable for new connections until a "clear
    >> >> ip nat trans *" is executed. I know how to reduce the timeout on
    >> >> translations, but that is not a generic solution because I cannot
    >> >> guarantee a time gap between attempts greater than typical (yet alone
    >> >> worst case) keepalive intervals.
    >> >>
    >> >> The problem appears to be that once a translation is assigned, the ip
    >> >> nat source route statements are ignored. That is, the "ip nat source
    >> >> route" statements are only checked if there is not already a translation
    >> >> assigned to the address. As a result, the classic trick of assigning the
    >> >> NAT based on the outbound interface only works for the initial
    >> >> assignment and unless the translations are manually cleared, will not
    >> >> switch the NAT to match the remaining interface.
    >> >>
    >> >> Short of running a daemon on a local PC, is there any way to
    >> >> automatically force the NAT translations to be reassigned before they
    >> >> have timed out?

    >
    >One thing that might do the trick (since you're already using SAA, ping
    >based routing) is to enable HSRP with interface tracking. On dual box
    >setups, the NAT table is supposed to be somewhat stateful.
    >
    >I know there won't be another router to pick up the HSRP status, but
    >perhaps the act of 'failing' over will refresh the NAT tables?
    >
    >hsb


    I got excited when I first read this, what a great idea. Then I
    realized that it wasn't going to work because SAA does not take
    down the interface, only the static route(s) using the interface,
    so HSRP interface tracking would never see it.

    Maybe in 12.4T Cisco will get it right...

    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
     
    Vincent C Jones, Jul 24, 2004
    #8
  9. On Wed, 21 Jul 2004 13:44:06 +0000, Vincent C Jones wrote:

    > When the active link goes down, the default route switches automagically,
    > but it is only useable for new connections until a "clear ip nat trans *"
    > is executed. I know how to reduce the timeout on translations, but that is
    > not a generic solution because I cannot guarantee a time gap between
    > attempts greater than typical (yet alone worst case) keepalive intervals.
    >
    > The problem appears to be that once a translation is assigned, the ip nat
    > source route statements are ignored. That is, the "ip nat source route"
    > statements are only checked if there is not already a translation assigned
    > to the address. As a result, the classic trick of assigning the NAT based
    > on the outbound interface only works for the initial assignment and unless
    > the translations are manually cleared, will not switch the NAT to match
    > the remaining interface.


    AIUI NAT will alway look in the translation table first and use a matching
    translation if it finds it. Route maps and ACLS only get checked if there
    is no existing translation and we are deciding whether and what sort to
    create.

    Are all your translations extended? If so, then the connections using
    ISP1 i/f as the IG address will timeout, and the clients inside will
    create new connections with different ephemeral ports and ISP2 i/f address as
    the IG address. That's assuming we're talking about dynamic translations.

    If we're talking static translations for servers, there does appear to
    be a problem with the route maps for static translation feature in late
    12.3 at least. It ignores the route map, and hosts that should use the
    static translation end up using a dynamic pool instead. It's especially
    noticeable with active mode ftp and the server on the inside. The ftp-data
    connections end up coming from a different address than the one the client
    originally connected to.

    --
    Rgds,
    Martin
     
    Martin Gallagher, Jul 24, 2004
    #9
  10. Vincent C Jones

    Jon Lawrence Guest

    Vincent C Jones wrote:
    > Jon Lawrence <> wrote:
    >>
    >>Is this something to do with the adsl ?
    >>
    >>Surely, if a connection drops there must be a way of clearing the nat
    >>tanslations.

    >
    >
    > This appears to be the case, the problem is that SAA only drops the
    > static route and the interface is still considered up. This is tricky,
    > because the interface needs to stay up so SAA can detect when it starts
    > working again. What is needed is for NAT to track SAA.
    >
    >

    OK, I opened a ticket with the TAC and it seems that they've come through.
    If you're using serial interfaces, then the nat will change correctly -
    apparently with other interfaces (eg ethernet or dsl) it won't.
    TAC advised I use something called 'PBR with tracking options' this is
    only supported under 'T' train.
    See
    http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d1e95.html
    for more details.

    Jon

    --
    remove goaway for email
     
    Jon Lawrence, Jul 25, 2004
    #10
  11. In article <>,
    Martin Gallagher <> wrote:
    >On Wed, 21 Jul 2004 13:44:06 +0000, Vincent C Jones wrote:
    >
    >> When the active link goes down, the default route switches automagically,
    >> but it is only useable for new connections until a "clear ip nat trans *"
    >> is executed. I know how to reduce the timeout on translations, but that is
    >> not a generic solution because I cannot guarantee a time gap between
    >> attempts greater than typical (yet alone worst case) keepalive intervals.
    >>
    >> The problem appears to be that once a translation is assigned, the ip nat
    >> source route statements are ignored. That is, the "ip nat source route"
    >> statements are only checked if there is not already a translation assigned
    >> to the address. As a result, the classic trick of assigning the NAT based
    >> on the outbound interface only works for the initial assignment and unless
    >> the translations are manually cleared, will not switch the NAT to match
    >> the remaining interface.

    >
    > AIUI NAT will alway look in the translation table first and use a matching
    >translation if it finds it. Route maps and ACLS only get checked if there
    >is no existing translation and we are deciding whether and what sort to
    >create.


    Yep, that's the way it appears to behave, and hence why there is a
    problem. What is needed is the ability for NAT translation table entries
    to be tied to tracked objects, so they can be removed immediately when
    the tracked object fails.

    > Are all your translations extended? If so, then the connections using
    >ISP1 i/f as the IG address will timeout, and the clients inside will
    >create new connections with different ephemeral ports and ISP2 i/f address as
    >the IG address. That's assuming we're talking about dynamic translations.


    Yes, they are dynamic translations. The problem is that the timeout for
    useful traffic can be too long to be useful (consider the problem of a
    TCP connection using keepalives).

    > If we're talking static translations for servers, there does appear to
    >be a problem with the route maps for static translation feature in late
    >12.3 at least. It ignores the route map, and hosts that should use the
    >static translation end up using a dynamic pool instead. It's especially
    >noticeable with active mode ftp and the server on the inside. The ftp-data
    >connections end up coming from a different address than the one the client
    >originally connected to.


    This is, I believe, a separate issue and unrelated to the problem I'm
    having.

    >Martin


    Thanks for responding!
    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
     
    Vincent C Jones, Jul 26, 2004
    #11
  12. In article <>,
    Jon Lawrence <> wrote:
    >Vincent C Jones wrote:
    >> Jon Lawrence <> wrote:
    >>>
    >>>Is this something to do with the adsl ?
    >>>
    >>>Surely, if a connection drops there must be a way of clearing the nat
    >>>tanslations.

    >>
    >>
    >> This appears to be the case, the problem is that SAA only drops the
    >> static route and the interface is still considered up. This is tricky,
    >> because the interface needs to stay up so SAA can detect when it starts
    >> working again. What is needed is for NAT to track SAA.
    >>
    >>

    >OK, I opened a ticket with the TAC and it seems that they've come through.
    >If you're using serial interfaces, then the nat will change correctly -
    >apparently with other interfaces (eg ethernet or dsl) it won't.
    >TAC advised I use something called 'PBR with tracking options' this is
    >only supported under 'T' train.
    >See
    >http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d1e95.html
    >for more details.
    >
    >Jon


    Maybe I'm missing something, but as near as I can tell, "the TAC"
    just doesn't understand the problem.

    I tried it out in the lab this morning (1760, IOS 12.3(8)T1) and
    as near as I can tell policy based routing with tracking does not
    exhibit the problematic behavior simply because there is no way
    to define conditional NAT assignments when using it! NAT using
    a route-map matching next interface uses the "next interface"
    in the routing table, not the "next interface" as modified by a
    policy route. In order to get the NAT to match the actual outbound
    interface, I had to use "static routes with tracking."

    The config I tried follows:

    Router_7#sho ver
    Cisco IOS Software, C1700 Software (C1700-K9O3SY7-M), Version 12.3(8)T1,
    RELEASE SOFTWARE (fc3)
    . . .
    Cisco 1760 (MPC860P) processor (revision 0x500) with 60076K/5460K bytes
    of memory.
    Processor board ID FOC08091V2T (923892838), with hardware revision 0000
    MPC860P processor: part number 5, mask 2
    2 Ethernet interfaces
    1 FastEthernet interface
    32K bytes of NVRAM.
    32768K bytes of processor board System flash (Read/Write)

    Configuration register is 0x2102

    Router_7#sho run
    Current configuration : 2929 bytes
    !
    ! Last configuration change at 10:13:37 edt Mon Jul 26 2004
    !
    version 12.3
    service timestamps debug datetime msec localtime
    service timestamps log datetime msec localtime
    no service password-encryption
    service udp-small-servers
    service tcp-small-servers
    !
    hostname Router_7
    !
    boot-start-marker
    boot system tftp TestIOS.7_X 192.168.100.127
    boot system tftp TestIOS.1700 192.168.100.127
    boot-end-marker
    !
    logging buffered 65535 debugging
    no logging console
    enable password cisco
    !
    clock timezone est -5
    clock summer-time edt recurring
    mmi polling-interval 60
    no mmi auto-configure
    no mmi pvc
    mmi snmp-timeout 180
    no aaa new-model
    ip subnet-zero
    !
    !
    !
    !
    no ip domain lookup
    ip cef
    ip ips po max-events 100
    no ftp-server write-enable
    !
    !
    !
    !
    !
    track 123 rtr 1 reachability
    !
    track 124 rtr 2 reachability
    !
    !
    interface Ethernet0/0
    description "Primary" ISP
    ip address 192.168.201.17 255.255.255.0
    ip nat outside
    ip virtual-reassembly
    half-duplex
    !
    interface FastEthernet0/0
    description User LAN
    ip address 192.168.100.17 255.255.255.0
    ip nat inside
    ip virtual-reassembly
    ip policy route-map alpha
    speed auto
    half-duplex
    !
    interface Ethernet1/0
    description "Alternate" ISP
    ip address 192.168.202.17 255.255.255.0
    ip nat outside
    ip virtual-reassembly
    half-duplex
    !
    ip local policy route-map alpha
    ip classless
    ip route 0.0.0.0 0.0.0.0 192.168.201.16 100 track 123
    ip route 0.0.0.0 0.0.0.0 192.168.202.16 100 track 124
    ip route 0.0.0.0 0.0.0.0 Null0 250
    no ip http server
    no ip http secure-server
    ip nat inside source route-map NAT_E0 interface Ethernet0/0 overload
    ip nat inside source route-map NAT_E1 interface Ethernet1/0 overload
    !
    !
    !
    logging trap debugging
    access-list 101 permit ip any 192.168.201.0 0.0.0.255
    access-list 101 permit ip any 192.168.202.0 0.0.0.255
    access-list 101 permit ip any 192.168.100.0 0.0.0.255
    access-list 10 permit 192.168.100.0 0.0.0.255
    snmp-server community public RO
    snmp-server community private RW
    snmp-server enable traps tty
    !
    route-map NAT_E1 permit 20
    match ip address 10
    match interface Ethernet1/0
    !
    route-map NAT_E0 permit 20
    match ip address 10
    match interface Ethernet0/0
    !
    route-map alpha permit 10
    match ip address 101
    !
    route-map alpha permit 20
    set ip next-hop verify-availability 192.168.201.16 10 track 123
    set ip next-hop verify-availability 192.168.202.16 20 track 124
    !
    route-map ISP2 permit 10
    match interface Ethernet1/0
    !
    route-map ISP1 permit 10
    match interface Ethernet0/0
    !
    !
    control-plane
    !
    rtr 1
    type echo protocol ipIcmpEcho 192.168.201.16
    rtr schedule 1 life forever start-time now
    rtr 2
    type echo protocol ipIcmpEcho 192.168.202.16
    rtr schedule 2 life forever start-time now
    !
    line con 0
    exec-timeout 600 0
    line aux 0
    exec-timeout 600 0
    transport input all
    line vty 0 4
    exec-timeout 600 0
    password cisco
    login
    !
    ntp clock-period 17208221
    ntp server 192.168.200.127
    ntp server 192.168.100.127
    end




    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
     
    Vincent C Jones, Jul 26, 2004
    #12
  13. On Mon, 26 Jul 2004 15:13:08 +0000, Vincent C Jones wrote:

    > Yep, that's the way it appears to behave, and hence why there is a
    > problem. What is needed is the ability for NAT translation table entries
    > to be tied to tracked objects, so they can be removed immediately when
    > the tracked object fails.
    >
    >


    Could you use Embedded Syslog Manager + Tcl + (maybe) debug track or
    something to clear the nat table when the tracked object changes to down?
    Seems a bit bleeding edge, and not much different from a script on a box
    somewhere, but at least it's all in the router and maybe happens at the
    right time.

    --
    Rgds,
    Martin
     
    Martin Gallagher, Jul 28, 2004
    #13
  14. In article <>,
    Martin Gallagher <> wrote:
    >On Mon, 26 Jul 2004 15:13:08 +0000, Vincent C Jones wrote:
    >
    >> Yep, that's the way it appears to behave, and hence why there is a
    >> problem. What is needed is the ability for NAT translation table entries
    >> to be tied to tracked objects, so they can be removed immediately when
    >> the tracked object fails.

    >
    > Could you use Embedded Syslog Manager + Tcl + (maybe) debug track or
    >something to clear the nat table when the tracked object changes to down?
    >Seems a bit bleeding edge, and not much different from a script on a box
    >somewhere, but at least it's all in the router and maybe happens at the
    >right time.
    >
    >Martin


    According to the documentation, this should work! Ugly as sin, and only
    available on 800 & 1700 platforms, but an incredibly powerful facility
    (for this and other hacks) if it works. Time to do some studying, than
    into the lab to see how theory translates into practice.

    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
     
    Vincent C Jones, Jul 29, 2004
    #14
  15. In article <ce9lft$mqh$>,
    Vincent C Jones <> wrote:
    >In article <>,
    >Martin Gallagher <> wrote:
    >>On Mon, 26 Jul 2004 15:13:08 +0000, Vincent C Jones wrote:
    >>
    >>> Yep, that's the way it appears to behave, and hence why there is a
    >>> problem. What is needed is the ability for NAT translation table entries
    >>> to be tied to tracked objects, so they can be removed immediately when
    >>> the tracked object fails.

    >>
    >> Could you use Embedded Syslog Manager + Tcl + (maybe) debug track or
    >>something to clear the nat table when the tracked object changes to down?
    >>Seems a bit bleeding edge, and not much different from a script on a box
    >>somewhere, but at least it's all in the router and maybe happens at the
    >>right time.
    >>
    >>Martin

    >
    >According to the documentation, this should work! Ugly as sin, and only
    >available on 800 & 1700 platforms, but an incredibly powerful facility
    >(for this and other hacks) if it works. Time to do some studying, than
    >into the lab to see how theory translates into practice.


    A followup for those who have been anxiously waiting...

    I've spent some time in the lab (far more than should have been
    required) and preliminary results are in...

    As is often the case, what is in the documentation and what is in
    the shipping code are two different animals (running C1700 Software
    (C1700-K9O3SY7-M), Version 12.3(8)T1), but enough is there that
    the job can be done. Would you believe that the Tcl implementation
    does not recognize "else" or do simple math? Makes programing the
    necessary monitoring and actions really interesting. Oh yes, you
    also only get error messages from Tcl when shutting down ESM.

    I'm now looking for a beta site or two to wring out the
    implementation to make sure that while grody, there is an improvement
    in reliability over the offerings of other vendors for the dual
    DSL/cable ISPs, both NATted "give me Internet access" that is always
    avalailable application.

    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
     
    Vincent C Jones, Aug 11, 2004
    #15
    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. TechGuy
    Replies:
    2
    Views:
    2,301
  2. Tarek Hamdy
    Replies:
    12
    Views:
    5,606
    Tarek Hamdy
    Oct 7, 2004
  3. Replies:
    2
    Views:
    534
    Chennak
    Oct 13, 2005
  4. nmilford
    Replies:
    0
    Views:
    595
    nmilford
    Nov 21, 2007
  5. okrus
    Replies:
    0
    Views:
    1,557
    okrus
    Jun 3, 2008
Loading...

Share This Page