thr3ads.net - LARTC - Rip problems [Sep 2002]

Joseph Watson

2002-Sep-28 10:46 UTC

Rip problems

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

=09I am running a portmaster for dialup customers.  This portmaster has a=
 T1=20
connected to it, and is the gateway to the internet.  Behind it I have a=20
class C network divided up into 4 subnets, netmask 255.255.255.192 or /26=
=2E =20
One of the subnets is behind my linuxbox (the 192 network).  The portmast=
er=20
is running rip(1), so I installed routed on the linux box, and configured=
 it=20
to share its information.

ie.
EXPORT_GATEWAY=3D"no"
SILENT=3D"no"

  When I start routed, the appropriate routes show up in the portmaster a=
fter=20
about a 30 seconds, and all works good for about 2 1/2 minutes.  Then the=
=20
portmaster sets the Metric to 16 for the route to my subnet behind the=20
firewall, and routing quits working.  If I restart routed, we will repeat=
 the=20
process.  If I stop routed during the 2 1/2 mins, it will immediately set=
 the=20
Met to 16.  This tells me that they are communicating because when I shut=
=20
routed down the metric is set to 16.  But why does this happen exactly at=
 2=20
1/2 min??  I am quite confused?

Any suggestions would be great.

- --=20
Regards

Joseph Watson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9lesTABydhMNsDgMRAuZzAKCDKkKGviW6PYX4YxDyTfyzikNhHQCeLiSz
+cONh6fjWlgOY4eirljT0CI=3D
=3DvgXh
-----END PGP SIGNATURE-----

Joseph Watson

2002-Sep-28 12:10 UTC

link

Rip problems

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I have identified the source of the problem, but not the cause of it. Her=
e is a output from
tcpdump that shows the rip traffic from the routed process on the linuxbo=
x.  Again I have
configured routed as follows:

EXPORT_GATEWAY=3D"no"
SILENT=3D"no"

and it gets its information from the network setup on the localmachine.

in the following output, all xx.xx.xx. represent the same class C address=
=2E

[root@dwwireless httpd]# tcpdump -ni eth0 udp port 520 and src host xx.xx=
=2Exx.52
tcpdump: listening on eth0
12:33:16.427345 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:33:21.658707 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(16) {xx.xx.xx.0}(16) (DF)  <----- restarted routed ------
12:33:22.359761 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-req 24 (DF)
12:33:52.358588 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:34:22.359529 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:34:52.360541 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:35:22.361625 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:35:52.362543 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:36:22.365285 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF)
12:36:52.364554 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF)
12:37:22.365592 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:37:52.366556 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:38:22.367531 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:38:52.368547 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:39:22.369516 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:39:52.370524 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:40:22.371571 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:40:52.372525 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:41:22.373521 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:41:52.374513 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:42:22.375511 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:42:28.221015 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(16) {xx.xx.xx.0}(16) (DF)  <---- restarted routed -------
12:42:28.937439 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-req 24 (DF)
12:42:59.066864 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:43:29.067806 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:43:59.068802 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:44:29.069811 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:44:59.070798 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:45:29.073590 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF)
12:45:59.072795 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 3]:=
 {xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF)
12:46:29.073861 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:46:59.074794 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:47:28.741356 xx.xx.xx.52.520 > xx.xx.xx.62.520:  RIPv1-resp [items 13]=
: {xx.xx.xx.65}(2) {xx.xx.xx.67}(2)[|rip] (DF)
12:47:29.075708 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:47:59.076795 xx.xx.xx.52.520 > xx.xx.xx.63.520:  RIPv1-resp [items 2]:=
 {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)

As you can see, routed is expiring the route xx.xx.xx.192 network, and ad=
ding one to the hole class C block.
This is obviously wrong, and I don't know why it is changing its routing =
information in mid swing???

Any Ideas?

- --
Regards

Joseph Watson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9lf6UABydhMNsDgMRAlT4AKDaZwYQHEzVA/VQGuadgeUlwcptsQCgxOyU
LWz1POL9TDTO+LELeMkFS3s=3D
=3DyRZe
-----END PGP SIGNATURE-----

James Sneeringer

2002-Sep-30 09:42 UTC

link

Rip problems

On Sat, Sep 28, 2002 at 01:46:37PM -0400, Joseph Watson wrote:
| EXPORT_GATEWAY="no"
| SILENT="no"

This should cause the equivalent of "routed -s" to be run.  The
"-s" tells
routed to send routing updates.  Check with "ps ax".  You can get
further
debugging out of it with "-d" and "-t".

|   When I start routed, the appropriate routes show up in the portmaster after
| about a 30 seconds, and all works good for about 2 1/2 minutes.  Then the
| portmaster sets the Metric to 16 for the route to my subnet behind the
| firewall, and routing quits working.

PortMasters do this when they think they need to remove the route from the
routing table.  They set the "O" flag (for obsolete, I guess) and set
the
metric to 16 (because 16 is the largest metric permitted by RIPv1).  The
route will eventually disappear from the table unless another update is
received.

| If I restart routed, we will repeat the
| process.  If I stop routed during the 2 1/2 mins, it will immediately set the
| Met to 16.  This tells me that they are communicating because when I shut
| routed down the metric is set to 16.  But why does this happen exactly at 2
| 1/2 min??  I am quite confused?

It sounds like routed isn't sending routing updates.  RIPv1 sends the whole
routing table every 30 seconds to the broadcast address (which is why it
takes about 30 seconds for the PortMaster to see the routes).  My guess is
it's only sending out the initial announcement, and when the PM doesn't see
subsequent announcements for a couple minutes, it drops the routes.

If possible, consider using OSPF instead.  RIPv1 is quite obsolete and
generally useless on subnetted networks like yours.  PortMasters have done
OSPF since ComOS 3.5, and you can implement it on Linux with zebra or gated.
For further PortMaster-specific help, consider subscribing to the
portmaster-users@portmasters.com list.  See http://www.portmasters.com/
for more info.

-James