RFC: Cisco HDLC bridging

RFC: Cisco HDLC bridging

[Eble, Dan]

Greetings network geeks,

I am about to implement Ethernet/802.3 over Cisco HDLC.  My plan is to
enhance hdlc_cisco.c to provide a new ethernet-like device, "cbeX"
(cisco-bridged ethernet), corresponding to the existing "hdlcX" device that
encapsulates the ethernet frames.  The "cbeX" device will suddenly appear
when "sethdlc hdlcX cisco ..." is run, and disappear when "hdlcX" is taken
out of Cisco mode.

Using a separate device for the bridged frames provides a way to get
ethernet-like behavior without obscuring the Cisco nature of "hdlcX".  For
example, a tcpdump of "hdlcX" would still show SLARP keepalive frames and
other ciscoey stuff.

I had also considered simply making "hdlcX" look like an ethernet device,
and "preserving" the SLARP packets for tcpdump by prepending a phony
ethernet header.  I abandoned that design because I could not find an
appropriate ethertype to mark such packets.  (It has other drawbacks too,
but at least it would be simple.)

Comments, suggestions, and warnings are welcome.

-- 
Dan Eble <dane@aiinet.com>  _____  .
Software Engineer          |  _  |/|
Applied Innovation Inc.    | |_| | |
http://www.aiinet.com/     |__/|_|_|

Re: RFC: Cisco HDLC bridging

[Krzysztof Halasa]

"Eble, Dan" <DanE@aiinet.com> writes:

> I am about to implement Ethernet/802.3 over Cisco HDLC.  My plan is to
> enhance hdlc_cisco.c to provide a new ethernet-like device, "cbeX"
> (cisco-bridged ethernet),

I would rather call it "hdlcXsomething", "cbeX" would not be very
obvious to newcomers. And I would make it conditional (for example,
with CONFIG_ option _and_ runtime ioctl creating the slave device).

> corresponding to the existing "hdlcX" device that
> encapsulates the ethernet frames.  The "cbeX" device will suddenly appear
> when "sethdlc hdlcX cisco ..." is run, and disappear when "hdlcX" is taken
> out of Cisco mode.

How are the packets encapsulated? What about 802.1q VLANs?

> Using a separate device for the bridged frames provides a way to get
> ethernet-like behavior without obscuring the Cisco nature of "hdlcX".  For
> example, a tcpdump of "hdlcX" would still show SLARP keepalive frames and
> other ciscoey stuff.

... + Ethernet traffic with Cisco HDLC headers, that's it.

However I don't feel like convinced to use the second network device.
Certainly there is no problem with tcpdump/libpcap, we could have
Cisco hdlcX device with SLARPs, Ethernet framing, regular IPv4/6
and anything we want.

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
at a time.

The same applies to Frame Relay (we have pvcX and ethpvcX).
-- 
Krzysztof Halasa, B*FH

RE: RFC: Cisco HDLC bridging

[Eble, Dan]

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?

> obvious to newcomers. And I would make it conditional (for example,
> with CONFIG_ option _and_ runtime ioctl creating the slave device).

OK.  I will attempt to add CONFIG_HDLC_CISCO_ETH and IF_PROTO_CISCO_ADD_ETH.
IF_PROTO_CISCO_ADD_ETH will return the name of the new device, probably
"hdlcXeth0".

> How are the packets encapsulated? What about 802.1q VLANs?

The packets are put directly into the payload of the Cisco HDLC frame.  The
protocol number in the Cisco header is 0x6558.  I don't remember if the FCS
is included or not.  I expect it is, but that should be obvious when I hook
up to a Cisco device.

I'm not sure about VLAN frames, or about IEEE spanning tree; I plan to treat
them like all other packets until I learn that there is another way.

> However I don't feel like convinced to use the second network device.
> Certainly there is no problem with tcpdump/libpcap, we could have
> Cisco hdlcX device with SLARPs, Ethernet framing, regular IPv4/6
> and anything we want.

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.  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.  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.

> 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?

Re: RFC: Cisco HDLC bridging

[Krzysztof Halasa]

"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

RE: RFC: Cisco HDLC bridging

[Eble, Dan]

> -----Original Message-----
> From: Krzysztof Halasa [mailto:khc@pm.waw.pl] 
> Sent: Wednesday, June 16, 2004 7:14 AM
... 
> 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.

Ah, yes.  But if the device does not have ARPHRD_ETHER the bridge driver
will not allow it to be used as a port.  I do not know what else may require
ARPHRD_ETHER, but I'm not keen to find out by trial and error (and then fix
everything to work with ARPHRD_CISCO too).

> It could be useful - with bridged Ethernet for MS Windows connectivity
> and with routed IP traffic.

When all you have is a hammer, MS Windows looks like a nail. :-)

> I'd go with "2 devices" path for now.

It is going well so far.  I will post patches when I am done, but they
probably will not apply to the current public versions without some extra
work.

This is the sethdlc syntax I have chosen to create and destroy the hdlcXeth0
device:

	sethdlc hdlc0 cisco proto <type> [ enable | disable ]

Where <type> is 0x6558 for bridged ethernet packets (or maybe "ether", but I
have not put that in yet).  I figure this will be useful to enable and
disable other protocols too.
-- 
Dan Eble <dane@aiinet.com>  _____  .
Software Engineer          |  _  |/|
Applied Innovation Inc.    | |_| | |
http://www.aiinet.com/     |__/|_|_|

Re: RFC: Cisco HDLC bridging

[Krzysztof Halasa]

"Eble, Dan" <DanE@aiinet.com> writes:

> Ah, yes.  But if the device does not have ARPHRD_ETHER the bridge driver
> will not allow it to be used as a port.

Correct. And while we can "fix" the bridge and other things, it's
still not enough.

> This is the sethdlc syntax I have chosen to create and destroy the hdlcXeth0
> device:
>
> 	sethdlc hdlc0 cisco proto <type> [ enable | disable ]
>
> Where <type> is 0x6558 for bridged ethernet packets (or maybe "ether", but I
> have not put that in yet).  I figure this will be useful to enable and
> disable other protocols too.

Ok. I'd prefer "ether", though.
-- 
Krzysztof Halasa, B*FH