Awesome Tcpdump Hack for Arista EOS to send to Wireshark

These below commands allow anyone to live stream the packet info to wireshark application on their Mac without having to capture on their device and then copy to mac...

To send tcpdump directly to wireshark:
ssh root@mt701 "tcpdump -s 0 -Un -w - -i vlan100" | wireshark -k -i -

The above command will:

- Tcpdump on the Arista EOS device mt701

- Capture packets of vlan100 (change to your desired interface)

- Pipe the output to Wireshark application on your Mac/Desktop


Tcpdump on a different VRF-"dhcpvrf"
ssh root@mc327 "ip netns exec ns-dhcpvrf tcpdump -i vlan10 port 67 or port 68 " | wireshark -k -i -

The main command telling the VRF info is: "ip netns exec ns-dhcpvrf tcpdump -i vlan2 port 67 or port 68"

The above command will:

- Tcpdump on the Arista EOS device mc327

- Capture packets on VRF "dhcpvrf" (change name to your desired vrf name)

- Capture packets of vlan2 (change to your desired interface)

- Capture packets on Port 67 or Port 68 only

- Pipe the output to Wireshark application on your Mac/Desktop

VLAN Translation

VLAN Translation is used to encapsulate one vlan (doq1q) in another vlan (dot1q)

So, it is also called q-in-q encapsulation

The original vlan is called C-VLAN (customer) and the translated vlan is called S-VLAN (standard-vlan)

To use vlan translation, 2 ways are there:

1. Use vlan mapping both ways .ie.any traffic coming with vlan X will be converted to vlan Y and those with vlan Y will be converted to Vlan X

interface Ethernet14

   switchport mode trunk

   switchport vlan mapping 80 280

   switchport port-security maximum 4

   switchport port-security violation protect log

interface Ethernet16

   switchport trunk native vlan 80

   switchport mode trunk

   switchport vlan mapping 280 80

In above case, any traffic coming with vlan 80 on et14 will be converted to vlan 280. On et16, any traffic coming with vlan 280 will be converted to vlan 80 (both ingressing and egressing)

NOTE: In et14, compulsorily vlan280 must be allowed and on et16, compulsorily vlan 80 must be allowed since vlan translation ahppens very initially in pipeline. So, any traffic with original vlan will be converted to new vlan before any sort of processing happens.

2. Another way is to use only 'in' and 'out' words in the mapping configuration, so that, only incoming or outgoing packets will be translated. Not other way around.

interface Ethernet14

   switchport mode trunk

y

   switchport port-security maximum 4

   switchport port-security violation protect log

interface Ethernet16

   switchport mode trunk

   switchport vlan mapping 280 80

   switchport vlan mapping out 280 80

In this case, on et 14, only incoming packets with vlan 80 will be translated to vlan 280. But, if a vlan 80 packet has to go out from et14,  it will be sent as vlan 80 only. Similarly, on et16, only egressing packets will be translated. So, if vlan 280 packet has to go out from et16, it will be translated to vlan80. But, if a incoming packet with vlan 280 hits et16, it will not be translated.

All about DHCP in a Gist

DHCP in a Gist

• Coming to the history of host auto configuration protocols, there were many protocols before DHCP that were meant to configure clients with minimal user intervention such as Reverse-ARP, BOOTP, etc…

• DHCP is actually a extension of BOOTP mechanism which allows backward compatibility with BOOTP devices.

• There are some differences between DHCP and BOOTP such as DHCP has mechanism to assign leases for a finite amount of time, thus, saving IP addresses.
• Also, there is some terminology differences b/w them such as the dhcp options were called as vendor-extensions in DHCP.
• Another major improvement in DHCP compared to BOOTP was that BOOTP uses 2-phase mechanism and requires additional servers for providing other details like it requires another TFTP server for performing file transfer of boot images, whereas DHCP uses 1-phase boot config and the client negotiates with a DHCP server to determine its IP address and obtain any other initial configuration details it needs for network operation.

DHCP MESSAGES

• The simplistic format of DHCP message looks like this:

• \1. message-type
• \2. hops (client sets as zero, relays increment it)
• \3. transaction-id
• \4. flags —> contains a bit called broadcast bit which helps clients that cannot unicast before getting a IP address get a DHCP exchange successfully
• \5. client-ip addr---> used only after client has already got an IP address during Renew/Rebind message exchange
• \6. si-addr—> server-id, filled by server
• \7. gi-addr —> relay agent IP address is put here if relay is used. If server is in same subnet as client, it will be 0x0 .ie. no relay has sent this message
• \8. cl-id: client mac is put here usually, but, not necessarily since it is considered as opaque field by server….This field is used by server to assign leases and thus, the client also should use the same identifier so that server can recognize it
• \9. file: TFTP server location
• \10. options
• Others are also there like server-hostname, your-Ip address (used by server in advertising Offers) etc…

