Skip to main content

Posts

Showing posts from 2020

Loadbalancing on Static Routes

If you have two routers / two Layer3 switches connected with two L3 links (two paths) you can route with two equal static routes towards the same prefix and the router will load balance traffic across both links. The idea is to make two same static routes on the same router but with different next-hops. The question was: Which link or which route will be used? And if the traffic will be load balanced, which mechanism will be used to share the traffic across both of links. ip route 10.0.0.0 255.0.0.0 192.168.10.2 ip route 10.0.0.0 255.0.0.0 192.168.11.2 If both routes have the same destination prefix and no different Administrative Distance is configured, both routes will get installed in the routing table. Routing table will then leave to the switching process the job of load-sharing. That is, route-cache mechanisms, CEF in case of Cisco device will do load-share per session using source-destination IP. MORE ABOUT THAT CEF Load-Balancing Overview CEF – Cisco Express Fo

Know about Route Recursion

We are going back to networking basics with this post. In few lines below you will find most important theory that makes network gear do its job. The main router job is to making routing decisions to be able to route packets toward their destination. Sometimes that includes recursive lookup of routing table if the next-hop value is not available via connected interface. ROUTING DECISION ON END DEVICES Lets have a look at routing decision that happens if we presume that we have a PC connected on our Ethernet network. If one device wants to send a packet to another device, it first needs to find an answer to these questions: Is maybe the destination IP address chunk of local subnet IP range? If that is true, packet will be forwarded to the neighbour device using Layer 2 in the ARP example below. If that is not the case, does the device network card configuration include a router address through which that destination can be reached? (default gateway) Device then look

Destination IP Address of DHCP

When DHCP starts the client has no idea about the network it’s currently on. Some clients may store the IP address they were previously on and send this out with the Discovery and Request packets, but the network is not truly set up until after the server has sent it’s final Ack message. Because of this the server does not know the network’s true broadcast address, however there is an address mapped for this very purpose. 255.255.255.255 If you run arp -a you will see that every interface has the following mapping 255.255.255.255 ff-ff-ff-ff-ff-ff static This means that just like a networks broadcast IP this message will be transmitted to all network adapters on the local network segment. The DHCP server listens for messages heading for port 67 UDP while the DHCP client listens for messages on port 68 UDP Lets lake a look at a DORA sequence in Wireshark 148 16.564069 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0xaccba128 149 16.5

How Virtual Port Channel Avoid Duplicate Frames

How Virtual Port Channel Avoid Duplicate Frames There is one critical rule with vPC.  If a member port receives a frame, it is forwarded across the peer-link. When the peer switch receives it, it will not forward the frame out a vPC member port . Why does this happen? Have a look at the diagram below. Frames received on a member port, then forwarded across the peer-link, will not be forwarded out another member port There are two servers connected by vPC member ports. Server-1 sends a frame to Server-2. The traffic flows like this: 1.        The frame travels up the link from Server-1 to Peer-1 2.        Peer-1 forwards the frame down the link to Server-2 3.        Peer-1 also forwards the frame across the peer-link to Peer-2 4.        Peer-2 sees that the frame came from a vPC member port, and refuses to forward it to Server-2 So, why does Peer-2 drop the frame? Peer-1 has already delivered it. If Peer-2 also tried to deliver the frame, server-2 would receive a

PACKET FLOW IN THE FIREWALL

PACKET FLOW IN THE FIREWALL: There are some common patterns that the Firewall vendors follow and this whitepaper helps to understand how the packet flow in the firewall. The Firewall Maintains the two paths, one is SLOW Path and the Other is Fast Path. Once the Firewall unit external interface receives a packet it first checks is the packet relate to the existing session, if the packet belongs to the existing session then it enters into the fast path or else it first sends the packet to the slow path to identify some parameters and to allocate the new session from the free pool. Below are the Steps the Firewall will follow to allocate the new session in the SLOW Path and to Enter into the Fast Path: Once the Firewall unit external interface receives a packet, the packet proceeds through a number of steps on its way to the internal interface, traversing each of the inspection types, depending on the security policy and security profile configuration. The diagram below i

IPV6 Configuration on Cisco Router:

IPV6 Configuration on Cisco Router:             By default Cisco Router was enabled with only IPv4 traffic we have to give the command "ipv6 unicast-routing" on the cisco router to enable IPv6 traffic in the Cisco router. R1(config)#ipv6 unicast-routing Next configure the IPv6 address on the Interface as shown in below. R1(config)#int Gi0/0 R1(config-if)#ipv6 address 2001:0BB9:AABB:1234::1024/64 Configure the IPv6  global unicast address on an interface using the ipv6 address address/prefix-length [eui-64] command. If you omit omit the eui-64 parameter, you will need to configure the entire address manually. After you enter this command, the link local address will be automatically derived.  or R1(config-if)#ipv6 address 2001:0BB9:AABB:1234::/64 eui-64 To verify with the show command : show ipv6 int gi0/0 R1#show ipv6 interface Gi0/0 GigabitEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::201:42FF:FE65:3E01 No Virtu

UPGRADING EOS in the ARISTA Switches

UPGRADING EOS in the ARISTA Switches: EOS is the Firmware for Arista Switches whereas IOS for Cisco. This blog post shows the detailed procedures to follow and to upgrade the EOS in the Arista Switches. This Post was supports for any platform or the Version you are going to upgrade in the Arista Switches. This Post was divided into three parts : Pre-Upgrade Process Upgrade Process Post-Upgrade Process PRE-UPGRADING-PROCESS: 1       1)        Check the Upgrade Path tool by clicking the below link. https://www.arista.com/en/support/mlag-portal/mlaglist and confirm it is in mlag issu compatible 2)       Check if the  STP agent is restartable by giving the command switch-1# show spanning-tree bridge detail | grep agent Stp agent restartable                      :            True NOTE :    A switch can continue supporting MLAG when its peer is offline if the STP agent is restartable. When one peer is offline, data traffic flows from the devices through the