Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FRR OSPF hello with wrong mask #27

Open
adorne opened this issue Dec 10, 2018 · 2 comments
Open

FRR OSPF hello with wrong mask #27

adorne opened this issue Dec 10, 2018 · 2 comments

Comments

@adorne
Copy link

adorne commented Dec 10, 2018

BSDRP 1.91
It shows GRE interfaces as unnumbered and consequently send "hello" messages by OSPF with 0.0.0.0 mask from an /30 interface. RouterOS on the other side doesn't accept wrong mask "hello" and routing is broken.
There is how it looks like.

system:

[root@n101v01]~# ifconfig tok1
tok1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1330
        options=80000<LINKSTATE>
        tunnel inet ip1 --> ip2
        inet 10.0.0.1 --> 10.0.0.2 netmask 0xfffffffc 
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: gre

FRR cli:

n101v01# show ip ospf interface tok1
tok1 is up
  ifindex 7, MTU 1330 bytes, BW 0 Mbit <UP,POINTOPOINT,RUNNING,MULTICAST>
  This interface is UNNUMBERED, Area 0.0.0.0
  MTU mismatch detection: enabled
  Router ID 10.10.1.1, Network Type POINTOPOINT, Cost: 10
  Transmit Delay is 1 sec, State Point-To-Point, Priority 1
  No backup designated router on this network
  Multicast group memberships: OSPFAllRouters
  Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
    Hello due in 2.719s
  Neighbor Count is 1, Adjacent neighbor count is 1

On the other BSDRP 1.90 system it's all right with masks.

@adorne adorne changed the title FRR hello with wrong mask FRR OSPF hello with wrong mask Dec 10, 2018
@adorne adorne closed this as completed Dec 20, 2018
@adorne adorne reopened this Dec 20, 2018
@deejay2
Copy link

deejay2 commented Jan 31, 2019

Not sure but it may be a FRRouting bug. If you haven't already done it, you could open a similar issue on the FRRouting project so they can sort it out.

@ocochard
Copy link
Owner

I think it is related to this FRR bug: FRRouting/frr#8132

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants