Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > Can't get rid of phantom route.

Reply
Thread Tools

Can't get rid of phantom route.

 
 
Bryan McClendon
Guest
Posts: n/a
 
      09-10-2004
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

 
Reply With Quote
 
 
 
 
Brian V
Guest
Posts: n/a
 
      09-10-2004
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

<(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> 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
>



 
Reply With Quote
 
 
 
 
Bryan McClendon
Guest
Posts: n/a
 
      09-10-2004

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
>
>

 
Reply With Quote
 
Doan
Guest
Posts: n/a
 
      09-10-2004

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
> >
> >

>


 
Reply With Quote
 
White Sheep
Guest
Posts: n/a
 
      09-13-2004
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" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> 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
>



 
Reply With Quote
 
micke
Guest
Posts: n/a
 
      09-13-2004
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" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> 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" <(E-Mail Removed)> wrote in message
> news(E-Mail Removed)...
> > 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
> >

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how do I get rid of beeping sound every time I get a new email? joe54345@gmail.com Computer Support 13 12-06-2005 10:14 PM
Antec Phantom 500 Power Supply Review at XYZ Computing Silverstrand Front Page News 0 08-23-2005 01:29 AM
Phantom folder in path Thomas Scheiderich ASP .Net 0 06-27-2004 03:34 AM
Phantom ports Mark Bryant Cisco 1 04-14-2004 07:10 PM
Phantom space and resize problem. Rod Billett ASP .Net 0 10-24-2003 08:35 PM



Advertisments