On 11/16/15 07:54, Paul Jakma wrote:
>> ping != ARP. The ping utility sends ICMP Echo messages. ICMP (and thus
>> ping) works fine on PPP,
>
> But it won't do anything to speed up any kind of addressing
> resolution/exchange protocol, cause those either run as part of the link
> configuration protocol, or are statically configured, right?
If you have a demand link -- one that's established based on link
activity -- then an ICMP message *may* be detected as activity and cause
an idle link to become active. ("May" because some demand links have
filters to avoid bringing the link up for trivial events -- they can
spoof ICMP Echo sent to the configured remote address and sometimes
spoof TCP keepalive as well. It all depends on how expensive the link
is to keep running, and how smart the system is in avoiding that expense.)
But I can't imagine that running OSPF over a demand link is a wise
choice to make, so it's hard to see how that'd be a real consideration.
In terms of the PPP negotiation, no, that has nothing whatsoever to do
with IP's behavior, including ICMP. PPP runs LCP first, then
authentication (if any), and then IPCP (and IPV6CP) to bring up the
network layer. None of those are IP-based protocols. No IP is involved
on the link until those things are done, and implementations are
required to drop any IP packets silently that may arrive before
negotiation is complete.
So, even if you could send IP before negotiation is done (you can't),
all you could possibly accomplish would be slowing down the work of
bringing the link up.
> I.e. sending pings isn't accomplishing anything for OSPF on such links?
Not much.
At a guess, you might rely on the ping utility's detection of
unreachable addresses. But that seems extremely silly to me, given that
you can do a much better job of exactly that from inside any daemon
capable of running OSPF.
And avoid the nastiness of system(), including overhead and security
concerns.
>> If ARP gets sent on broadcast type media through this mechanism, it's
>> purely by accident. The same accident that you'd trigger by sending a
>> unicast OSPF Hello.
>
> So if this is a useful convergence tweak to OSPF on broadcast
> interfaces, then it should be done as a unicast OSPF packet (e.g.
> Hello), and the tweak described to the OSPF WG so that things like
> conformance suites don't complain (e.g. ANVL - which is why Dinesh told
> me he went with ping instead of an OSPF packet).
Yes, I agree, that's a better way to go. If, in a pinch, you can't send
an innocuous OSPF message because some "conformance" test gets upset,
you can certainly send an ICMP message. But doing so does not require
invoking system().
Surely if you can send IP proto 89 using SOCK_RAW, you can send IP proto
1, right?
Perhaps the interesting part here is receiving errors. But even so, I'd
expected you'd want to receive errors for regular OSPF messages anyway,
so if that's not already being done, it should.
If ARP fails, most OSes will synthesize an ICMP error message locally,
so if ARP failure is the concern, that should help. Of course, that
doesn't help with PPP, and the only things you can do there are [1] look
for the correct IFF_UP|IFF_RUNNING flags and [2] send messages and time
out waiting for a response.
--
James Carlson 42.703N 71.076W <[email protected]>
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
