Did this test again, and I got the same result.

@c-po, while I don't wish to put words in the mouths of others, I believe the belief is that the interface should stay oper-down.

Good news for the backport into Sagitta, it works :)

Are we going to just let EVPN be the L2VPN technology of choice and not go down the VPWS/VPLS route for L2VPN? EVPN is the future anyway, so going and adding VPWS/VPLS is kind of doing legacy work.

Put in the PR for this at https://github.com/vyos/vyos-1x/pull/2780

Added PR for documentation here https://github.com/vyos/vyos-documentation/pull/1169

Added PR here https://github.com/vyos/vyos-1x/pull/2263

Under normal operations the VyOS box looks like this for OSPF:

I was able to test this for ISIS. I'll test OSPF hopefully tomorrow.

Added initial implementation here:

OSPF and ISIS segment routing should now have been successfully refactored...at least for now.

Adding PR to fix OSPF opaque LSA and rfc 1583 compatibility to the OSPF FRR Jinja2 template.

We figured out the problem. So for OSPF segment routing to work we need to enable opaque LSA capabilities. So by default VyOS doesn't have opaque LSAs (type 9, type 10, type 11) enabled. So after checking the configuration for the OSPF FRR template I noticed that the actual command to enable opaque LSAs is broken because it's not in the OSPF FRR template. Once we fix that, we'll have working OSPF segment routing.

One miracle at a time :)

I am finding out, it seems OSPF SR doesn't work properly :(

Here is ISIS segment routing working:

Put in hopefully the last PR for this here, https://github.com/vyos/vyos-1x/pull/1595

Added PR for this here, https://github.com/vyos/vyos-1x/pull/1574

I closed the other PR, and put in https://github.com/vyos/vyos-1x/pull/1572.

Initial PR here, https://github.com/vyos/vyos-1x/pull/1551.

It seems we have working ISIS segment routing:

Added a new pull request to make ISIS segment routing work again.

It seems that we have two constraints here.

Made a fix and now we have:

Let me see if I can fix it.

Doing further testing, it seems adding the explicit-null broke the configuration:

Good news. It seems the patch worked properly. Here we show MPLS labels generated via segment routing for the prefix command:

Added a pull request for this fix.

Put in pull request https://github.com/vyos/vyos-1x/pull/1423

I wanted to ask you guys if this is an appropriate change to make. Considering it's on BGP, it's going to be a change in a crucial part but I think this one is probably a good one to make just to reduce ambiguity.

@c-po, lets run with "system-as"

@Viacheslav, hmmm, yeah that's a good point. I'll see what I can do to add the OP configs. I know I added the conf configs.

Now that's......different.

Did more checks.....and noticed it *IS* properly sending the ping command:

Made the change to "do" and I noticed that.....DF is used even if there is no DF bit explicitly set...:

It seems the man page that I looked at I either didn't read carefully enough, or I completely messed it up. You're right @Viacheslav.

Did a quick test...

Hmmmm....it worked last time. I'll give it another run.

Put in a PR for this....

@Scoopta, thank you. That's good. I *think* know how the logic should go. Shouldn't be difficult but I'll consult with @Viacheslav and @c-po on how we should tackle it. It shouldn't be hard, but I want to make sure I properly do it :)

@Viacheslav, @c-po, the ISIS FRR Jinja2 template is significantly different between 1.3 and 1.4. Should I try to make the change on 1.3 and then merge? Or should I make it on 1.4 and we'll find a way to merge it back into 1.3?

@Viacheslav, @Scoopta, I take it for default originate on IPv6 there's a requirement to have "ipv6 router isis" added on the interface? I'm thinking yes. If it's a yes (which I'm thinking it is) then I believe this should be fairly easy to add. I'll give it a check guys.

Added PR:

@fernando, this was something I was looking into adding but it'll be in 1.4 One day.....I hope soonish....maybe in a few months.

Will be adding the BGP op commands for it as well eventually...

I put in a PR for this:

FRR coder Donald Sharp kicked ass and fixed it here...

I have successfully added a *ton* of address families in my build. I will PR it, but we also have found an error. The error that we have found is an FRR error at this link here.

@c-po, using a value of "0" for use inbound packet would actually be the best behavior if we can specify/use that.

I know my opinion is....really not that important but I would *highly* recommend going to maximum TTL of 255 or at minimum 127. TTL is a very hard thing to troubleshoot most of the time and therefore it's almost never worth going lower than maximum for IP TTL.

Put in a PR for this, https://github.com/vyos/vyos-1x/pull/744

Here is some more testing. Currently on FRR 7.5:

I *think* that there was a fix that happened on a task somewhere by someone in the underlying operating system that happened to fix this problem, but I for the life of me don't know what/where it would be. I'll have to ask around on it as I think there was changes on it 100% certain. The reason is is because I *saw* this problem too on a very old install too but it went away very quickly and I made no changes to fix it.

Just curious.

Hmmm...I am still not able to replicate...

I think we have a workable solution to this.

I can say that after testing here's what I found.

Put in a PR for this request.

In T915#83668, @daniil wrote:

In T915#81521, @Cheeze_It wrote:

See if you can get absolute latest and see if it works...

net.mpls.conf.X.input variable is not set after reboot.

I'd personally recommend "pmtu-discovery-disable", but either would be fine.

Put PR for segment routing addition:

@drac, while yes that is an option I am unsure which VyOS should as a software package should use.

So, this option can be disabled here per the FRR manual:

This is due to RFC 8212, which was added on FRR 7.4. Please see here...

I am wondering if these are Zebra errors as they *seem* like Zebra errors.

Put in PR for op commands: