------Origineel bericht------
Van: sampsa at mac.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] Auto-booting a MicroVAX 3400
Verzonden: 13 december 2012 21:48
I've just been donated (by Saku Setala) a pair of MicroVAX 3400s.
One of them is set up as a satellite node and boots fine off ESA0 - however, I can't figure out what I need to do to make it automatically boot when powered on - anyone know what switch / console command I need to give to make this happen?
At the moment it starts up to the >>> prompt and if I type boot, it boots happily. I'm just trying to get it to autoboot instead.
sampsa
1.9. Virtual extensible LAN tunneling protocol
Linux adds vxlan, a tunneling protocol that allows to transfer Layer 2 Ethernet packets over UDP. vxlan is often used to tunnel virtual network infrastructure in virtualized environments.
The VXLAN protocol itself, which is a RFC draft right now, is a tunnelling protocol that is designed to solve the problem of limited number of available VLANs (4096). With vxlan the identifier is expanded to 24 bits. The protocol runs over UDP using a single destination port. Unlike most tunnels, a VXLAN is a 1 to N network, not just point to point. A VXLAN device can either dynamically learn the IP address of the other end, in a manner similar to a learning bridge, or the forwarding entries can be configured statically. There is also an implantation of VXLAN for Open vSwitch.
Recommended articles: VXLAN for Linux, Typical VXLAN use case
The links for the recommended articles:
http://linux-network-plumber.blogspot.com.es/2012/09/just-published-linux-k…http://it20.info/2012/05/typical-vxlan-use-case/
I have not (yet) digged into this thing, but it superficially looks as somethig we could use in HECnet.
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
Cisco's Nexus 1000V does VXLAN and it is supported in the free version.
Just FYI. :)
-brian
1.9. Virtual extensible LAN tunneling protocol
Linux adds vxlan, a tunneling protocol that allows to transfer Layer 2 Ethernet packets over UDP. vxlan is often used to tunnel virtual network infrastructure in virtualized environments.
The VXLAN protocol itself, which is a RFC draft right now, is a tunnelling protocol that is designed to solve the problem of limited number of available VLANs (4096). With vxlan the identifier is expanded to 24 bits. The protocol runs over UDP using a single destination port. Unlike most tunnels, a VXLAN is a 1 to N network, not just point to point. A VXLAN device can either dynamically learn the IP address of the other end, in a manner similar to a learning bridge, or the forwarding entries can be configured statically. There is also an implantation of VXLAN for Open vSwitch.
Recommended articles: VXLAN for Linux, Typical VXLAN use case
The links for the recommended articles:
http://linux-network-plumber.blogspot.com.es/2012/09/just-published-linux-k…http://it20.info/2012/05/typical-vxlan-use-case/
I have not (yet) digged into this thing, but it superficially looks as somethig we could use in HECnet.
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
1). UUCP launches dialer
Sort of - there's a script language that looks kinda like a bunch of 'expect' commands
2). Remote system answers
Inshallah.
3). Remote system gives login prompt and UUCP logs in as UUCP (is this what happens?)
Usually if you have multiple users you each has a login name starting with U (this is convention only)
,
4). UUCP on initiating system talks with UUCP's "shell" given after login on remote system.
If you're connecting over port 540 (i.e. uucico is invoked by inetd directly), the receiving system sends an Shere <system name> message to which the sending system sends it's own UUCP name.
Am I missing any (major) steps?
Not that I am aware of.
(Also, UUCP would want to dial would it not? Would it be easier to implement a custom "dialer" that just opens the device in /dev and doesn't send any AT commands, or do some UUCP implementations implement this feature already? The initial test would likely occur between two 4.3BSD instances.)
The "dialling" part is done with scripts - if you just hack it together so the uucico\s just talk to each other, no "dialling" or authentication need to take place.
1). UUCP launches dialer
2). Remote system answers
3). Remote system gives login prompt and UUCP logs in as UUCP (is this what happens?)
4). UUCP on initiating system talks with UUCP's "shell" given after login on remote system.
Am I missing any (major) steps?
(Also, UUCP would want to dial would it not? Would it be easier to implement a custom "dialer" that just opens the device in /dev and doesn't send any AT commands, or do some UUCP implementations implement this feature already? The initial test would likely occur between two 4.3BSD instances.)
Thanks!
Give me 10 minutes to boot a pc, ok?
------Origineel bericht------
Van: sampsa at mac.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] SIMH VAX Win32 binaries with Ethernet
Verzonden: 7 oktober 2012 21:20
Just out of interest, how do I specify the ethernet device (I have no idea how Windows names them) in the ini file?
Sampsa
On 7 Oct 2012, at 22:15, hvlems at zonnet.nl wrote:
Btw IIRC my website offers a precompiled kit: /home.zonnet.nl/hvlems
------Origineel bericht------
Van: sampsa at mac.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] SIMH VAX Win32 binaries with Ethernet
Verzonden: 7 oktober 2012 20:55
Does anyone happen to have a copy of a networking enabled Windows SIMH VAX around?
Sampsa
mentioned, and the DS20L which was an 833MHz processor system in the 1U
size. The DS10L was supported for use with any of the DEC O/S while the
DS20L was only supported for Tru64 from DEC and Linux. VMS was not a
supported O/S, although it was purported to be possible to get it to
boot with some fiddling. Unfortunately, I was never privy to the
details of such.
http://h18002.www1.hp.com/alphaserver/archive/ds20l/http://h18000.www1.hp.com/products/quickspecs/10976_na/10976_na.HTML
Alpha Processors Inc (API) also produced a 1U system. Based on the
DS20L platform, they aimed for the HPC cluster market. Also purported
to be possible to boot VMS with some fiddling, but the usual O/S was
some form of Linux. http://youtu.be/RfowtlIk9Uc
All were fairly noisy for their size. Maybe not noticeable in a
computer center, but definitely in a home setting.
John H. Reinhardt
