| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3028.1 | rip trace | GIDDAY::KINGSMILL | Geoff Kingsmill, Australia | Mon Feb 26 1996 02:27 | 862 |
| 3028.2 | | MARVIN::FORSTER | | Wed Feb 28 1996 13:33 | 8 |
| 3028.3 | | MARVIN::FORSTER | | Wed Feb 28 1996 14:43 | 7 |
| 3028.4 | Fixed | GIDDAY::KINGSMILL | Geoff Kingsmill, Australia | Thu Mar 21 1996 15:55 | 4 |
| 3028.5 | same problem in V4.0-2 | YAKKA::KINGSMILL | Geoff Kingsmill, Australia | Mon Mar 10 1997 18:42 | 11 |
| I've upgraded a pair of parallel DECnis routers from V3.1-x to
V4.1-2 and now seem to have the same (or very similar) RIP problem
that was seen back in FEB-1996. Is it possible that this fix did not get
into V4.0? When two routers are in parallel we see the rip metric for
each route incrementing by 2 each update. Everything works fine if one
of the parallel routers is shutdown.
Is this a known problem or do you have ideas on what's wrong.
Thanks,
Geoff..
|
| 3028.6 | Mmmmm? | MARVIN::MILLS | | Tue Mar 11 1997 02:43 | 17 |
|
> I've upgraded a pair of parallel DECnis routers from V3.1-x to
>V4.1-2 and now seem to have the same (or very similar) RIP problem
>that was seen back in FEB-1996. Is it possible that this fix did not get
>into V4.0? When two routers are in parallel we see the rip metric for
>each route incrementing by 2 each update. Everything works fine if one
>of the parallel routers is shutdown.
> Is this a known problem or do you have ideas on what's wrong.
The fix is in for v3.1-9 and V4.0-2. Let me try and reproduce the
problem in the lab and I'll get back to you.
I assume the network is the same as described in .0?
Regards,
Grant.
|
| 3028.7 | It works for me. | MARVIN::MILLS | | Tue Mar 11 1997 11:25 | 108 |
| I've setup a network as follow in our lab :-
64.7.2.2 64.7.2.1
---------+-------------------------------+------------
| | |
L601-3-0 L602-3-1 |
NIS2 NIS1 L602-3-0-------+ 64.64.64.110
L601-4-0 L601-4-0 |
| | |
---------+-------------------------------+------------
64.7.3.2 64.7.3.1
Each NIS is running V4.0-1.
When I use DTF to trace the RIP update packets broadcast by NIS1
I see the correct metric for each of the parallel subnets being
Transmitted to circuit.
E.g:
-DTF- 0 ripTx 292 of 292 at 00:18:10.129 L602-3-0 1
Status: 8064FCC4 Context: 00000002 Function: 00000000
|
IP Packet: IP
Type of service 0x00 | Precedence Routine
Total length 292 | Packet identifier 0x00F8
Fragment offset 0x0000 | Time to live 2
Verified checksum 0xB4E4 | Source Address 64.64.64.110
Destination Address 64.64.64.255 | Protocol UDP
|
IP protocol: UDP
Verified UDP checksum 0x724B | UDP length 272
Source port router | Destination port router
|
UDP port: RIP
RIP version 1 | RIP Command Response
|
RIP command: Response
RIP Networks... 13 | network @ metric 1.0.0.0 @ 16
network @ metric 16.0.0.0 @ 16 | network @ metric 64.0.1.0 @ 16
network @ metric 64.0.2.0 @ 16 | network @ metric 64.6.6.0 @ 16
network @ metric 64.7.0.0 @ 16 | network @ metric 64.7.2.0 @ 1
network @ metric 64.7.3.0 @ 1 | network @ metric 64.20.226.0 @ 16
network @ metric 64.20.227.0 @ 16 | network @ metric 64.20.228.0 @ 16
network @ metric 64.21.250.0 @ 16 | network @ metric 64.70.0.0 @ 16
-DTF- 0 ripTx 292 of 292 at 00:18:10.129 L602-3-1 1
Status: 8064FCC4 Context: 00000002 Function: 00000000
|
IP Packet: IP
Type of service 0x00 | Precedence Routine
Total length 292 | Packet identifier 0x00F9
Fragment offset 0x0000 | Time to live 2
Verified checksum 0x31C1 | Source Address 64.7.2.1
Destination Address 64.7.2.255 | Protocol UDP
|
IP protocol: UDP
Verified UDP checksum 0xB184 | UDP length 272
Source port router | Destination port router
|
UDP port: RIP
RIP version 1 | RIP Command Response
|
RIP command: Response
RIP Networks... 13 | network @ metric 1.0.0.0 @ 2
network @ metric 16.0.0.0 @ 2 | network @ metric 64.0.1.0 @ 5
network @ metric 64.0.2.0 @ 3 | network @ metric 64.6.6.0 @ 4
network @ metric 64.7.0.0 @ 2 | network @ metric 64.7.3.0 @ 1
network @ metric 64.20.226.0 @ 2 | network @ metric 64.20.227.0 @ 2
network @ metric 64.20.228.0 @ 3 | network @ metric 64.21.250.0 @ 2
network @ metric 64.64.64.0 @ 1 | network @ metric 64.70.0.0 @ 2
-DTF- 0 ripTx 292 of 292 at 00:18:10.129 L601-4-0 1
Status: 8064FCC4 Context: 00000002 Function: 00000000
|
IP Packet: IP
Type of service 0x00 | Precedence Routine
Total length 292 | Packet identifier 0x00FA
Fragment offset 0x0000 | Time to live 2
Verified checksum 0x2FC0 | Source Address 64.7.3.1
Destination Address 64.7.3.255 | Protocol UDP
|
IP protocol: UDP
Verified UDP checksum 0xB084 | UDP length 272
Source port router | Destination port router
|
UDP port: RIP
RIP version 1 | RIP Command Response
|
RIP command: Response
RIP Networks... 13 | network @ metric 1.0.0.0 @ 2
network @ metric 16.0.0.0 @ 2 | network @ metric 64.0.1.0 @ 5
network @ metric 64.0.2.0 @ 3 | network @ metric 64.6.6.0 @ 4
network @ metric 64.7.0.0 @ 2 | network @ metric 64.7.2.0 @ 1
network @ metric 64.20.226.0 @ 2 | network @ metric 64.20.227.0 @ 2
network @ metric 64.20.228.0 @ 3 | network @ metric 64.21.250.0 @ 2
network @ metric 64.64.64.0 @ 1 | network @ metric 64.70.0.0 @ 2
network @ metric 64.20.228.0 @ 3 | network @ metric 64.21.250.0 @ 2
network @ metric 64.64.64.0 @ 1 | network @ metric 64.70.0.0 @ 2
As far as I can see there is nothing wrong with V4.0-# or V3.1-9.
So in order to solve your problem can you supply more info concerning
your configuration, network etc.
Regards,
Grant.
|
| 3028.8 | more details | YAKKA::KINGSMILL | Geoff Kingsmill, Australia | Tue Mar 11 1997 18:33 | 18 |
| Grant,
Thanks for following this up. After entering the note here I also tried to
reproduce the problem in an offline simplified environment and I was not able
to reproduce the problem either. In the operational environment however the
problem is totally reproduceable. The parallel DECnis's contain two FDDI's and
four ethernets. When I tried to emulate the behaviour I used parallel DECnis's
containing one FDDI and two ethernets.
If I go back to V3.1-9 everything works fine. As soon as I boot V4.0-2 the
incorrect RIP updates reappear so its definely related to V4.0-2. The network
trace shows the RIP metric incrementing by two on each update (ie. every 30
seconds) for subnets local to the router. The RIP metric for remote subnets are
fine. The network has a lot of subnets and so it takes four RIP packets to
transmit all subnets.
I will see if I can reproduce this using a similar offline configuration.
Any other suggestions or ideas?
Thanks,
Geoff..
|
| 3028.9 | Same Routing Code in each image. | MARVIN::MILLS | | Wed Mar 12 1997 06:12 | 15 |
| > If I go back to V3.1-9 everything works fine. As soon as I boot V4.0-2 the
>incorrect RIP updates reappear so its definely related to V4.0-2.
Both V3.1-9 and V4.0-2 contain exactly the same Routing code. So it is very
strange indeed that only V4.0-2 should exhibit this behaviour.
Can you tell me the procedure you go through when reloading the DECNIS units
with a new image. Which configurator are you using, VMS or the PC Windows
configurator? Are you using exactly the same configuration each time?
Regards,
Grant.
|
| 3028.10 | the finger and the mind are out of sync | YAKKA::KINGSMILL | Geoff Kingsmill, Australia | Wed Mar 12 1997 22:07 | 21 |
| Grant,
>> If I go back to V3.1-9 everything works fine. As soon as I boot V4.0-2 the
>>incorrect RIP updates reappear so its definely related to V4.0-2.
>
>Both V3.1-9 and V4.0-2 contain exactly the same Routing code. So it is very
>strange indeed that only V4.0-2 should exhibit this behaviour.
Sorry, The above is incorrect. V3.1-6 works fine. V4.0-2 fails. I also believe
V4.0-1 also fails but I have not confirmed this using a network trace.
>Can you tell me the procedure you go through when reloading the DECNIS units
>with a new image. Which configurator are you using, VMS or the PC Windows
>configurator? Are you using exactly the same configuration each time?
We installed V4.0-2 on VMS/VAX V6.2 and rebuilt the CMIP file. When the
DECnis's were rebooted the RIP problem occurred. We then rebooted using the
V3.1-6 system image with the new CMIP file and everything worked fine.
Thanks,
Geoff..
|
| 3028.11 | IPMT CFS.49698 | YAKKA::KINGSMILL | Geoff Kingsmill, Australia | Tue Mar 25 1997 16:31 | 5 |
| Just to close off this note. Grant provided a new image which fixes the V4.0.2
RIP problem.
Geoff..
|