{"id":6776,"date":"2026-05-14T03:56:42","date_gmt":"2026-05-14T03:56:42","guid":{"rendered":"https:\/\/technobabble.us.to\/?p=6776"},"modified":"2026-05-14T07:31:50","modified_gmt":"2026-05-14T07:31:50","slug":"evpn-vxlan-on-sonic-virtually-via-eve-ng","status":"publish","type":"post","link":"https:\/\/technobabble.us.to\/?p=6776","title":{"rendered":"EVPN-VXLAN on SONiC virtually via EVE-NG"},"content":{"rendered":"\n

I’ve been focused heavily on network automation and hardware during my last 5 years working at eBay & Celestica so I wanted to get back to my networking roots and dig into a protocol that I don’t have much experience with. Lucky for me SONiC offers virtual images<\/a> that can be run on network emulators like EVE-NG.<\/p>\n\n\n\n

I’m running my instance of EVE-NG inside of a VM on ProxMox, but it can also be setup on bare metal. I’m rocking a new Minisforum MS-A2<\/a> with 128GB DDR5 memory with an AMD Ryzen 9 9955HX, so the hypervisor overhead in minimal in my case.<\/p>\n\n\n\n

Once you get the image downloaded, then it just needs to be unzipped, renamed and uploaded to EVE-NG, there is no need to convert the image or do anything special. Once it’s been uploaded and added to a template you can uses these images over and over for various labs.<\/p>\n\n\n\n

\n
\"\"<\/a><\/figure>\n<\/figure>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/figure>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/figure>\n\n\n\n

Moving onto the actual configurations, there were several SONiC issues I had to work out. I did not go to bed until 4am, hence the blog post, to try and save anyone else from needless pain. <\/p>\n\n\n\n

Let’s start with the diagram above, specifically the port numbering. What I found, on two different virtual images was that you want to avoid using Ethernet0 when connecting everything. The reason being when you run LLDP you will keep seeing references to eth0, also all of the neighbors looked funny. <\/p>\n\n\n\n

When I had everything connected via Ethernet0 I was not able to ping a directly connected link! Through some trial and error I saw the issue and then reconnected everything like you see above. Now the crazy thing is when you configure the interfaces in SONiC, you will be configuring Ethernet0 for the wire that is Ethernet1. <\/p>\n\n\n\n

Here is an example of the issue<\/strong>, Links in EVE-NG are Ethernet1<\/em> & Ethernet2<\/em><\/strong><\/p>\n\n\n\n

\n
\"\"<\/a><\/figure>\n<\/figure>\n\n\n\n

Once again, I saw this issue in our Celestica image, as well as the image I downloaded from Azure. This caused a lot of confusion when I was copy and pasting configs. You might also notice that Ethernet2 actually maps to Ethernet4…….fun times…….now you know! <\/p>\n\n\n\n

The next bit of fun was trying to find an image that supported all the config options I needed for my lab, unfortunately I wasted several hours with our Celestica image that forced you to use sonic-cli with missing options for EVPN-VXLAN, there was no way to enter vtysh mode on this image. <\/p>\n\n\n\n

Once I downloaded a 202511 image from Azure, I was able to enter VTYSH mode and configure BGP with all the advanced options. This led to the next bit of fun where I would constantly lose my BGP configs when the switch was rebooted! <\/p>\n\n\n\n

With SONiC, there are a lot of ways to configure things, too many ways if I’m being honest! Then there is the whole sonic-cli thing, and frr-mgmt-framework, which attempts to keep everything unified and Cisco like. I personally hate this but then learned all the GNMI, YANG, & REST stuff is all tied into this. <\/p>\n\n\n\n

However, for a lab, that stuff is all overkill. All I need is a simple config_db.json file paired with a BGP config file (frr.conf) that I manage and that will not get borked when rebooting. The magic that makes this happen is “split-unified<\/strong>“. <\/p>\n\n\n

\nadmin@spine-1:~$ sudo cat \/etc\/sonic\/config_db.json | jq ".DEVICE_METADATA"\n{\n  "localhost": {\n    "buffer_model": "traditional",\n    "default_bgp_status": "up",\n    "default_pfcwd_status": "disable",\n    "docker_routing_config_mode": "split-unified",\n    "hostname": "spine-1",\n    "hwsku": "Force10-S6000",\n    "mac": "22:1c:31:5e:21:7c",\n    "platform": "x86_64-kvm_x86_64-r0",\n    "timezone": "UTC",\n    "type": "LeafRouter"\n  }\n}\n<\/pre><\/div>\n\n\n
You also need to pair that config change with a change to vtysh.conf<\/em>      <\/p>\n\n\n
\nservice integrated-vtysh-config"\n<\/pre><\/div>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/figure>\n\n\n\n
what you now have is a simple way to manage your BGP configuration separate from your config_db.json file. More importantly, this file frr.conf file will persist across reboots!<\/p>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/figure>\n\n\n\n
There is also no need for any of the other files that you normally find in this location, zerba, bgpd, ospf, static, etc. With this change, none of those are needed, you can delete them as I have. You can even have static route info in your frr.conf file. <\/p>\n\n\n\n
Key Aspects of split-unified<\/code> Mode:<\/strong><\/p>\n\n\n\n