"Eble, Dan" <DanE@xxxxxxxxxx> 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
|