OSPF in V3

[oscarBravo]

I replaced a WRAP backbone router with a WAR yesterday. The WRAP was in a part of our network that's still OSPF routed. The replacement wasn't a happy experience.

It seems OSPF in V3 doesn't recognise virtual interfaces. The first radio has two IP addresses, because (as a temporary arrangement) it has two client routers connected downstream from it. So, wpci0 (to use the Linux nomenclature) has 10.30.39.73/30, and wpci0:0 has 10.30.39.81/30. Looking at "show ip ospf interface" I could see the 39.73 address on wpci0, but not the 39.81 address. In V2, both addresses would show as being on wpci0.

There also seems to be a problem with redistributing static routes entered in Zebra. This is a function that had worked well in V2, but only intermittently in V3 - some routes were redistributed while others weren't, and those that were disappeared from neighbouring routers after a while.

We reconfigured the router for fully static routing, which is an ongoing process in the network anyway.

StarV3 1.1.2 on a dual WAR.

[lonnie]

Is the issue that it does not show the second IP or that it does not use it? If you declare the subnet are you saying it is not announced?

[oscarBravo]

OSPF seems to be completely unaware of the address at all. "s i o i" shows the interface with only one address, whereas v2 showed both. There is a network statement to cover the subnet, but with (apparently) no active interface in the subnet it's not being advertised.

[sir_lunatic]

What was the outcome of this? I really need to use virtual interfaces and OSPF.

[lonnie]

We have no solution. This is a Quagga issue and we will watch their site for updates.

I'm not sure why you need alias addresses on an interface. I believe it is poor practice to have more than one IP subnet per segment. You can easily use a single subnet for all devices on the segment, so I do not see how this little quirk will make it impossible to use.

This worked in v2 which used the 2.4 kernel, but V3 uses the 2.6 kernel so perhaps Quagga is built with 2.4 in mind.

[meshnet]

Well,

This is an issue, and explains some problems we are seeing..
I do have some interfaces with more than one ip, and the reason
we do it, is most of our customers have private ip's, but most
of our businesses use public ips, and some of them refuse to connect their
vpn routers, etc to anything associated with private ip's..
So, our aps may have two ip's on an interface, a public ip subnet for
business customers, and a private for residential..

Remember, not all of these customers are wireless, some are on ethernet
interfaces also..

Has anyone tested this on vlans? if we set an ethernet port up with
multiple vlans, does quagga see all the ip's?


Richard

[meshnet]

Well, vlans didn't make any difference.. back to statics.

quagga shows it but no routes propagated.

Richard

[oscarBravo]

We have no solution. This is a Quagga issue and we will watch their site for updates. In my experience, you'll have better luck if you engage with them on the quagga-dev mailing list. I'm not sure why you need alias addresses on an interface. I believe it is poor practice to have more than one IP subnet per segment. You can easily use a single subnet for all devices on the segment, so I do not see how this little quirk will make it impossible to use. Actually, we used multiple addresses precisely to work around problems we were having with OSPF. When we had a point-to-multipoint radio configuration we originally had all the radios in the same subnet, but this didn't play nice with the fact that we had to configure the radio interfaces as non-broadcast. I've no idea whether this setup works any better in v3. This worked in v2 which used the 2.4 kernel, but V3 uses the 2.6 kernel so perhaps Quagga is built with 2.4 in mind. Quagga is cross-platform, running on (at least) Linux, BSD and Solaris, so I can't imagine a kernel version change would cause major loss of functionality. I have seen mention on the mailing lists of people using Quagga in a production environment, on Linux 2.6. Again, the best option is to engage with the Quagga developers.

[sir_lunatic]

The reason for using multiple ip's on an interface is because customers get publics and equipment gets privates. With thousands of customers and x times customers in equipment, public addresses are scarce. So a routed network with overlays for publics and privates and filters only allowing certain publics access to privates works rather well.

OSPF handles this rather well. No fudging with VLANS when dozens of pops are involved (gets rather complicated on large scale) plus the added benifit of being able to create rings within rings not only for customer traffic redundency but management as well.

[lonnie]

They have released 99.5 so we will grab it and get it built into the system. Expect the next release with this is about 4 weeks.

[bminish]

This worked in v2 which used the 2.4 kernel, but V3 uses the 2.6 kernel so perhaps Quagga is built with 2.4 in mind.

I have Quagga (various versions from 98.4 up) running on multiple platforms with differing kernel versions (almost all Linux 2.6.x versions though). I am also in the early stages of testing an open source distro for WRAP that appears to have a working Quagga implementation.

I do not, on any of these platforms have either the missing interface isues or the new (in v3) issue with no support for VLAN's

As it currently stands OSPF in V3 is much more seriously broken than in V2 and there is little evidence that the finger can simply be pointed at Quagga since Quagga seems to be working so well on so many other platforms

Perhaps it's time that Valemont engaged meaningfully on the Quagga Devel list?

.brendan

[lonnie]

Brendan,

I am not sure what the problem is here, but I can assure you it is not Quagga nor our System. I just fired up two systems with ospf. One of them is a simple single connection so that it can hear routes and show me what is happening in ospf land. The other system has ethernet with 3 IP addresses and an Atheros card with one IP.

The Ethernet is tagged as area 0 with
10.10.250.6 10.10.101.1 10.10.102.1 all on Ether1
10.10.222.1 is on wpci2 and is tagged as area 1

I made network statements on the main system of:
network 10.10.250.0/24 area 0
network 10.10.101.0/24 area 0
network 10.10.102.0/24 area 0
network 10.10.222.0/24 area 1

