ospf virtual link not coming up

[Martin Kraus]

Hi.
I'm playing with ospf and got stuck on a virtual link with a cisco router. The
cisco virtual link is up and I can see hello packets coming to the linux
router but nothing going out. It's connected through area 0.0.0.1. I can see
both routers in lsdb.

debug in bird produces following:

OSPF: Received packet for unknown vlink (ID 192.168.70.1, IP 10.5.1.1)

I assume I'm doing something wrong but I can't see what as the config seems
very simple.


bird RID 10.4.7.1:

area 0.0.0.1 {
interface "r2" {
cost 10;
type pointopoint;
neighbors {
10.4.8.2;
};
};
virtual link 192.168.70.1 {
};
};

bird> show ospf interfaces
Virtual link to 192.168.70.1:
Peer IP: 0.0.0.0
Transit area: 0.0.0.1 (1)
Interface: "(none)"
State: down
Priority: 0
Cost: 0
Hello timer: 10
Wait timer: 40
Dead timer: 40
Retransmit timer: 5


bird> show ospf lsadb area 1 type 1

Area 0.0.0.1

Type LS ID Router Age Sequence Checksum
0001 192.168.60.1 192.168.60.1 353 80000008 5485
0001 192.168.70.1 192.168.70.1 232 80000006 b37b
0001 10.4.7.1 10.4.7.1 146 80000019 1312


cisco RID 192.168.70.1:

router ospf 1
area 0.0.0.1 virtual-link 10.4.7.1

R3#show ip ospf virtual-links
Virtual Link OSPF_VL2 to router 10.4.7.1 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 0.0.0.1, via interface FastEthernet0/1, Cost of using 20
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:04


thanks for help
Martin

[Ondrej Zajicek]

Post by Martin Kraus
Hi.
I'm playing with ospf and got stuck on a virtual link with a cisco router. The
cisco virtual link is up and I can see hello packets coming to the linux
router but nothing going out. It's connected through area 0.0.0.1. I can see
both routers in lsdb.
OSPF: Received packet for unknown vlink (ID 192.168.70.1, IP 10.5.1.1)

This is because vlink iface on linux router is down.

Post by Martin Kraus
area 0.0.0.1 {
interface "r2" {
cost 10;
type pointopoint;
neighbors {
10.4.8.2;
};

The config is probably OK. Note that 'neighbors' option is unnecessary
for ptp link.

Post by Martin Kraus
bird> show ospf interfaces
Peer IP: 0.0.0.0
Transit area: 0.0.0.1 (1)
Interface: "(none)"
State: down
Priority: 0
Cost: 0
Hello timer: 10
Wait timer: 40
Dead timer: 40
Retransmit timer: 5

The iface is down so i suppose that router 192.168.70.1 is unreachable
from the linux router. What is the output of 'show ospf state all'?

[Martin Kraus]

Post by Ondrej Zajicek

Post by Martin Kraus
Hi.
I'm playing with ospf and got stuck on a virtual link with a cisco router. The
cisco virtual link is up and I can see hello packets coming to the linux
router but nothing going out. It's connected through area 0.0.0.1. I can see
both routers in lsdb.
OSPF: Received packet for unknown vlink (ID 192.168.70.1, IP 10.5.1.1)

This is because vlink iface on linux router is down.

Post by Martin Kraus
area 0.0.0.1 {
interface "r2" {
cost 10;
type pointopoint;
neighbors {
10.4.8.2;
};

The config is probably OK. Note that 'neighbors' option is unnecessary
for ptp link.

hi.

I managed to get the vlink up. I'm using ptp on a broadcast network to get rid of the DR/BDR
timeout. All the segments are ethernet. I assumed that is a correct way to do it but I might
be wrong. I'm actually using gns3 to do the simulations but that shouldn't
matter.

bird> s o s all

area 0.0.0.0

router 192.168.70.1
distance 20
vlink 10.4.7.1 metric 20
xnetwork 192.168.60.1/32 metric 11
xnetwork 192.168.70.1/32 metric 1
xnetwork 10.4.8.0/28 metric 20
xnetwork 10.5.1.0/28 metric 10
xnetwork 10.5.2.0/28 metric 10
xrouter 10.4.7.1 metric 20

router 10.4.7.1
distance 0
vlink 192.168.70.1 metric 20
stubnet 10.4.7.0/28 metric 10
xnetwork 192.168.60.1/32 metric 11
xnetwork 192.168.70.1/32 metric 21
xnetwork 10.4.8.0/28 metric 10
xnetwork 10.5.1.0/28 metric 20

area 0.0.0.1

router 192.168.60.1
distance 10
router 10.4.7.1 metric 10
network 10.5.1.0/28 metric 10
stubnet 192.168.60.1/32 metric 1
stubnet 10.4.8.0/28 metric 10

router 192.168.70.1
distance 20
network 10.5.1.0/28 metric 10
stubnet 192.168.70.1/32 metric 1
xnetwork 10.5.2.0/28 metric 10
xrouter 10.4.7.1 metric 20

router 10.4.7.1
distance 0
router 192.168.60.1 metric 10
stubnet 10.4.8.0/28 metric 10
xnetwork 10.4.7.0/28 metric 10

network 10.5.1.0/28
dr 192.168.70.1
distance 20
router 192.168.70.1
router 192.168.60.1

other ASBRs

router 10.4.7.1
external 0.0.0.0/0 metric2 10000


10.4.7.1 is running bird. It's connected to 192.168.60.1(R3) and that in turn is
connected to 192.168.70.1(R4).

the vlink is setup between 10.4.8.1 (on RID 10.4.7.1) and 10.5.1.1 (on RID
196.168.70.1)

The way to get the vlink on bird working was to set the ospf between R3 and
R4 to broadcast. Cisco could determine the vlink ip address on the linux box
on the ptp network and when I setup another cisco router in place of 10.4.7.1
I could get the vlink up over the ptp network as well.

How is the peer ip address determined? I don't see it in any of the LSAs.

thanks
Martin

[Ondrej Zajicek]

Post by Martin Kraus
I managed to get the vlink up. I'm using ptp on a broadcast network to get rid of the DR/BDR
timeout. All the segments are ethernet. I assumed that is a correct way to do it but I might
be wrong. I'm actually using gns3 to do the simulations but that shouldn't
matter.

...

Post by Martin Kraus
10.4.7.1 is running bird. It's connected to 192.168.60.1(R3) and that in turn is
connected to 192.168.70.1(R4).
the vlink is setup between 10.4.8.1 (on RID 10.4.7.1) and 10.5.1.1 (on RID
196.168.70.1)
The way to get the vlink on bird working was to set the ospf between R3 and
R4 to broadcast. Cisco could determine the vlink ip address on the linux box
on the ptp network and when I setup another cisco router in place of 10.4.7.1
I could get the vlink up over the ptp network as well.
How is the peer ip address determined? I don't see it in any of the LSAs.

Hello

This is a problematic issue in OSPFv2. IP address of remote vlink
endpoint is determined from an IP address of a link to border router,
which is OK if this is broadcast network, but may not work for ptp
network (where the value may be either IP or a local interface index,
while the local router cannot know what it is). Cisco is probably more
relaxed and just try the value anyway, while BIRD does not deduce IP
address in this case.