SHARIFUL's TECH BLOG

I always like to work with open source tools. As a network engineer, we need to maintain a device configuration management system where we take backup of configuration for different networking devices like routers, switches, firewalls etc. We want to have our backups ready so that we can restore a device configuration when a device fails or replace with new one or for auditing purpose to track recent configuration changes. Today I will talk about such a open source tools named - Oxidized. Interested readers can have a look at it's GitHub page . It is a network configuration management tool with support for diverse networking equipments. Oxidized is developed with programming language Ruby. It is very configurable, extensible and can be integrated with management tools like Librenms . I will do a two part blog about Oxidized. In this part I will cover basic setup of Oxidized and start taking configuration backup of networking equipments. Network Topology Our topology l

The other day I have an idea that I want to explore for QnQ just out of fun. We all know how QnQ works. In the QnQ termination switch, we configure the switch port which applies the extra vlan tag for QnQ, we configure that port as access port, allow our QnQ vlan as access vlan on the port  and enable QnQ. With the setup above, the QnQ port is in access mode and we can only have that QnQ vlan active on that switch port. But I want to run that switch port in both trunk and QnQ mode, so that I can carry some extra vlan which will not be double vlan tagged with QnQ. Those vlan will pass QnQ enabled switch port with their original vlan tag (with only one and the original vlan tagg applied). May be explained better with some pictures -  I have vlan 11, 12 and 13 which will be double tagged with QnQ vlan 201. And have vlan 101, which will pass the switch port without QnQ just with original vlan tag 101. If we draw a picture it will look below -  Outer Vlan In

In our previous blog post -  Stacking switches Part - V (Cisco Nexus vPC - Virtual Port Channel) , we have looked at how to configure vPC between two nexus switches. But we were at a huge disadvantage - because of the underlying architecture how vPC/MLAG works. With any MLAG implementation, we are still managing two individual switches, they are just facilitating a LACP aggregation link which is spread throughout the vPC peers. And we are configuring the same things twice - one time in each peer of our vPC domain. There is always risk in such setup that we miss some configuration commands in one of the switch and the vPC interfaces does not comes up. Cisco has implemented a feature called switch-profile which allows configuration syncing to all the vPC peer switches. We just configure a profile in both peer switches, make our configuration changes, then NX-OS validates the configuration and pushes it throughout the vPC domain. The good thing with config-sync is that it not only