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: eric@noc.online.be . . . . . . . . . . . . . . . . . . . . . . . | 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 "majordomo@xmission.com" 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.