4 Nov 2008 20:00
[quagga-users 10101] Re: OSPFD routing between networks, and/or "received on link eth0 but no ospf_interface"
I thought I'd post with my progress
After taking out the redistribute routes, double checking everything, and making sure it matches your suggestions it looks like I have some success!!
The problem I seem to be having, specifically with one of the routers is this:
I have 1 client off of porgw1 (10.2.x.x)
I have 1 client off of burgw1 (10.5.x.x)
I can ping from the client (10.2.x.x) and it goes client --> porgw1 --> (fiber connection) --> burgw1 --> client (10.5.x.x)
Now if I disconnect the fiber connection going to porgw1, it still works as expected using the ptp wireless link between porgw1 and stcgw1 (stcgw1 has a wireless and fiber connection):
client (10.2.x.x) --> porgw1 --> (wireless connection) --> stcgw1 ---> (fiber connection) ---> burgw1 ---> client (10.5.x.x)
The problem arises when I plug the fiber connection back in, it seems porgw1 never detects this, so it won't go back to using it, so if wireless goes down after, it won't be able to get anywhere. I checked /var/log/messages and can see the OS noticing that the interface got plugged back into, but ospf never seems to notice.
Just curious if anyone has any ideas what could be causing this? I have iptables completely turned off as well.
| Charles Briscoe-Smith <charles-quagga-6mWPojCWDXNcMsmgWJmlI+kiAK3p4hvP@public.gmane.org>
Sent by: quagga-users-bounces-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org 11/03/08 06:59 PM |
|
(Edited down your configurations to make them a bit more readable:)
On Mon, Nov 03, 2008 at 11:57:17AM -0500, Chris Beach wrote:
> hostname porgw1
>
> interface eth0
> ip address 10.2.1.1/16
>
> interface eth1
> ip address 192.168.1.2/29
>
> interface eth2
> ip address 172.16.1.2/30
>
> router ospf
> network 10.2.0.0/16 area 0
> network 192.168.1.2/29 area 0
> network 172.16.1.0/30 area 0
> hostname stcgw1
>
> interface eth0
> ip address 192.168.1.1/29
>
> interface eth1
> ip address 172.16.1.1/30
>
> interface eth2
> ip address 10.1.1.1/16
>
> router ospf
> network 10.1.0.0/16 area 0
> network 192.168.1.0/29 area 0
> network 172.16.1.0/30 area 0
> hostname burgw1
>
> interface eth0
> ip address 10.5.1.1/16
>
> interface eth1
> ip address 192.168.1.5/29
>
> router ospf
> network 192.168.1.0/29
> network 10.5.0.0/16
I've removed all the "redistribute" lines; I don't think they're relevant
here. I think I've only ever once needed to redistribute one static route
into OSPF. I would certainly suggest avoiding redistributing routes
unless you know exactly what routes you're intending to redistribute
and they aren't already in OSPF. In the configurations you've given,
for example, you don't need to "redistribute connected" because all your
interfaces are OSPF-enabled already.
> I put everything in area 0 since I had read somewhere it's simpler to
> start out that way then move forward.
Yes, definitely. Areas are, as far as I know, basically an optimisation.
Unless you have at least hundreds of routes in your OSPF I doubt you'll
need to worry about areas. I've never tried using them - they just sound
like too much trouble for my relatively small networks. Unless you're
getting towards the point where your routers will run out of memory for
more routes, or performance will suffer because of routing table size,
I doubt you need areas.
You don't say which interfaces are connected to which, but, if you have
them connected up as follows, I don't see why it shouldn't work:
Broadcast network linking together eth1 on porgw1, eth0 on stcgw1 and
eth1 on burgw1. (Presumably your fibre network.)
Point-to-point link connecting eth2 on porgw1 with eth1 on stcgw1.
(Radio link.)
Three separate client networks connected to eth0 on porgw1, eth2 on
stcgw1 and eth0 on burgw1.
> 10.1.0.0 via 192.168.1.1 eth1
> 10.2.0.0 via 192.168.1.2 eth1
> 10.5.0.0 is directly connected
> 172.16.1.0 via 192.168.1.2
> via 192.168.1.1
> 192.168.12.0 is directly connected
Looks reasonable (assuming 192.168.12.0 is a typo).
> so as of right now it can ping porgw1 (192.1658.1.2) because they are both
> on the fiber network, now if I disconnect the fiber connection from
> porgw1, it's only on wireless (172.16.1.2). Now I need burgw1 to send the
> data to stcgw1 which is on fiber AND wireless so it can route it over, but
> this does not happen. I'm unable to ping the wireless interface of porgw1
> (172.16.1.2) or the internal interface facing the lan (10.2.1.1)
If you try to ping 192.168.1.2 from burgw1, it'll try to use the connected
route via eth1, of course. That is quite normal and isn't a fault of
OSPF; connected routes have precedence over OSPF routes. If you really
want to be able to ping a link address which should be reachable via a
connected interface but, because the network's partitioned, it isn't,
you'd need to shut down that interface locally. This is the reason you
shouldn't use interface addresses on routers for real communications!
If you try pinging something on one of the client (10.*) networks
connected to each router, does that work? I'd've thought that what
you should be trying to make work correctly is the ability to reach
10.1.*.* from 10.2.*.* and all the other combinations of 10.1, 10.2 and
10.5, including when you have some plugs pulled out but not enough to
partition the whole system. If that criterion holds, then it should
be working properly. Don't use the addresses you're using to link your
routers together for anything other then routing.
If you want to have give your routers reliable addresses, add a loopback
address - a /32 address on the loopback interface lo - and add a network
line to the "router ospf" stanza covering it. (When I say loopback
address, I *don't* mean anything in 127.0.0.0/8 as that's reserved for
internal loopback within hosts and should never appear on any physical
network.) That address will then get included in the OSPF routing
domain and you can use that for talking to the router more reliably.
However, some UDP services (like snmpd) can reply from an interface
address when queried on a loopback address, and outgoing connections
will tend to come from interface addresses unless you specifically bind
them to the loopback address. It's much easier if you just have your
routers route, and put all services on hosts (on the 10.* networks).
That said, I do run quite a few services on quagga router, but I am
pretty careful about getting them configured correctly, so they don't
break as soon as my network topology changes!
I'm not sure I've explained that particularly clearly, but I hope
it helps.
--
Charles Briscoe-Smith
http://www.linkedin.com/in/charlesbriscoesmith
_______________________________________________
Quagga-users mailing list
Quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
http://lists.quagga.net/mailman/listinfo/quagga-users
_______________________________________________ Quagga-users mailing list Quagga-users@... http://lists.quagga.net/mailman/listinfo/quagga-users
RSS Feed