Re: Eigrp not responding to bandwidth commands [7:38744]

2002-03-19 Thread MADMAN

In the diagram and configs it's not clear where exactly nw 1, 2 and 3
are, you cut that part of the config out.  I know changing the bandwidth
works well and quite fast.  I have done so in the past for a customer
running a 6M ATM pipe and T1 frame relay for redundancy.  We needed to
work on the router that terminated the ATM so I simply changed the
bandwidth to 100 and with a couple seconds all the traffic reverted to
frame.

  If you really only want to test whether changing the bandwidth works
simply connect two routers back to back with two serial connections,
equal clocks, no distribute lists and then change the bandwidth.

  Dave

V patankar wrote:
 
 Hi,
 
 I have a very simple three router scenario, using 12.0(10) IOS on 1200
 platform, and configured to run EIGRP.
 
 
RB
S0/   \ s1
(nw 1) bw=512/  \   bw=1024  (nw  2)
 s1 /\ s1
   RC --- RA
  bw=512
  nw 3
 
 All the three links are serial links connected by using a back-to-back X.21
 cables.
 
 Looking at the above diagram you would expect the following
 
 RB
 
 all traffic will be send over interface S1 to reach nw 3, and no load
 balancing should take place.
 
 RC
 
 Two routes, to reach network nw 2, load balancing should take place, and
two
 routes should be seen in the routing tabel.
 
 RA
 
 All traffic should leave via interface S1 to reach the nw 1 and no load
 balancing should take place.
 
 Problem:
 
 All the routers are showing that two paths exist to reach the destination
 networks.
 
 Please check the outputs:
 ---
 ra#
 interface Serial0
 bandwidth 512
 ip address 172.16.91.21 255.255.255.252
 no fair-queue
 !
 interface Serial1
 bandwidth 1024
 ip address 172.16.91.25 255.255.255.252
 !
 router eigrp 1
 passive-interface Ethernet0
 network 172.16.0.0
 distribute-list 1 out Serial0
 distribute-list 1 out Serial1
 auto-summary
 no eigrp log-neighbor-changes
 !
 D   172.16.91.28/30 [90/6023936] via 172.16.91.26,  Serial1
 [90/6023936] via 172.16.91.22,  Serial0
 C   172.16.91.24/30 is directly connected, Serial1
 ra#
 
 
 interface Serial0
 bandwidth 512
 ip address 172.16.91.30 255.255.255.252
 no ip directed-broadcast
 no ip mroute-cache
 no fair-queue
 clockrate 38400
 !
 interface Serial1
 bandwidth 1024
 ip address 172.16.91.26 255.255.255.252
 no ip directed-broadcast
 clockrate 38400
 !
 router eigrp 1
 passive-interface Ethernet0
 network 172.16.0.0
 distribute-list 1 out Serial0
 distribute-list 1 out Serial1
 rb#
 
 172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
 C   172.16.15.0/24 is directly connected, Ethernet0
 D   172.16.91.20/30 [90/6023936] via 172.16.91.25, Serial1
 [90/6023936] via 172.16.91.29, Serial0
 C   172.16.91.28/30 is directly connected, Serial0
 C   172.16.91.24/30 is directly connected, Serial1
 -
 rc#
 
 interface Serial0
 bandwidth 512
 ip address 172.16.91.22 255.255.255.252
 no ip directed-broadcast
 no ip mroute-cache
 delay 2000
 no fair-queue
 clockrate 38400
 !
 interface Serial1
 bandwidth 512
 ip address 172.16.91.29 255.255.255.252
 no ip directed-broadcast
 !
 router eigrp 1
 passive-interface Ethernet0
 network 172.16.0.0
 distribute-list 1 out Serial0
 distribute-list 1 out Serial1
 !
 
 Gateway of last resort is not set
 
 172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
 C   172.16.14.0/24 is directly connected, Ethernet0
 C   172.16.91.20/30 is directly connected, Serial0
 C   172.16.91.28/30 is directly connected, Serial1
 D   172.16.91.24/30 [90/6023936] via 172.16.91.21,  Serial0
 [90/6023936] via 172.16.91.30,  Serial1
 rc#
 -
 P.S. By changing the delay parameter on rb for inteface s0 (2 - 20001)
 will for the traffic to go via interface s1.
 
 Has anyone seen this behaviour before, is it normal for Eigrp to behave in
 such a way ?
 
 Note: All the Ethernet networks are 172.16.15.0, 172.16.14.0 and