DHCP PROCESS:

• DHCP Client-server exchange process:

• Client sends a broadcast DHCP Discover message with S-IP: 0 and D-Ip: 255.255.255.255. S-mac: client-mac and D-Mac: ffff:ffff:ffff
• Now, servers present in same broadcast domain will send offers and put the IP address in your-ip-address field of DHCP. This message will be sent as unicast message to client with D-IP as the one which it plans on offering and the D-Mac as the client’s Mac. This behavior depends on the server actually and both unicast and broadcast dest-IP address will work.
• Then, client chooses one of the servers and sends request. This is always sent as a broadcast message so that other servers which were not chosen knows that those Offers were implicitly declined
• Then, the DHCP server first pings for the IP which it plans on assigning so as to confirm that that Ip was not manually assigned to any host. If it passes, it sends a ACK to the client with the configuration parameters as UNICAST. If ping fails, it sends a NAK to client as broadcast

• Other messages in DHCP include:

• DHCP Decline: After server sends a ACK, the client does a G-ARP for the IP. If it fails, client sends a DHCP Decline to server
• DHCP Release: Graceful shutdown- Informing the server of cancelling the lease by the client
• DHCPInform: used by client to only request parameters and not IP addresses.

• There is no explicit DHCP Renew message in v4 and same Request messages are used even for Renew with the fields being set with IP addresses and this will be unicast directly to server-ip

• Now, if the B bit is set in the DHCP DISCOVER of the client, all the above exchange will be using the destination-Ip as broadcast always

• 

• Another thing to note is that DHCP covers variety of scenarios such as different servers offering IPs in different subnets as well as two servers offering IP in same subnet. In the above exchange, the transaction-id set by the client will be the same and even if two messages are received by client from different servers, it will just ignore the later one (ACK- in case of same pools, NAK in case of different pools)

RELAY SCENARIO:

• RELAY SCENARIO:

• Since for DHCP servers to work, we need them in same subnet as the client but this approach is scalable and costly
• So, usually DHCP/BOOTP relays are used to unicast the client’s DHCP messages to the server
• In case relays are used, the giaddr field in the DHCP message will contain the relay agent’s interface on which the client is connected to.
• All replies from server will be sent to this address

• Lease allotment:

• Permanent allotment: Server assigns a lease to client permanently. Done by putting the seconds field as ffff-ffff
• Fixed time allotment: Here client is given a lease time with minimum of 300 sec and the client must periodically renew the lease
• Manual assignment using DHCP- used for getting finer control wherein we configure a IP for each client’s Mac on the server

• DHCP options

• Several DHCP options can be there
• In case the client needs particular parameters from the server, it uses the Parameter Request Option. The client uses this to request for subnet mask, gateway router, renewal time and rebinding time. (The server gives all these info in separate respective options )

• Now, there is another very important Option in DHCP which is the DHCP Option82. Also known as Relay agent Information Option

• This option82 enables a DHCP relay agent to insert information about a client's identity into a DHCP client request being sent to a DHCP server. This option can be used to assist DHCP servers to implement dynamic address policy.
• It is used only between the relay and the server and is deleted before forwarding to the client

DHCP SNOOPING:

• DHCP snooping is a security feature to prevent dhcp-based violations by identifying trusted and untrusted ports and marking only the known server’s port as trusted port and all clients will be untrusted. If any dhcp message that is supposed to be sent only by server comes on untrusted port, those packets are not forwarded. In order for DHCP snooping to work, we need the relay agent to use Option82 and this is done automatically.

• Option82 can contain several sub options. In case of DHCP snooping, the sub options used to identify the client are:

• Circuit-id ——> identifies the link on the relay
• remote-id ——> identifies the relay-agent. We use the relay agent’s mac address as remote-id

Git- Part 5: Branching

Branching: Overview

● Software Branching is a technique used to achieve code isolation.

◆ Release Branches: Used to create a snapshot of the codebase at time of release. To ensure stability and minimize risk, only severe bug fixes are permitted in release branches.

◆ Development Branches

Git-Part 4: Undoing and Discarding Changes

Undoing: Discarding Unstaged Changes

● Scenario:

You edited file(s) but you have not yet staged them ( i.e. git add ).

How do I discard the changes?