So, we are going to use a different bridge interface, other than pnet0 for the management network. This EVE-NG subnet can optionally be used as a management network in labs, but for my purposes, I wanted to keep the management IPs for EVE-NG nodes in a separate address space from my external GCP lab VMs. "10.128.0.27") that is used for the EVE-NG Web GUI. Furthermore, as depicted below, pnet0 is assigned the IP address (eg. In the context of KVM/QEMU, a Linux bridge is used to connect the KVM/QEMU guest interface to the host network interface.Īs shown in the screenshot above, bridge interface pnet0 is bridged with the primary physical EVE-NG ethernet port eth0. A bridge interface shows up in ifconfig or ip link alongside physical interfaces such as eth0, however they are just virtual interfaces that take packets from one physical interface and transparently routes them to the other interface(s) on the same bridge. If you login to your EVE-NG host machine and issue the ifconfig -s command, you will see these interfaces, as shown in the screenshot below.īy issuing the brctl show command, we can see that these are indeed bridge interfaces ( see screenshot below). Of particular importance are the interfaces named pnet0 through pnet9. Bridge Interfaces Created By EVE-NGĮVE-NG creates several bridge interfaces on the host VM during the installation process. So, with that in mind, in this third blog post of this series, I will walk through a simple approach that worked for me in enabling this bridging between the EVE-NG and GCP network domains. This is very useful in testing and prototyping scenarios. This type of access is not enabled by default and requires a little workaround in both EVE-NG and in GCP in order to make it work.Įnabling this access can be quite powerful, in that the topologies you spin up in EVE-NG can then serve as an extension of the existing infrastructure you might have deployed in GCP. For example, you might want to send Syslog messages to an existing Splunk server in your GCP lab, or perhaps you might want to send streaming telemetry from a Juniper vMX to an existing Telegraf collector that is running on a GCP VM. However, it is very likely that you might want to connect your EVE-NG topology to external VMs that reside in your GCP environment. In Part 2, we looked at how to spin up a simple topology in EVE-NG, consisting of Arista EOS and Juniper vMX routers. In Part 1 of this blog series, we covered the step-by-step procedure for installing EVE-NG ( ) on Google Cloud Platform (GCP).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |