Subject: (usr-tc) RIP problem on HiperArc

From: Eric <[email-masked]>
Date: Thu, 25 Nov 1999 22:26:50 +0000

Hi all,

We are running software version V4.2.32 - 1 on our HiperArcs and we
have some problems with the RIP routing.

Some more details:
We have ran RIP on those 7 hiperarcs successfully for the past few months,
today however we experimented with the (rather new) OSPF code. Unfortunately
this fscked things up beyond any recognition and we changed back to using RIP.
Apart from the frequent crashes when entering commands (so yes, they were rebooted
in te meantime) RIP still won't work like it used to, I had to add static routes
on our cisco To Make Things Work(tm).
We merely disabled OSPF routing and restarted RIP and now some Arc refuse to announce
their pooladdress (a full class C) trough RIP to our cisco.
Strangely enough the customers who have a radius-assigned IP DO get announced via RIP
and are visible on our cisco (running rip version 2, same as the hiperarcs), so I guess
we can conclude that nothing is wrong in respect to the exchange of RIP routing information
between the Arcs and the Cisco.

Configuration details:

Cisco: (Cisco 7507 running IOS 11.1CC(20)

router ospf 100
 redistribute connected metric 5 subnets
 redistribute static metric 10 subnets
 redistribute rip metric 50 subnets
 network 62.112.0.0 0.0.0.127 area 31
 [snip irrelevant info]
!
router rip
 version 2
 timers basic 30 45 60 30
 passive-interface FastEthernet1/0/0
 network 62.0.0.0
 distribute-list 10 in FastEthernet1/0/0

[note range 62.112.8.x is assigned by our radius for specific customers]

R       62.112.8.7/32 [120/1] via 62.112.0.35, 00:00:16, FastEthernet1/0/0
R       62.112.8.4/32 [120/1] via 62.112.0.38, 00:00:06, FastEthernet1/0/0
R       62.112.8.5/32 [120/1] via 62.112.0.36, 00:00:16, FastEthernet1/0/0
R       62.112.8.2/32 [120/1] via 62.112.0.37, 00:00:34, FastEthernet1/0/0
R       62.112.8.3/32 [120/1] via 62.112.0.34, 00:00:02, FastEthernet1/0/0
R       62.112.8.1/32 [120/1] via 62.112.0.38, 00:00:06, FastEthernet1/0/0
R       62.112.8.14/32 [120/1] via 62.112.0.35, 00:00:16, FastEthernet1/0/0
S       62.112.6.0/24 [1/0] via 62.112.0.37
S       62.112.7.0/24 [1/0] via 62.112.0.38
R       62.112.2.0/24 [120/1] via 62.112.0.33, 00:00:02, FastEthernet1/0/0

So obviously some routes are learned via RIP from the Arcs... except for their
dialpools which are staticly configured (the arcs are configured to send 
aggregate routes only, probably the reason why they aren't even announcing
the single host routes for each dialinport)

Arc Config:

SHOW IP  NETWORK online SETTINGS: 
Interface:                                 eth:1
Network Address:                           62.112.0.36/25 
Frame Type:                                ETHERNET_II  
Status:                                    ENABLED  
Reconfigure Needed:                        FALSE   
Mask:                                      255.255.255.128
Station:                                   62.112.0.36
Broadcast Algorithm:                       IETF
Max Reassembly Size:                       3464
WAN Type:                                  N/A
Remote IP Address:                         0.0.0.0
IP Routing Protocols:                      
                                            RIPV2 
IP Routing Metric:                         1
RIP Interface Export Metric:               0
IP RIP Routing Policies:                   
                                           SEND_ROUTES
                                           FLASH_UPDATE
                                           RIPV2_RECEIVE
IP RIP Authentication Key:                 

list rtab preferred

     62.112.2.0/C  RIP    7840      62.112.0.33     2      eth:1 <- this *can* be seen on the cisco

     But there is no logic at all in why certain pools get announced and some don't (hence this mail)

     62.112.5.0/C  REMOTE 7324      NONE            1      NONE   <- This is his localpool
     62.112.5.1/H  LOCAL  2358      62.112.5.1      0      slot:3/mod:25
     62.112.5.2/H  LOCAL  895       62.112.5.2      0      slot:6/mod:26
     62.112.5.4/H  LOCAL  1670      62.112.5.4      0      slot:8/mod:8
     62.112.5.6/H  LOCAL  9968      62.112.5.6      0      slot:1/mod:11
     62.112.5.7/H  LOCAL  1078      62.112.5.7      0      slot:5/mod:6
     62.112.5.8/H  LOCAL  2235      62.112.5.8      0      slot:7/mod:1

I'll explain the OSPF problems in a next mail or so...

-- 
Eric 
Senior Network & Systems Engineer             | http://www.online.be
Online Internet nv                            | email: [email-masked]
. . . . . . . . . . . . . . . . . . . . . . . | Tel  : +32 (0)9 244.11.11
RIPE Handle: EL357-RIPE                       | Fax  : +32 (0)9 222.64.80

 "It is not true that life is one damn thing after another -- it's one
                    damn thing over and over."

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.