Changes in 98383c9: Updated IX2.md (markdown)

				services/IX2.md
			
          @@ -12,7 +12,7 @@ how to participate:

           all you have to do is prepare a qcow2 or vmdk image and upload it to somewhere and ping nop-mnt (mc36 @ irc) with the url... i'll wget it once then boot up your vm connected to the switchport... you'll have raw dn42 reachability there and pat-ed clearnet to continue your installation or upgrades or to connect to the rest of your infra...

          -alternatively you can try remotely the ix by preparing the vm image and giving it a vnic pointing to a remote switch participating in the ix already.  "-netdev socket,id=a1,udp=10.10.10.5:1100,localaddr=:1101 -device virtio-net-pci,netdev=a1,mac=as:df:as:df:as:df" 4 example nop-mnt's vpls instance running in a very different datacenter where the real ix located, plus your networking delays to that datacenter, is the sum packet loss, delay, etc... its just about to try out the ix before participating...

          +alternatively you can try remotely the ix by preparing the vm image and giving it a vnic pointing to a remote switch participating in the ix already.  "-netdev socket,id=a1,udp=vpn.nop.hu:998,localaddr=:1234 -device virtio-net-pci,netdev=a1,mac=as:df:as:df:as:df" 4 example nop-mnt's vpls instance running in a very different datacenter where the real ix located, plus your networking delays to that datacenter, is the sum packet loss, delay, etc... its just about to try out the ix before participating...

           once finalized, only one thing to look for twice, the "console=ttyS0,115200n8" be present as a kernel parameter... plus that your only vnic at the real dc will be the above mentioned vpls instance, but now, with a much less delay/jitter/packetlosss.... if you need vnc access instead, just ask for it during the bringup phase....

...	...	@@ -12,7 +12,7 @@ how to participate:
12	12
13	13	all you have to do is prepare a qcow2 or vmdk image and upload it to somewhere and ping nop-mnt (mc36 @ irc) with the url... i'll wget it once then boot up your vm connected to the switchport... you'll have raw dn42 reachability there and pat-ed clearnet to continue your installation or upgrades or to connect to the rest of your infra...
14	14
15		-alternatively you can try remotely the ix by preparing the vm image and giving it a vnic pointing to a remote switch participating in the ix already. "-netdev socket,id=a1,udp=10.10.10.5:1100,localaddr=:1101 -device virtio-net-pci,netdev=a1,mac=as:df:as:df:as:df" 4 example nop-mnt's vpls instance running in a very different datacenter where the real ix located, plus your networking delays to that datacenter, is the sum packet loss, delay, etc... its just about to try out the ix before participating...
	15	+alternatively you can try remotely the ix by preparing the vm image and giving it a vnic pointing to a remote switch participating in the ix already. "-netdev socket,id=a1,udp=vpn.nop.hu:998,localaddr=:1234 -device virtio-net-pci,netdev=a1,mac=as:df:as:df:as:df" 4 example nop-mnt's vpls instance running in a very different datacenter where the real ix located, plus your networking delays to that datacenter, is the sum packet loss, delay, etc... its just about to try out the ix before participating...
16	16
17	17	once finalized, only one thing to look for twice, the "console=ttyS0,115200n8" be present as a kernel parameter... plus that your only vnic at the real dc will be the above mentioned vpls instance, but now, with a much less delay/jitter/packetlosss.... if you need vnc access instead, just ask for it during the bringup phase....
18	18