and as if by magic the monitor unit saw the following routing table
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.11.250.9 * 255.255.255.255 UH 0 0 0 eth0
127.0.0.1 * 255.255.255.255 UH 0 0 0 lo
10.10.250.9 * 255.255.255.255 UH 0 0 0 eth0
10.10.222.0 10.10.250.6 255.255.255.0 UG 20 0 0 eth0
10.11.250.0 * 255.255.255.0 U 0 0 0 eth0
10.10.250.0 * 255.255.255.0 U 0 0 0 eth0
10.10.101.0 10.10.250.6 255.255.255.0 UG 20 0 0 eth0
10.10.102.0 10.10.250.6 255.255.255.0 UG 20 0 0 eth0
default 10.10.250.6 0.0.0.0 UG 0 0 0 eth0

It obviously recognizes the alias IP addresses and it even announces them to other ospf systems.

I suspect that you did not in fact try what I said, to put in the network declaration because you did not see the interface as you expected.

As far as I am concerned this is not an issue and this thread is dealt with.

[sir_lunatic]

Thats great news lonnie, i was going to test the same thing on monday.

[lonnie]

Quagga does not see anything. You have to declare all of the subnets in use. If you declare it then OSPF will use it. No declaration and it is not announced.

Well,

This is an issue, and explains some problems we are seeing..
I do have some interfaces with more than one ip, and the reason
we do it, is most of our customers have private ip's, but most
of our businesses use public ips, and some of them refuse to connect their
vpn routers, etc to anything associated with private ip's..
So, our aps may have two ip's on an interface, a public ip subnet for
business customers, and a private for residential..

Remember, not all of these customers are wireless, some are on ethernet
interfaces also..

Has anyone tested this on vlans? if we set an ethernet port up with
multiple vlans, does quagga see all the ip's?


Richard

[bminish]

Brendan,

As far as I am concerned this is not an issue and this thread is dealt with.
It works on ethernet but not atheros

this is from a box with 2 IPs on wpci1 in AP mode
on wpic1 we have
10.30.39.73/29
and
10.30.39.81/30


# s i o i
beacon is down
ifindex 8, MTU 0 bytes, BW 0 Kbit <>
OSPF not enabled on this interface
cbq is down
ifindex 9, MTU 0 bytes, BW 0 Kbit <>
OSPF not enabled on this interface
eth0 is up
ifindex 2, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
Internet Address 10.30.1.66/24, Broadcast 10.30.1.255, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 10.30.3.2, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DROther, Priority 1
Designated Router (ID) 10.30.1.1, Interface Address 10.30.1.1
Backup Designated Router (ID) 10.30.100.13, Interface Address 10.30.1.69
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 4.501s
Neighbor Count is 5, Adjacent neighbor count is 2
eth1 is up
ifindex 3, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,MULTICAST>
OSPF not enabled on this interface
lo is up
ifindex 1, MTU 16436 bytes, BW 0 Kbit <UP,LOOPBACK,RUNNING>
OSPF not enabled on this interface
wifi0 is up
ifindex 5, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
OSPF not enabled on this interface
wifi1 is up
ifindex 7, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
OSPF not enabled on this interface
wpci0 is up
ifindex 4, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
Internet Address 10.30.39.73/29, Broadcast 10.30.39.79, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 10.30.3.2, Network Type NBMA, Cost: 100
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.30.3.2, Interface Address 10.30.39.73
Backup Designated Router (ID) 10.30.39.74, Interface Address 10.30.39.74
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 4.499s
Neighbor Count is 1, Adjacent neighbor count is 1
wpci1 is up
ifindex 6, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
Internet Address 10.30.3.2/24, Broadcast 10.30.3.255, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 10.30.3.2, Network Type NBMA, Cost: 100
Transmit Delay is 1 sec, State Backup, Priority 1
Designated Router (ID) 10.30.0.10, Interface Address 10.30.3.1
Backup Designated Router (ID) 10.30.3.2, Interface Address 10.30.3.2
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 4.500s
Neighbor Count is 1, Adjacent neighbor count is 1

#sh running-config

Current configuration:
!
hostname ktm1
password 1234
!
!
!
interface beacon
!
interface cbq
!
interface eth0
!
interface eth1
!
interface lo
!
interface wifi0
!
interface wifi1
!
interface wpci0
ip ospf network non-broadcast
ip ospf cost 100
!
interface wpci1
ip ospf network non-broadcast
ip ospf cost 100
!
router ospf
redistribute static
network 10.30.0.0/16 area 0.0.0.0
neighbor 10.30.3.1
neighbor 10.30.39.74
neighbor 10.30.39.82
!
access-list vtylist permit 127.0.0.1/32
access-list vtylist deny any
!
line vty
access-class vtylist
!
end




Please tell me why the second interface on wpci1 is not being made aware to Quagga

[lonnie]

You are not doing it right, that is why.

Declare EACH subnet, as I said and demonstrated.

Thus you require:
network 10.30.39.72/29 area 0
network 10.30.39.80/30 area 0

You are hung up on being able to see the interface in Quagga. Accept that it does not, and work around it and declare each subnet that you want it to announce.

Do you have OSPF books I recommended (by Cisco)? My reading of them tells me to do it the way I have recommended.

[lonnie]

Did you try it?

network 10.30.39.72/29 area 0
network 10.30.39.80/30 area 0

I need to know since I would really like to know if my suggestion worked. I know it works on my systems, but I do need to know if it works on yours.

[oscarBravo]

I've been trying to duplicate the problem I saw, and can't do so reliably. At an early point in testing I saw the problem - only one address appeared on the "show ip ospf interface" list, although two were configured. Some time later, both appeared. Now they're both showing whether I use the separate subnet syntax you've suggested, or the aggregated syntax we had used - which is the behaviour I'd expect, since both are valid according to the Cisco docs.

Strange one.