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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).