On 5/9/23 14:32, Tom Beecher wrote:
Except you didn't exactly "call out limitations". You simply said :
IS-IS in Quagga and FRR are not yet ready for business, is what I
would
caution.
The reality is that's not true.
And just a few weeks prior, I had given an update about this very issue,
as per attached.
I figured if anyone needed more details (as I'd provided weeks prior),
they'd reach out, like Bryan did.
- You have a specific environment ( FRR on FreeBSD ) that has an issue
with IS-IS.
- You identified the issue in Apr 2020 as related to the size of the
PSNPs being larger than the default BPF packet buffer size :
https://seclists.org/nanog/2020/Apr/238
- Although a solution was provided (
https://seclists.org/nanog/2020/Apr/240 ) , you made an affirmative
choice you didn't want to. ( https://seclists.org/nanog/2020/Apr/241 )
You didn't say "I don't want to adjust net.bpf.bufsize because it
would have negative impacts in my environment, so I need an option in
FRR to adjust the PSNP size." You said "I don't want to."
Ummh, not sure if you need help reading, but my exact words were:
"Probably could - but I'd prefer solutions that don't mess with the
base
system, which ensures long term usability of FRR across future
upgrades."
The implication being that while it might work, it would make
administration of the system onerous and unpredictable, considering we
are dealing with a ton of FreeBSD installations, and not just a single
server.
You, somehow, read my response is me being petulant; which is entirely
your right, of course. But I also won't let you make a false inference
of what my response actually was.
You are of course perfectly free to not make that change, and
perfectly free to gripe that FRR development has not done what you
asked. But it's pretty disingenuous to say that the software isn't
"ready" strictly because of issues in your use case. That doesn't
really help anyone.
I made a statement, I was asked to explain, I did. There was historical
context, even though I can't expect you to file all member's postings to
memory.
But if you want to let yourself get into your feelings, I can't help you
there.
Mark.
--- Begin Message ---
Despite a new release of FRR since my last testing in 2021, IS-IS
appears to be more broken, with no hopes of it getting any attention.
Will drop back to Quagga.
If anyone is successfully using IS-IS on FRR, I'd be keen to hear.
Mark.
On 3/31/23 09:16, Mark Tinka wrote:
Hi all.
I posted the below in 2020 about IS-IS in FRR (7.3, at the time):
https://seclists.org/nanog/2020/Apr/226
I gave up and moved back to Quagga with OSPF.
I decided to try again today, with FRR 8.5, on FreeBSD-13.1-RELEASE-p6.
Things seem to have taken a major step back since then. I can't even
get an adjacency going with a Cisco IOS XE router:
2023/03/31 07:12:01 ISIS: [WDVAD-TY6HY] ISIS-LFA: failed to unregister
RLFA with LDP
2023/03/31 07:12:01 ISIS: [WDVAD-TY6HY] ISIS-LFA: failed to unregister
RLFA with LDP
2023/03/31 07:12:01 ISIS: [WDVAD-TY6HY] ISIS-LFA: failed to unregister
RLFA with LDP
2023/03/31 07:12:01 ISIS: [YDRGH-0DJ94] Opened BPF device /dev/bpf0
2023/03/31 07:12:01 ISIS: [QJWNQ-3FFKM] BPF buffer len = 4096
2023/03/31 07:12:01 ISIS: [V3AHD-XE2Z5] failed to set BPF buffer len
(4096 to 9000)
2023/03/31 07:12:01 ISIS: [W02G1-H56T1] IS-IS bpf: could not transmit
packet on em0: Input/output error
2023/03/31 07:12:01 ISIS: [G7ZA5-AT06A][EC 67108865] ISIS-Adj (1):
Send L2 IIH on em0 failed
2023/03/31 07:12:04 ISIS: [W02G1-H56T1] IS-IS bpf: could not transmit
packet on em0: Input/output error
2023/03/31 07:12:04 ISIS: [G7ZA5-AT06A][EC 67108865] ISIS-Adj (1):
Send L2 IIH on em0 failed
2023/03/31 07:12:07 ISIS: [W02G1-H56T1] IS-IS bpf: could not transmit
packet on em0: Input/output error
2023/03/31 07:12:07 ISIS: [G7ZA5-AT06A][EC 67108865] ISIS-Adj (1):
Send L2 IIH on em0 failed
Thoughts?
Mark.
--- End Message ---
