- User Since
- Aug 12 2020, 3:52 AM (58 w, 6 d)
Aug 7 2021
Did more checks.....and noticed it *IS* properly sending the ping command:
Aug 5 2021
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.
Jul 25 2021
Put in a PR for this....
Jul 19 2021
@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.
Jun 17 2021
May 22 2021
@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.
Apr 30 2021
Will be adding the BGP op commands for it as well eventually...
Mar 25 2021
I put in a PR for this:
Mar 17 2021
FRR coder Donald Sharp kicked ass and fixed it here...
Mar 14 2021
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.
Mar 5 2021
@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.
Feb 26 2021
Put in a PR for this, https://github.com/vyos/vyos-1x/pull/744
Feb 17 2021
Here is some more testing. Currently on FRR 7.5:
Feb 12 2021
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.
Hmmm...I am still not able to replicate...
Jan 28 2021
I think we have a workable solution to this.
Jan 27 2021
I can say that after testing here's what I found.
Jan 18 2021
Put in a PR for this request.
Jan 14 2021
Jan 4 2021
I'd personally recommend "pmtu-discovery-disable", but either would be fine.
Jan 3 2021
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...
Dec 30 2020
I am wondering if these are Zebra errors as they *seem* like Zebra errors.
Dec 27 2020
Put in PR for op commands:
Dec 22 2020
Put in a PR to add LDP ordered control operation for LDP.
Dec 19 2020
Put in a PR to add op commands for LDP.
Dec 12 2020
Put in a PR to fix spelling/help string error. My bad. I didn't catch it before.
Dec 9 2020
Put in a PR to add documentation for LDP import/export control again. I didn't rebase properly last time. Sorry everyone :(
Put in a PR to add LDP import/export control.
Dec 7 2020
@bbs2web, here's what I got...
@bbs2web, getting this one (https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-202012070521-amd64.iso) and will troubleshoot...
Dec 6 2020
Put in a new PR to enable LDP local label allocation control.
Nov 30 2020
This will be on my list to test here in a little bit. I'm almost done with stuff relating to LDP.
Nov 29 2020
Put in a new PR to enable ethernet sub interface MPLS enablement. I screwed up the first one...but here's hoping this one is good.
Nov 26 2020
Put in a PR to enable ethernet sub interface MPLS enablement
Nov 25 2020
@bbs2web, I figured it out. I know what's not working.
I just did some testing, and @bbs2web, you're right. Sub interfaces to not get enabled. However main interfaces *DO* get enabled.
Try the new rolling by the way. There was a problem initially that we had to fix. Do like the rolling from 11/25 or tomorrow of 11/26.
@bbs2web, yessir, this is a new changed behavior. In the past when you configured an LDP interface it also enabled MPLS on the same interface.
Nov 23 2020
Put in a PR for refactor of LDP template, MPLS python handler, addition of global MPLS parameters (via Linux kernel config changes), and separation of MPLS interfaces from LDP interfaces. *PLEASE* know I did do testing but I want more people to test as well. I have uploaded the package file for this PR here so that people can test my work.
Nov 22 2020
@bbs2web, oh don't you worry. I've had my eyes on it after I get LDP done. I'm almost done with it too.
Nov 10 2020
Put in a PR to add miscellaneous MPLS and LDP parameters.
Nov 8 2020
Put in a PR to add targeted LDP neighbors.
Nov 5 2020
Sure, no worries. We still have a *ton* of work on 7.3.1 to do so I'm sure we'll get to 7.5 in time :)
Not sure if it's relevant or not, but I think 7.5 was released....we might be able to just leapfrog 7.4 and go directly to 7.5 instead.
Nov 4 2020
Put in a PR to add session hold time for static LDP neighbors.
Put in a PR to add TTL security for static LDP neighbors.
Oct 27 2020
Put in a PR to separate hello/hold timers for IPv4 and IPv6. Added IPv6 timers.
Oct 26 2020
I put a request on this up top. We'll get to it eventually, but I was hoping we could put it like this:
Oct 20 2020
Here is the test for the LDP session time change.
Here is the test for Explicit Null.
Everything seems to be good. Closing case.
Submitted second PR
Oct 18 2020
Oct 17 2020
Oct 16 2020
I'll be giving those a test once T2981 is done. I'll report back here with results :)
PR is added here...
Oct 15 2020
Oct 12 2020
The last thing I think we can add is the dual stack capability options. We only got 2.
Ok, so here's the import LDP FEC one that I think we could take advantage of as well.
Ok, so here's the export LDP FEC one that I think we could take advantage of.
The one after that I feel would be fairly easy to also implement is customized label allocation. Again, it is under the family of IPv4 or IPv6.
The next one that I think would be fairly easy to add would be the following:
Hello sir. I am unsure if you're able to add more under LDP but I have found others if you possibly could add. They should be simple additions and are already supported under FRR 7.3.1.
Sep 29 2020
The way I was thinking is on this Juniper page here.
Sep 20 2020
Sep 19 2020
Sep 18 2020
@Viacheslav, I am unsure if you're able to finish the template and/or work on it more but if you guys ever choose to complete it and add it into rolling then I can test it out in my lab.
Sep 13 2020
Not quite sure if this is the right thing to do but, if a "delete protocols ospf" command is given the equivalent in FRR should be "no router ospf".
Sep 1 2020
If you guys want, I can also try to test it out too...
Aug 31 2020
@adestis yes, that is true....but that can be worked around. Any option can be used (either BFD, or ARP, or ICMP). I just wanted to give more ideas so that hopefully can get a working implementation for all 3.
Aug 24 2020
@Viacheslav, when I try that I get the following:
Aug 22 2020
Version of Vyos I have is:
Aug 20 2020
Ok, I got the new version of code and here is what I found. As a baseline here's the Vyos config, and it's more or less the same as before but I moved lab environments:
Aug 19 2020
Would it be reasonable to use BFD for this? Since BFD is already implemented we might be able to use that as well?
I also want to add more verification. I was able to bring up LDP *properly* to a Juniper as well. The one thing I was not able to 100% verify was that the labels themselves were proper from end to end *BUT* the Junipers did properly see the labels and did allocate from Vyos. Vyos itself also did the same. Due to a lack of ability to specify an explicit null I cannot absolutely verify yet, but I hope to be able to in the future. SO far though it seems that you guys have done a good job making sure that the P functionality works, and label allocation works. Well done. I was *ALSO* able to make the MPLS label pop up properly. Please check the very bottom for the verification of it working :)
Aug 12 2020
In theory, service providers use OSPF and ISIS for IGPs. LDP in theory shouldn't really care which protocol is used for the next hop as long as the next hop resolves and the label is there for the next hop for that LSP. Albeit I will admit I am not sure how it is organized in FRR. OSPF and ISIS should both be able to work though for next hops, and they should be consistent.