Page MenuHomeVyOS Platform

Move OSPF and RIP interface configuration under protocols
Closed, ResolvedPublic

Description

The configuration of interface specific parameters for ospf and rip are now located inside the physical interface's sub-config inside interfaces

to ease creation of configuration scripts it's necessary to move configuration of any aspect of a services into it's own hierarchy in for this service protocols (osof|rip) sub-config

Configuration today:

`
interfaces {
    ethernet eth0 {
       ip {
            ospf {
                cost 200
                dead-interval 40
                hello-interval 10
                network broadcast
                priority 0
                retransmit-interval 5
                transmit-delay 1
            }
        }
    }
}

The proposed new configuration is: (interface names and parameters are used as example)

protocols {
    ospf {
        interface eth0 {
            address-family ipv4 {
                /* Configuration moved from the interface */ 
                cost 1000
                dead-interval 40
                hello-interval 10
                network point-to-point
                priority 1
                retransmit-interval 5
                transmit-delay 1   
            }
        }
    }
}

To ease configuration there are also questions about if configuration should be allowed on the main interface level, that overrides config inside the address-family that way you do not need to configure cost and intervals separately for ipv4 and ipv6

example:

protocols {
    ospf {
        interface eth0 {
            cost 1000
            dead-interval 40
            hello-interval 10
            network point-to-point
            priority 1
            retransmit-interval 5
            transmit-delay 1   
            address-family ipv4 { }
            address-family ipv6 {
                dead-interval 200
                hello-interval 50
            }
        }
    }
}

This configuration will create all "global" parameters for both ipv4 and ipv, but for ipv6 hello-interval and dead-interval is overrided.

Also, if the protocols ospf interface eth0 tag-node is created without child nodes values are filled by default values or left unconfigured inside frr

For now the process is not started, feel free to comment and if your'e want a mission, just assign yourself the case.

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Event Timeline

runar created this object in space S1 VyOS Public.

As I see in VyOS 1.4-rolling-202102040221 the OSPF interface configuration is already under protocol section. Looks good.
So next up are ospfv3 and rip.

c-po renamed this task from Move ospf and rip interface configuration under protocols to Move OSPF and RIP interface configuration under protocols.Feb 5 2021, 4:23 PM
c-po changed the task status from Open to In progress.
c-po triaged this task as Normal priority.
c-po edited projects, added VyOS 1.4 Sagitta; removed VyOS 1.3 Equuleus.
c-po set Is it a breaking change? to Unspecified (possibly destroys the router).
c-po claimed this task.

rVYOSONEX47261d051759: bgp: evpn: T1513: VNI rt and rd are only supported under EVPN VRF.

Can i ask why this is being enforced in this way, this breaks L2 EVPN VXLAN when you need to inject a specific vlan:vxlan mapping into the fabric. I don't see the reason it needs to be forced into a VRF.

Hi @SIN3R6Y,

any idea about an alternative CLI? This is beta functionality in VyOS 1.4 and we can change it arround

In T1513#108669, @c-po wrote:

Hi @SIN3R6Y,

any idea about an alternative CLI? This is beta functionality in VyOS 1.4 and we can change it arround

Do we know the conditions in which FRR requires this? For example this works fine in vtysh when not using any VRF's on current nightly iso.

address-family l2vpn evpn
 neighbor EVPN activate
 advertise-all-vni
 vni 20512
  rd 192.168.0.2:512
  route-target import 512:20512
  route-target export 512:20512
 exit-vni
exit-address-family

I don't mind experimenting and coming up with something, i'm just at a loss as to why this is required in the first place.

I do know that "advertise-default-gw" will generate this error if it is defined before "vni" or "advertise-all-vni"

Also, not sure, but this may be relevant. https://github.com/FRRouting/frr/issues/6112

Unfortunately there are a few EVPN misnomers in FRR as of current. "advertise-all-vni" is not an optional flag. That setting really means "enable evpn" as it sits currently. There is no option to selectively advertise only specific vni's. (aside from vxlan interfaces with a predefined source / destination address, those will not advertise) It's all or nothing, you can however override the RD/RT later on, as i am doing in that example.

EVPN can also only be enabled in one VRF at any given time, and it is for the moment assumed that it's the default vrf.

https://github.com/FRRouting/frr/issues/9405

https://github.com/FRRouting/frr/issues/8994

As for how to prevent invalid configs.

  1. I think i would force "advertise-vni-all", or check if it's defined, if not don't apply EVPN config at all.
  1. Only allow EVPN config in the default VRF, or at least allow only a single VRF. (even though this is currently broken in FRR)
  1. If any L3 commands are specified such as "advertise-defualt-gw", make sure they are applied last. Also will likely have to check to ensure at least one VXLAN tunnel is up as i believe these will fail to apply if not (will have to double check that is still the case).

or alternatively just revert the previous commit as it breaks functionality, and maybe issue a warning about invalid configs until FRR has EVPN more set in stone.

Let me know if there is a preference, i can submit a PR. I just don't really think there is a clean way of preventing invalid configuration entirely with EVPN still being a moving target in FRR, however some of these things can help prevent it.