172.16.90.0
 all using a 24 bit mask, the distribute list was used to stop these updates
 from entering the eigrp routing table.
 
 The main focus here is to find out why the bandwidth command when used in
 EIGRP is not effective. I hope I have not confussed anyone.
 
 Thanks in Advance.
 vp
-- 
David Madland
Sr. Network Engineer
CCIE# 2016
Qwest Communications Int. Inc.
[EMAIL PROTECTED]
612-664-3367

Emotion should reflect reason not guide it




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7i=38807t=38744
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]



Eigrp not responding to bandwidth commands [7:38744]

2002-03-18 Thread V patankar

Hi,

I have a very simple three router scenario, using 12.0(10) IOS on 1200
platform, and configured to run EIGRP.

 
   RB
   S0/   \ s1
   (nw 1) bw=512/  \   bw=1024  (nw  2)
s1 /\ s1
  RC --- RA
 bw=512
 nw 3

All the three links are serial links connected by using a back-to-back X.21
cables.


Looking at the above diagram you would expect the following

RB

all traffic will be send over interface S1 to reach nw 3, and no load
balancing should take place.

RC

Two routes, to reach network nw 2, load balancing should take place, and two
routes should be seen in the routing tabel.

RA

All traffic should leave via interface S1 to reach the nw 1 and no load
balancing should take place.


Problem:

All the routers are showing that two paths exist to reach the destination
networks.

Please check the outputs:
---
ra#
interface Serial0
bandwidth 512
ip address 172.16.91.21 255.255.255.252
no fair-queue
!
interface Serial1
bandwidth 1024
ip address 172.16.91.25 255.255.255.252
!
router eigrp 1
passive-interface Ethernet0
network 172.16.0.0
distribute-list 1 out Serial0
distribute-list 1 out Serial1
auto-summary
no eigrp log-neighbor-changes
!
D   172.16.91.28/30 [90/6023936] via 172.16.91.26,  Serial1
[90/6023936] via 172.16.91.22,  Serial0
C   172.16.91.24/30 is directly connected, Serial1
ra#


interface Serial0
bandwidth 512
ip address 172.16.91.30 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
no fair-queue
clockrate 38400
!
interface Serial1
bandwidth 1024
ip address 172.16.91.26 255.255.255.252
no ip directed-broadcast
clockrate 38400
!
router eigrp 1
passive-interface Ethernet0
network 172.16.0.0
distribute-list 1 out Serial0
distribute-list 1 out Serial1
rb#

172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C   172.16.15.0/24 is directly connected, Ethernet0
D   172.16.91.20/30 [90/6023936] via 172.16.91.25, Serial1
[90/6023936] via 172.16.91.29, Serial0
C   172.16.91.28/30 is directly connected, Serial0
C   172.16.91.24/30 is directly connected, Serial1
-
rc#

interface Serial0
bandwidth 512
ip address 172.16.91.22 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
delay 2000
no fair-queue
clockrate 38400
!
interface Serial1
bandwidth 512
ip address 172.16.91.29 255.255.255.252
no ip directed-broadcast
!
router eigrp 1
passive-interface Ethernet0
network 172.16.0.0
distribute-list 1 out Serial0
distribute-list 1 out Serial1
!

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C   172.16.14.0/24 is directly connected, Ethernet0
C   172.16.91.20/30 is directly connected, Serial0
C   172.16.91.28/30 is directly connected, Serial1
D   172.16.91.24/30 [90/6023936] via 172.16.91.21,  Serial0
[90/6023936] via 172.16.91.30,  Serial1
rc#
-
P.S. By changing the delay parameter on rb for inteface s0 (2 - 20001)
will for the traffic to go via interface s1.

Has anyone seen this behaviour before, is it normal for Eigrp to behave in
such a way ?

Note: All the Ethernet networks are 172.16.15.0, 172.16.14.0 and 172.16.90.0
all using a 24 bit mask, the distribute list was used to stop these updates
from entering the eigrp routing table.

The main focus here is to find out why the bandwidth command when used in
EIGRP is not effective. I hope I have not confussed anyone.

Thanks in Advance.
vp



Message Posted at:
http://www.groupstudy.com/form/read.php?f=7i=38744t=38744
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]