From: Krzysztof Halasa <khc@pm.waw.pl>
To: "Eble, Dan" <DanE@aiinet.com>
Cc: "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: Re: RFC: Cisco HDLC bridging
Date: Wed, 16 Jun 2004 13:13:44 +0200 [thread overview]
Message-ID: <m3llinn4bb.fsf@defiant.pm.waw.pl> (raw)
In-Reply-To: <C060DFCD9697A842B3189B458524FDC205D2C6@AIMAIL1.ai.aiinet.com> (Dan Eble's message of "Mon, 14 Jun 2004 09:40:23 -0400")
"Eble, Dan" <DanE@aiinet.com> writes:
> Krzysztof, I thought you had dropped off the face of the earth. Good to
> hear from you again. Did you ever see my changes to make the HDLC generic
> layer use the PPP generic layer instead of syncppp.c?
Not sure. Do you have a copy?
> I thought tcpdump/libpcap only looked at the device type, so that if we sent
> non-eth packets up an eth interface, tcpdump would try to interpret them as
> eth packets.
Sure. But we won't - with device type = Cisco HDLC tcpdump will be happy.
I.e. will happily print SLARPs, regular IP frames, and Ethernet frames.
Looks like it doesn't support it yet:
switch (proto) {
case ETHERTYPE_IP:
case ETHERTYPE_IPV6:
case CHDLC_TYPE_SLARP:
case CHDLC_TYPE_CDP:
case ETHERTYPE_MPLS:
case ETHERTYPE_MPLS_MULTI:
case ETHERTYPE_ISO:
but I can't see a problem with adding it, given the kernel code is
confirmed working so I can test it.
Note it's irrelevant to single hdlcX vs hdlcX + hdlcXeth0 issue, it
has to be done anyway.
> My primary reason for wanting a second device is to be sure
> not to discard information that is helpful/necessary for troubleshooting;
> so, if receiving packets with diverse header types is not going to mess
> things up, I would definitely prefer using only one device, because it is
> simpler to configure.
Receive side is definitely not a problem. Transmit side is and I think
we need two devices, at least for now.
> The case of using a Cisco HDLC link for bridged
> ethernet *and* IP *and* other things at the same time does not seem very
> useful.
But it's more elegant solution I think (the same would apply to FR PVCs).
It could be useful - with bridged Ethernet for MS Windows connectivity
and with routed IP traffic.
>> The only problem I can see (a serious one, though) is the protocol
>> "routing" in Linux. If we "ip addr add" IP address to hdlcX, does
>> it mean we want native IP or IP/Ethernet? It would be nice to be able
>> to:
>> ifconfig hdlc0 10.0.0.1/24 hw cisco-hdlc
>> ifconfig hdlc0 10.0.1.1/24 hw ether
>
> We could just use "sethdlc hdlc0 cisco-eth" and not worry about
> distinguishing in ifconfig, right?
Sure, but that wouldn't be "at a time".
I'd go with "2 devices" path for now. Long-term I'm going to investigate
"1 device" possibility. This depends on my future job = time I can
find for it, as my current contract ends by Sep, 1 and I'll be seeking
a new one (hope I'll have more time for Linux works than now).
--
Krzysztof Halasa, B*FH
next prev parent reply other threads:[~2004-06-16 11:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-14 13:40 RFC: Cisco HDLC bridging Eble, Dan
2004-06-16 11:13 ` Krzysztof Halasa [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-06-16 12:58 Eble, Dan
2004-06-16 22:49 ` Krzysztof Halasa
2004-06-11 13:01 Eble, Dan
2004-06-11 21:29 ` Krzysztof Halasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3llinn4bb.fsf@defiant.pm.waw.pl \
--to=khc@pm.waw.pl \
--cc=DanE@aiinet.com \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.