Can't get rid of phantom route.

Discussion in 'Cisco' started by Bryan McClendon, Sep 10, 2004.

  1. On 12.2(2)T1 on a 7206

    The Problem,

    We're having a problem that I find pretty odd, but I'm not a guru so maybe
    it is easy for someone else.

    Quite simply, we have a route that comes back for no reason that we can
    see. Obviously it's not in the config and the route isn't coming from
    any routing protocols. It must be cached somewhere but where?

    For example, we have this statement in the config:

    ip route 1.1.1.1 255.255.255.255 ATM1/0.2315

    cut and paste output (ips changed):

    girrt5#show ip route 1.1.1.1
    Routing entry for 1.1.1.1/32
    Known via "static", distance 1, metric 0 (connected)
    Routing Descriptor Blocks:
    * directly connected, via ATM1/0.2315
    Route metric is 0, traffic share count is 1
    directly connected, via ATM1/0.4562
    Route metric is 0, traffic share count is 1

    Where is that second route coming from? It shouldn't be there so we try to
    get rid of it.

    girrt5#clear ip route 1.1.1.1
    girrt5#show ip route 1.1.1.1
    Routing entry for 1.1.1.1/32
    Known via "static", distance 1, metric 0 (connected)
    Routing Descriptor Blocks:
    * directly connected, via ATM1/0.2315
    Route metric is 0, traffic share count is 1

    [wait about 60 seconds]
    girrt5#show ip route 1.1.1.1
    Routing entry for 1.1.1.1/32
    Known via "static", distance 1, metric 0 (connected)
    Routing Descriptor Blocks:
    * directly connected, via ATM1/0.2315
    Route metric is 0, traffic share count is 1
    directly connected, via ATM1/0.4562
    Route metric is 0, traffic share count is 1

    As you can see, the route is back. WTf?!

    Ok now here is what has happened so far. The unwanted route for 1.1.1.1 to
    ATM1/0.4562 was originaly brought up via DHCP. The IP was configured to
    only go to one MAC address via an 'ip dhcp pool' statement. This worked
    as intended. We then accidentally assigned it permanently to a pvc for a
    customer who made a request for a static IP:

    ip route 1.1.1.1 255.255.255.255 ATM1/0.2315

    At this point we have 1.1.1.1 both being given out via DHCP and also
    statically routed. The config was like this for a day with the IP both
    being in a dhcp pool statement (and leased out to a pvc) and also being
    routed directly to a PVC. This of course wasn't working out and both
    users had problems. Once we realized our error we set the dhcp pool
    statement to use another IP address, but for some reason the router still
    wants to assign 1.1.1.1 to the old pvc it was leased to via DHCP
    (ATM1/0.4562). We have tried reloading the router and also we have tried
    to do these things:

    girrt5#clear arp
    girrt5#clear ip route 1.1.1.1
    girrt5#clear ip dhcp binding 1.1.1.1
    % Adddress 1.1.1.1 is not in the database.
    girrt5#clear atm atm-vc ATM1/0 4 562
    svc (4,562) does not exist on interface ATM1/0

    That last was a shot in the dark, it's a pvc range not a svc.

    Why does this route come back? Where is it cached? Anyone have any ideas
    what we can do to get it to stop coming back?

    Relevant parts of the config:

    Here is the statement that used to lease 1.1.1.1 via DHCP
    ip dhcp pool tracey
    host 1.1.1.2 255.255.248.0
    client-identifier 0100.00f0.7f97.92
    default-router 1.1.1.3
    dns-server 1.1.1.4
    lease 0 8
    !

    Here are the two ATM interfaces (among many). Our DSL customers come up on
    these.

    interface ATM1/0.2035 point-to-point
    description Girard BDT
    ip unnumbered Loopback1
    ip access-group 101 in
    atm route-bridged ip
    range pvc 2/35 2/635
    ubr 1200
    encapsulation aal5snap
    !
    !
    interface ATM1/0.4035 point-to-point
    description Uniontown BDT
    ip unnumbered Loopback1
    ip access-group 101 in
    atm route-bridged ip
    range pvc 4/35 4/635
    ubr 1200
    encapsulation aal5snap
    !
    !

    Here is the ip being statically assigned to a pvc and removed from the
    dhcp database.:

    ip dhcp excluded-address 1.1.1.1
    ip route 1.1.1.1 255.255.255.255 ATM1/0.2315 name district_courthouse

    And finally,
    girrt5#show ver
    Cisco Internetwork Operating System Software
    IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(2)T1, RELEASE SOFTWARE (fc2)
    TAC Support: http://www.cisco.com/tac
    Copyright (c) 1986-2001 by cisco Systems, Inc.
    Compiled Wed 18-Jul-01 10:11 by ccai
    Image text-base: 0x600089C0, data-base: 0x6145A000

    ROM: System Bootstrap, Version 12.2(4r)B, RELEASE SOFTWARE (fc1)
    BOOTFLASH: 7200 Software (C7200-KBOOT-M), Version 12.1(8a)E, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

    girrt5 uptime is 19 hours, 37 minutes
    System returned to ROM by reload at 15:56:39 CDT Thu Sep 9 2004
    System restarted at 15:57:59 CDT Thu Sep 9 2004
    System image file is "disk0:7200ip1222T1_16f_128r.bin"

    cisco 7206VXR (NPE400) processor (revision A) with 114688K/16384K bytes of memory.
    Processor board ID 26813261
    R7000 CPU at 350Mhz, Implementation 39, Rev 3.3, 256KB L2, 4096KB L3 Cache
    6 slot VXR midplane, Version 2.6

    Last reset from power-on
    Bridging software.
    X.25 software, Version 3.0.0.
    2 FastEthernet/IEEE 802.3 interface(s)
    3 ATM network interface(s)
    125K bytes of non-volatile configuration memory.

    47040K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes).
    8192K bytes of Flash internal SIMM (Sector size 256K).
    Configuration register is 0x102


    Bryan McClendon
    Craw-Kan Telephone
    Bryan McClendon, Sep 10, 2004
    #1
    1. Advertising

  2. Bryan McClendon

    Brian V Guest

    1, You need to use the "no ip route" to remove the static, not clear ip
    route, thats only used to flush a routing table.
    2, You do not need a static route for a directly connected network.
    Interface ATM1/0.2315 is on the 1.1.1.1 network.

    -Brian

    <> wrote in message
    news:p...
    > On 12.2(2)T1 on a 7206
    >
    > The Problem,
    >
    > We're having a problem that I find pretty odd, but I'm not a guru so maybe
    > it is easy for someone else.
    >
    > Quite simply, we have a route that comes back for no reason that we can
    > see. Obviously it's not in the config and the route isn't coming from
    > any routing protocols. It must be cached somewhere but where?
    >
    > For example, we have this statement in the config:
    >
    > ip route 1.1.1.1 255.255.255.255 ATM1/0.2315
    >
    > cut and paste output (ips changed):
    >
    > girrt5#show ip route 1.1.1.1
    > Routing entry for 1.1.1.1/32
    > Known via "static", distance 1, metric 0 (connected)
    > Routing Descriptor Blocks:
    > * directly connected, via ATM1/0.2315
    > Route metric is 0, traffic share count is 1
    > directly connected, via ATM1/0.4562
    > Route metric is 0, traffic share count is 1
    >
    > Where is that second route coming from? It shouldn't be there so we try to
    > get rid of it.
    >
    > girrt5#clear ip route 1.1.1.1
    > girrt5#show ip route 1.1.1.1
    > Routing entry for 1.1.1.1/32
    > Known via "static", distance 1, metric 0 (connected)
    > Routing Descriptor Blocks:
    > * directly connected, via ATM1/0.2315
    > Route metric is 0, traffic share count is 1
    >
    > [wait about 60 seconds]
    > girrt5#show ip route 1.1.1.1
    > Routing entry for 1.1.1.1/32
    > Known via "static", distance 1, metric 0 (connected)
    > Routing Descriptor Blocks:
    > * directly connected, via ATM1/0.2315
    > Route metric is 0, traffic share count is 1
    > directly connected, via ATM1/0.4562
    > Route metric is 0, traffic share count is 1
    >
    > As you can see, the route is back. WTf?!
    >
    > Ok now here is what has happened so far. The unwanted route for 1.1.1.1 to
    > ATM1/0.4562 was originaly brought up via DHCP. The IP was configured to
    > only go to one MAC address via an 'ip dhcp pool' statement. This worked
    > as intended. We then accidentally assigned it permanently to a pvc for a
    > customer who made a request for a static IP:
    >
    > ip route 1.1.1.1 255.255.255.255 ATM1/0.2315
    >
    > At this point we have 1.1.1.1 both being given out via DHCP and also
    > statically routed. The config was like this for a day with the IP both
    > being in a dhcp pool statement (and leased out to a pvc) and also being
    > routed directly to a PVC. This of course wasn't working out and both
    > users had problems. Once we realized our error we set the dhcp pool
    > statement to use another IP address, but for some reason the router still
    > wants to assign 1.1.1.1 to the old pvc it was leased to via DHCP
    > (ATM1/0.4562). We have tried reloading the router and also we have tried
    > to do these things:
    >
    > girrt5#clear arp
    > girrt5#clear ip route 1.1.1.1
    > girrt5#clear ip dhcp binding 1.1.1.1
    > % Adddress 1.1.1.1 is not in the database.
    > girrt5#clear atm atm-vc ATM1/0 4 562
    > svc (4,562) does not exist on interface ATM1/0
    >
    > That last was a shot in the dark, it's a pvc range not a svc.
    >
    > Why does this route come back? Where is it cached? Anyone have any ideas
    > what we can do to get it to stop coming back?
    >
    > Relevant parts of the config:
    >
    > Here is the statement that used to lease 1.1.1.1 via DHCP
    > ip dhcp pool tracey
    > host 1.1.1.2 255.255.248.0
    > client-identifier 0100.00f0.7f97.92
    > default-router 1.1.1.3
    > dns-server 1.1.1.4
    > lease 0 8
    > !
    >
    > Here are the two ATM interfaces (among many). Our DSL customers come up on
    > these.
    >
    > interface ATM1/0.2035 point-to-point
    > description Girard BDT
    > ip unnumbered Loopback1
    > ip access-group 101 in
    > atm route-bridged ip
    > range pvc 2/35 2/635
    > ubr 1200
    > encapsulation aal5snap
    > !
    > !
    > interface ATM1/0.4035 point-to-point
    > description Uniontown BDT
    > ip unnumbered Loopback1
    > ip access-group 101 in
    > atm route-bridged ip
    > range pvc 4/35 4/635
    > ubr 1200
    > encapsulation aal5snap
    > !
    > !
    >
    > Here is the ip being statically assigned to a pvc and removed from the
    > dhcp database.:
    >
    > ip dhcp excluded-address 1.1.1.1
    > ip route 1.1.1.1 255.255.255.255 ATM1/0.2315 name district_courthouse
    >
    > And finally,
    > girrt5#show ver
    > Cisco Internetwork Operating System Software
    > IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(2)T1, RELEASE SOFTWARE
    > (fc2)
    > TAC Support: http://www.cisco.com/tac
    > Copyright (c) 1986-2001 by cisco Systems, Inc.
    > Compiled Wed 18-Jul-01 10:11 by ccai
    > Image text-base: 0x600089C0, data-base: 0x6145A000
    >
    > ROM: System Bootstrap, Version 12.2(4r)B, RELEASE SOFTWARE (fc1)
    > BOOTFLASH: 7200 Software (C7200-KBOOT-M), Version 12.1(8a)E, EARLY
    > DEPLOYMENT RELEASE SOFTWARE (fc1)
    >
    > girrt5 uptime is 19 hours, 37 minutes
    > System returned to ROM by reload at 15:56:39 CDT Thu Sep 9 2004
    > System restarted at 15:57:59 CDT Thu Sep 9 2004
    > System image file is "disk0:7200ip1222T1_16f_128r.bin"
    >
    > cisco 7206VXR (NPE400) processor (revision A) with 114688K/16384K bytes of
    > memory.
    > Processor board ID 26813261
    > R7000 CPU at 350Mhz, Implementation 39, Rev 3.3, 256KB L2, 4096KB L3 Cache
    > 6 slot VXR midplane, Version 2.6
    >
    > Last reset from power-on
    > Bridging software.
    > X.25 software, Version 3.0.0.
    > 2 FastEthernet/IEEE 802.3 interface(s)
    > 3 ATM network interface(s)
    > 125K bytes of non-volatile configuration memory.
    >
    > 47040K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes).
    > 8192K bytes of Flash internal SIMM (Sector size 256K).
    > Configuration register is 0x102
    >
    >
    > Bryan McClendon
    > Craw-Kan Telephone
    >
    Brian V, Sep 10, 2004
    #2
    1. Advertising

  3. The only static route that we have is pointing to the ATM1/0.2315
    interface. That is the route we want to keep, the route we don't want
    to keep is 1.1.1.1 going to ATM1/0.4562 There is nothing in the config, no
    static routes, no dhcp assignments, anything, that is pointing the 1.1.1.1
    IP to ATM1/0.4562 so there is nothing to do a 'no' command on. The only
    way to get rid of the route is to clear it from the routing table, but
    that is the problem I am having, the route comes back and I do not know
    why.

    Bryan


    On Fri, 10 Sep 2004 13:26:12 -0400, Brian V wrote:

    > 1, You need to use the "no ip route" to remove the static, not clear ip
    > route, thats only used to flush a routing table.
    > 2, You do not need a static route for a directly connected network.
    > Interface ATM1/0.2315 is on the 1.1.1.1 network.
    >
    > -Brian
    >
    >
    Bryan McClendon, Sep 10, 2004
    #3
  4. Bryan McClendon

    Doan Guest

    Try reloading your router.

    Doan

    On Fri, 10 Sep 2004, Bryan McClendon wrote:

    >
    > The only static route that we have is pointing to the ATM1/0.2315
    > interface. That is the route we want to keep, the route we don't want
    > to keep is 1.1.1.1 going to ATM1/0.4562 There is nothing in the config, no
    > static routes, no dhcp assignments, anything, that is pointing the 1.1.1.1
    > IP to ATM1/0.4562 so there is nothing to do a 'no' command on. The only
    > way to get rid of the route is to clear it from the routing table, but
    > that is the problem I am having, the route comes back and I do not know
    > why.
    >
    > Bryan
    >
    >
    > On Fri, 10 Sep 2004 13:26:12 -0400, Brian V wrote:
    >
    > > 1, You need to use the "no ip route" to remove the static, not clear ip
    > > route, thats only used to flush a routing table.
    > > 2, You do not need a static route for a directly connected network.
    > > Interface ATM1/0.2315 is on the 1.1.1.1 network.
    > >
    > > -Brian
    > >
    > >

    >
    Doan, Sep 11, 2004
    #4
  5. Bryan McClendon

    White Sheep Guest

    Hi,

    It is probably being installed by a routing process. For example EIGRP will
    generate a static route when you perform route summarisation, as will some
    other protocols under varying conditions. Is it possible to post a 'show
    run'?

    Cheers,

    Greg.


    "Bryan McClendon" <> wrote in message
    news:p...
    > On 12.2(2)T1 on a 7206
    >
    > The Problem,
    >
    > We're having a problem that I find pretty odd, but I'm not a guru so maybe
    > it is easy for someone else.
    >
    > Quite simply, we have a route that comes back for no reason that we can
    > see. Obviously it's not in the config and the route isn't coming from
    > any routing protocols. It must be cached somewhere but where?
    >
    > For example, we have this statement in the config:
    >
    > ip route 1.1.1.1 255.255.255.255 ATM1/0.2315
    >
    > cut and paste output (ips changed):
    >
    > girrt5#show ip route 1.1.1.1
    > Routing entry for 1.1.1.1/32
    > Known via "static", distance 1, metric 0 (connected)
    > Routing Descriptor Blocks:
    > * directly connected, via ATM1/0.2315
    > Route metric is 0, traffic share count is 1
    > directly connected, via ATM1/0.4562
    > Route metric is 0, traffic share count is 1
    >
    > Where is that second route coming from? It shouldn't be there so we try to
    > get rid of it.
    >
    > girrt5#clear ip route 1.1.1.1
    > girrt5#show ip route 1.1.1.1
    > Routing entry for 1.1.1.1/32
    > Known via "static", distance 1, metric 0 (connected)
    > Routing Descriptor Blocks:
    > * directly connected, via ATM1/0.2315
    > Route metric is 0, traffic share count is 1
    >
    > [wait about 60 seconds]
    > girrt5#show ip route 1.1.1.1
    > Routing entry for 1.1.1.1/32
    > Known via "static", distance 1, metric 0 (connected)
    > Routing Descriptor Blocks:
    > * directly connected, via ATM1/0.2315
    > Route metric is 0, traffic share count is 1
    > directly connected, via ATM1/0.4562
    > Route metric is 0, traffic share count is 1
    >
    > As you can see, the route is back. WTf?!
    >
    > Ok now here is what has happened so far. The unwanted route for 1.1.1.1 to
    > ATM1/0.4562 was originaly brought up via DHCP. The IP was configured to
    > only go to one MAC address via an 'ip dhcp pool' statement. This worked
    > as intended. We then accidentally assigned it permanently to a pvc for a
    > customer who made a request for a static IP:
    >
    > ip route 1.1.1.1 255.255.255.255 ATM1/0.2315
    >
    > At this point we have 1.1.1.1 both being given out via DHCP and also
    > statically routed. The config was like this for a day with the IP both
    > being in a dhcp pool statement (and leased out to a pvc) and also being
    > routed directly to a PVC. This of course wasn't working out and both
    > users had problems. Once we realized our error we set the dhcp pool
    > statement to use another IP address, but for some reason the router still
    > wants to assign 1.1.1.1 to the old pvc it was leased to via DHCP
    > (ATM1/0.4562). We have tried reloading the router and also we have tried
    > to do these things:
    >
    > girrt5#clear arp
    > girrt5#clear ip route 1.1.1.1
    > girrt5#clear ip dhcp binding 1.1.1.1
    > % Adddress 1.1.1.1 is not in the database.
    > girrt5#clear atm atm-vc ATM1/0 4 562
    > svc (4,562) does not exist on interface ATM1/0
    >
    > That last was a shot in the dark, it's a pvc range not a svc.
    >
    > Why does this route come back? Where is it cached? Anyone have any ideas
    > what we can do to get it to stop coming back?
    >
    > Relevant parts of the config:
    >
    > Here is the statement that used to lease 1.1.1.1 via DHCP
    > ip dhcp pool tracey
    > host 1.1.1.2 255.255.248.0
    > client-identifier 0100.00f0.7f97.92
    > default-router 1.1.1.3
    > dns-server 1.1.1.4
    > lease 0 8
    > !
    >
    > Here are the two ATM interfaces (among many). Our DSL customers come up on
    > these.
    >
    > interface ATM1/0.2035 point-to-point
    > description Girard BDT
    > ip unnumbered Loopback1
    > ip access-group 101 in
    > atm route-bridged ip
    > range pvc 2/35 2/635
    > ubr 1200
    > encapsulation aal5snap
    > !
    > !
    > interface ATM1/0.4035 point-to-point
    > description Uniontown BDT
    > ip unnumbered Loopback1
    > ip access-group 101 in
    > atm route-bridged ip
    > range pvc 4/35 4/635
    > ubr 1200
    > encapsulation aal5snap
    > !
    > !
    >
    > Here is the ip being statically assigned to a pvc and removed from the
    > dhcp database.:
    >
    > ip dhcp excluded-address 1.1.1.1
    > ip route 1.1.1.1 255.255.255.255 ATM1/0.2315 name district_courthouse
    >
    > And finally,
    > girrt5#show ver
    > Cisco Internetwork Operating System Software
    > IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(2)T1, RELEASE SOFTWARE
    > (fc2)
    > TAC Support: http://www.cisco.com/tac
    > Copyright (c) 1986-2001 by cisco Systems, Inc.
    > Compiled Wed 18-Jul-01 10:11 by ccai
    > Image text-base: 0x600089C0, data-base: 0x6145A000
    >
    > ROM: System Bootstrap, Version 12.2(4r)B, RELEASE SOFTWARE (fc1)
    > BOOTFLASH: 7200 Software (C7200-KBOOT-M), Version 12.1(8a)E, EARLY
    > DEPLOYMENT RELEASE SOFTWARE (fc1)
    >
    > girrt5 uptime is 19 hours, 37 minutes
    > System returned to ROM by reload at 15:56:39 CDT Thu Sep 9 2004
    > System restarted at 15:57:59 CDT Thu Sep 9 2004
    > System image file is "disk0:7200ip1222T1_16f_128r.bin"
    >
    > cisco 7206VXR (NPE400) processor (revision A) with 114688K/16384K bytes of
    > memory.
    > Processor board ID 26813261
    > R7000 CPU at 350Mhz, Implementation 39, Rev 3.3, 256KB L2, 4096KB L3 Cache
    > 6 slot VXR midplane, Version 2.6
    >
    > Last reset from power-on
    > Bridging software.
    > X.25 software, Version 3.0.0.
    > 2 FastEthernet/IEEE 802.3 interface(s)
    > 3 ATM network interface(s)
    > 125K bytes of non-volatile configuration memory.
    >
    > 47040K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes).
    > 8192K bytes of Flash internal SIMM (Sector size 256K).
    > Configuration register is 0x102
    >
    >
    > Bryan McClendon
    > Craw-Kan Telephone
    >
    White Sheep, Sep 13, 2004
    #5
  6. Bryan McClendon

    micke Guest

    isnt this a result of the link protocol you are running of the
    connection line a PPP host route for the protocoll to work

    /micke

    "White Sheep" <> wrote in message news:<>...
    > Hi,
    >
    > It is probably being installed by a routing process. For example EIGRP will
    > generate a static route when you perform route summarisation, as will some
    > other protocols under varying conditions. Is it possible to post a 'show
    > run'?
    >
    > Cheers,
    >
    > Greg.
    >
    >
    > "Bryan McClendon" <> wrote in message
    > news:p...
    > > On 12.2(2)T1 on a 7206
    > >
    > > The Problem,
    > >
    > > We're having a problem that I find pretty odd, but I'm not a guru so maybe
    > > it is easy for someone else.
    > >
    > > Quite simply, we have a route that comes back for no reason that we can
    > > see. Obviously it's not in the config and the route isn't coming from
    > > any routing protocols. It must be cached somewhere but where?
    > >
    > > For example, we have this statement in the config:
    > >
    > > ip route 1.1.1.1 255.255.255.255 ATM1/0.2315
    > >
    > > cut and paste output (ips changed):
    > >
    > > girrt5#show ip route 1.1.1.1
    > > Routing entry for 1.1.1.1/32
    > > Known via "static", distance 1, metric 0 (connected)
    > > Routing Descriptor Blocks:
    > > * directly connected, via ATM1/0.2315
    > > Route metric is 0, traffic share count is 1
    > > directly connected, via ATM1/0.4562
    > > Route metric is 0, traffic share count is 1
    > >
    > > Where is that second route coming from? It shouldn't be there so we try to
    > > get rid of it.
    > >
    > > girrt5#clear ip route 1.1.1.1
    > > girrt5#show ip route 1.1.1.1
    > > Routing entry for 1.1.1.1/32
    > > Known via "static", distance 1, metric 0 (connected)
    > > Routing Descriptor Blocks:
    > > * directly connected, via ATM1/0.2315
    > > Route metric is 0, traffic share count is 1
    > >
    > > [wait about 60 seconds]
    > > girrt5#show ip route 1.1.1.1
    > > Routing entry for 1.1.1.1/32
    > > Known via "static", distance 1, metric 0 (connected)
    > > Routing Descriptor Blocks:
    > > * directly connected, via ATM1/0.2315
    > > Route metric is 0, traffic share count is 1
    > > directly connected, via ATM1/0.4562
    > > Route metric is 0, traffic share count is 1
    > >
    > > As you can see, the route is back. WTf?!
    > >
    > > Ok now here is what has happened so far. The unwanted route for 1.1.1.1 to
    > > ATM1/0.4562 was originaly brought up via DHCP. The IP was configured to
    > > only go to one MAC address via an 'ip dhcp pool' statement. This worked
    > > as intended. We then accidentally assigned it permanently to a pvc for a
    > > customer who made a request for a static IP:
    > >
    > > ip route 1.1.1.1 255.255.255.255 ATM1/0.2315
    > >
    > > At this point we have 1.1.1.1 both being given out via DHCP and also
    > > statically routed. The config was like this for a day with the IP both
    > > being in a dhcp pool statement (and leased out to a pvc) and also being
    > > routed directly to a PVC. This of course wasn't working out and both
    > > users had problems. Once we realized our error we set the dhcp pool
    > > statement to use another IP address, but for some reason the router still
    > > wants to assign 1.1.1.1 to the old pvc it was leased to via DHCP
    > > (ATM1/0.4562). We have tried reloading the router and also we have tried
    > > to do these things:
    > >
    > > girrt5#clear arp
    > > girrt5#clear ip route 1.1.1.1
    > > girrt5#clear ip dhcp binding 1.1.1.1
    > > % Adddress 1.1.1.1 is not in the database.
    > > girrt5#clear atm atm-vc ATM1/0 4 562
    > > svc (4,562) does not exist on interface ATM1/0
    > >
    > > That last was a shot in the dark, it's a pvc range not a svc.
    > >
    > > Why does this route come back? Where is it cached? Anyone have any ideas
    > > what we can do to get it to stop coming back?
    > >
    > > Relevant parts of the config:
    > >
    > > Here is the statement that used to lease 1.1.1.1 via DHCP
    > > ip dhcp pool tracey
    > > host 1.1.1.2 255.255.248.0
    > > client-identifier 0100.00f0.7f97.92
    > > default-router 1.1.1.3
    > > dns-server 1.1.1.4
    > > lease 0 8
    > > !
    > >
    > > Here are the two ATM interfaces (among many). Our DSL customers come up on
    > > these.
    > >
    > > interface ATM1/0.2035 point-to-point
    > > description Girard BDT
    > > ip unnumbered Loopback1
    > > ip access-group 101 in
    > > atm route-bridged ip
    > > range pvc 2/35 2/635
    > > ubr 1200
    > > encapsulation aal5snap
    > > !
    > > !
    > > interface ATM1/0.4035 point-to-point
    > > description Uniontown BDT
    > > ip unnumbered Loopback1
    > > ip access-group 101 in
    > > atm route-bridged ip
    > > range pvc 4/35 4/635
    > > ubr 1200
    > > encapsulation aal5snap
    > > !
    > > !
    > >
    > > Here is the ip being statically assigned to a pvc and removed from the
    > > dhcp database.:
    > >
    > > ip dhcp excluded-address 1.1.1.1
    > > ip route 1.1.1.1 255.255.255.255 ATM1/0.2315 name district_courthouse
    > >
    > > And finally,
    > > girrt5#show ver
    > > Cisco Internetwork Operating System Software
    > > IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(2)T1, RELEASE SOFTWARE
    > > (fc2)
    > > TAC Support: http://www.cisco.com/tac
    > > Copyright (c) 1986-2001 by cisco Systems, Inc.
    > > Compiled Wed 18-Jul-01 10:11 by ccai
    > > Image text-base: 0x600089C0, data-base: 0x6145A000
    > >
    > > ROM: System Bootstrap, Version 12.2(4r)B, RELEASE SOFTWARE (fc1)
    > > BOOTFLASH: 7200 Software (C7200-KBOOT-M), Version 12.1(8a)E, EARLY
    > > DEPLOYMENT RELEASE SOFTWARE (fc1)
    > >
    > > girrt5 uptime is 19 hours, 37 minutes
    > > System returned to ROM by reload at 15:56:39 CDT Thu Sep 9 2004
    > > System restarted at 15:57:59 CDT Thu Sep 9 2004
    > > System image file is "disk0:7200ip1222T1_16f_128r.bin"
    > >
    > > cisco 7206VXR (NPE400) processor (revision A) with 114688K/16384K bytes of
    > > memory.
    > > Processor board ID 26813261
    > > R7000 CPU at 350Mhz, Implementation 39, Rev 3.3, 256KB L2, 4096KB L3 Cache
    > > 6 slot VXR midplane, Version 2.6
    > >
    > > Last reset from power-on
    > > Bridging software.
    > > X.25 software, Version 3.0.0.
    > > 2 FastEthernet/IEEE 802.3 interface(s)
    > > 3 ATM network interface(s)
    > > 125K bytes of non-volatile configuration memory.
    > >
    > > 47040K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes).
    > > 8192K bytes of Flash internal SIMM (Sector size 256K).
    > > Configuration register is 0x102
    > >
    > >
    > > Bryan McClendon
    > > Craw-Kan Telephone
    > >
    micke, Sep 13, 2004
    #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. AM
    Replies:
    3
    Views:
    633
  2. Replies:
    1
    Views:
    5,171
    Barry Margolin
    Aug 13, 2005
  3. Bruce Cao
    Replies:
    3
    Views:
    4,487
    Barry Margolin
    Dec 6, 2005
  4. Replies:
    13
    Views:
    1,437
  5. Replies:
    9
    Views:
    5,047
    Scott Perry
    Aug 7, 2008
Loading...

Share This Page