Template for getting a basic Debian VM with python virtualenv and pyenv. Run python3 by default
$ sudo aptitude update
$ sudo aptitude dist-upgrade
$ sudo apt-get install -y python3-pip
$ sudo apt install git
$ sudo adduser --home /home/USER --shell /bin/bash USER
$ sudo usermod -a -G sudo USER
$ vim .bashrc
git clone https://github.com/yyuu/pyenv.git ~/.pyenv
git clone https://github.com/yyuu/pyenv-virtualenvwrapper.git ~/.pyenv/plugins/pyenv-virtualenvwrapper
if [ ! -d "$PYENV_ROOT" ];then
git clone https://github.com/pyenv/pyenv.git ~/.pyenv
if [ ! -d "$PYENV_ROOT/plugins/pyenv-virtualenvwrapper" ]; then
mkdir -p $PYENV_ROOT/plugins
git clone https://github.com/yyuu/pyenv-virtualenvwrapper.git $PYENV_ROOT/plugins/pyenv-virtualenvwrapper
if type "pyenv" &> /dev/null; then
eval "$(pyenv init -)"
# TODO: make the prompt work for python and ruby
if type "python" > /dev/null; then
pyenv_python_version=$(pyenv version | sed -e 's/ .*//')
if pyenv which pip &> /dev/null; then pyenv virtualenvwrapper fi export PS1="py:\$(__pyversion)|$PS1"
$ sudo apt-get install -y --no-install-recommends make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev tcpdump tree
$ pyenv install 3.7.3
$ pyenv global 3.7.3
I had my shiny and tiny GCP network for EVE-NG to test vEOS. I built a new VM (vm2) to be my center for automation so I can test stuff like ansible/napalm/nornir etc… But I couldn’t ping from vm2 to the vEOS instances in eve-ng (vm1). Those instances where in a different network attached to vm1 so it had to “route”.
As usual, I missed one step when I created the EVE-NG VM. The official documentation doesnt mention anything regarding enabling routing in the VM. As I am not used to Cloud environments, I assume that any simple Linux VM can forward traffic if configured.
Surprise Surprise. In GCP (not sure in other cloud providers), you need to enable “forwarding” during the VM creation and you can’t change that afterwards in any way.
After checking the second guide I followed, I realised that guide mentioned the point to enable forwarding to avoid the same problem I was facing…
So I had to gave up and had to build both VMs from scratch….
But at the end, I have routing enabled in both VMs and I can ping to the vEOS images.
And another annoying thing. I couldnt update the next hop in a static route defined in the VPC. So I had to delete it and create again pointing to the new VM with the vEOS.
And dealing with the internal IPs…
Moving on, quite frustrating day. But learned several things about GCP netwoking.
I was reading a chat today, and people were talking about issues with EH. As usual, I didn’t pay attention to the very beginning of the conversation. At the end, after reading the initial link from the conversation, this was all related to IPv6 Extended Headers. And it seems they can cause issues even showed in a rfc7872.
This is the agenda from “NPS/CAIDA 2020 Virtual IPv6 Workshop” last week. And this Geoff Huston’s presentation that started the conversation. And one more link from Geoff about measuring IPv6.
And this is an old issue about IPv6, fragmentation, load balancers, anycast networks that was very interesting to read. IPv6 MTU is 1280.
I don’t have production experience with IPv6 so I try to learn from others. At some point I need to create a proper IPv6 lab with IPv6 services (NTP, DNS, DHPC, HTTPs, etc)