[prev in list] [next in list] [prev in thread] [next in thread]
List: firewall-1
Subject: Re: [FW-1] RIP "not on same net"
From: Crist Clark <Crist.Clark () GLOBALSTAR ! COM>
Date: 2008-05-28 17:39:42
Message-ID: 483D366A.8C45.0097.0 () globalstar ! com
[Download RAW message or body]
Just thought I'd answer my own question here.
I found out that if I got rid of the eth0:0 interface, suddenly,
things
worked. The routing daemon decided that the network on eth0 really was
"on same net." I tried swapping eth0 and eth0:0 configuration, but
that
didn't make a difference. What I had to do was use the,
primary-alias
Sub-command with the IP address I wanted to use in the "interface
eth0"
configuration.
Now, what I think is happening is that the routing daemon defaults to
the _lowest numbered_ network among the various nets configured on the
interface. This is contrary to the documentation which implies the
address on eth0 would be preferred. I say this because the system
didn't
like 206.aaa.bbb.ccc no matter whether it was on eth0 or eth0:0, it
seemed to prefer 65.ddd.eee.fff. Interestingly, we had previously done
a lab setup that had an eth0 and eth0:0 that worked fine on the first
try (which is why this time it was so frustrating), but in that case,
eth0 again had 206 in the first octet, but eth0:0 was greater, with
207 in the first octet.
So this is working now. But with this problem, I'm kind of afraid to
try to do RIP with multiple networks on one physical interface. I
don't
see how it would work in this implementation.
On 5/23/2008 at 11:20 AM, Crist Clark <Crist.Clark@GLOBALSTAR.COM>
wrote:
> SecurePlatformPro RIP has been driving me nuts. Here's the
> latest fun problem.
>
> The firewall is not picking up any of the routes from a
> router on its external interface. I turned on tracing,
> and it seems to be quite clear why,
>
> May 23 11:05:50.638860+0.000060 io_receive_packet: task
> RIP.0.0.0.0+520 from 206.220.219.193+520 to 224.0.0.9 socket 22
length
> 44
> May 23 11:05:50.638860+0.000088 RIP RECV 206.220.219.193 ->
224.0.0.9
> vers 2, cmd Response, length 44
> 0.0.0.0/0.0.0.0 router 0.0.0.0
metric
> 1 tag 0000
> 63.65.128.248/255.255.255.252 router 0.0.0.0
metric
> 1 tag 0000
> RIP RECV end of packet
> May 23 11:05:50.638860+0.000126
> May 23 11:05:50.638860+0.000142 rip_recv: ignoring RIP Response
> packet from 206.220.219.193+520 - not on same net
>
> That's the RIP response from the router at 206.220.219.193.
> The routing software complains that 206.220.219.193 is
> "not on the same net" and ignores it. However,
>
> # ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 00:1B:24:6D:F3:5E
> inet addr:206.220.219.206 Bcast:206.220.219.255
> Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:4473 errors:0 dropped:0 overruns:0 frame:0
> TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:492862 (481.3 Kb) TX bytes:5666 (5.5 Kb)
> Base address:0xec00 Memory:fe9e0000-fea00000
>
> And,
>
> # router
> localhost>en
> localhost#sh run
> Building configuration...
>
> router rip
> enable
> network 192.168.112.42 0.0.0.255
> network 206.220.219.206 0.0.0.255
> redistribute direct
> redistribute rip
> exit
> interface eth0
> ip rip enable
> ip rip version 2
> exit
> interface eth1
> ip rip enable
> ip rip version 2
> exit
>
> It sure looks like 206.220.219.193 is on the same net to me.
> Why is it telling me that?
>
> Oh, but I like this even more. When the firewall hears its own RIP
> responses go out,
>
> May 23 11:05:56.869959+0.000023 io_receive_packet: task
> RIP.0.0.0.0+520 from 206.220.219.206+520 to 224.0.0.9 socket 22
length
> 104
> May 23 11:05:56.869959+0.000049 RIP RECV 206.220.219.206 ->
224.0.0.9
> vers 2, cmd Response, length 104
> 206.220.219.224/255.255.255.224 router 0.0.0.0
metric
> 1 tag 0000
> 206.220.219.184/255.255.255.248 router 0.0.0.0
metric
> 2 tag 0000
> 192.168.112/255.255.255 router 0.0.0.0
metric
> 1 tag 0000
> 65.223.103.128/255.255.255.240 router 0.0.0.0
metric
> 1 tag 0000
> 65.223.103/255.255.255.240 router 0.0.0.0
metric
> 1 tag 0000
> RIP RECV end of packet
> May 23 11:05:56.869959+0.000124
> May 23 11:05:56.869959+0.000138 rip_recv: ignoring RIP Response
> packet from 206.220.219.206+520 - not on same net
>
> It claims they are not on the same net either. WTF?
>
> I've played around with the "network" command in the router
> configuration. I've used the natural class C address as you
> see above by just typing,
>
> localhost(config-router-rip)# network 206.220.219.206
>
> At the recommendation of Check Point. I've also tried the
> interface's real hostmask,
>
> localhost(config-router-rip)# network 206.220.219.206 0.0.0.15
>
> And using the network number rather than the interface IP,
>
> localhost(config-router-rip)# network 206.220.219.192 0.0.0.15
>
> Just to be complete. None made a difference.
>
> Finally, I should note everything works just fine on eth1
> which is 192.168.112.42/24.
>
> Anyone have ideas? For those in the USA, have a fun, safe
> Memorial Day Weekend.
B ¼information contained in this e-mail message is confidential, intended
only for the use of the individual or entity named above. If the reader
of this e-mail is not the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that any review, dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this e-mail
in error, please contact postmaster@globalstar.com
Scanned by Check Point Total Security Gateway.
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV@amadeus.us.checkpoint.com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner@ts.checkpoint.com
=================================================
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic