Configuring ZTP on Arista EOS

ZTP

• CLIs:
• zerotouch cancel - cancel this time
• zerotouch disable - distable ztp permanently
• bash vi /mnt/flash/zerotouch-config
• DHCPd config:
• see below
• Supported version:
• Fixed - v3.7
• Chassis - v4.10
• If no startup-config the switch will default to ZTP, if not disable ZTP, the switch will not function properly.  
• automatic configuration based on DHCP
• configure all eth and management ports with "no switchport" to allow DHCP
• can use dhcpd on the Linux
• below bootfile can be either config or script

DHCPd config:
option subnet-mask 255.255.255.0
option broadcast-address 192.168.1.255

option routers 192.168.1.1
option domain-name-server 192.168.1.200, 192.168.1.205
option domain-name "gad.net"

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.160 192.168.1.167;
}

host Arista1 {
 option dhcp-client-identifier 00:1c:73:08:91:33;
 fixed-address 192.168.1.170
 option bootfile-name "http://www2.gad.net/config/Arista1-ZTP"
}

ZTP Script:
#!/usr/bin/Cli -p2
enable
copy http://<url>/arista1-startup flash:startup-config
copy http://<url>/EOS-4.9.3.swi flash:
config
boot system flash:EOS-4.9.3.swi

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

Routing Protocols used in Data centers and advantage/disadv of OSPF (Link State) with BGP

• Routing Protocols used in Data centers and advantage/disadv of OSPF (Link State) with BGP:

• Oversubscription:

• Spine Layer must have 1:1 Oversubscription ratio since it becomes non-blocking
• Leaf Layer can have x:1 oversubscription Ratio since one leaf is connected to all the Spines
• NOTE: Oversubscription at the leaf node is controlled by maintaining a ratio of uplinks to downlinks. A 2:1 oversubscription ratio would imply that twice as many ports are used for servers(downlink) than for uplinks.

• Network Design Considerations: The number of spine nodes required for a given design will depend on a few factors including:

• Number of Compute/Storage Racks: All leaf uplinks must be accommodated by the spine nodes depending on the oversubscription ratio at the leaf. For eg, if leaf has 3:1 ratio , then, for 64-port leaf device, 16 links will be uplink and 48 will be connected to servers
• Controlling Fault Domains: Provisions must be made to contain control plane failures to minimize impact on capacity as well as prevent the spread of control plane poisoning.

• Network Protocol Considerations:

• OSPF (Link State IGP):

• Since OSPF generates link state updates for a single event which must be flooded to all the neighbors, the devices must have powerful control plane processors
• Single Pass Spine: it is critical that no single leaf node shall be a transit path for any other leaf node. A link-state IGP can infact introduce momentary leaf-transit scenarios during protocol state-transitions. Such transitive traffic patterns temporarily disrupt our pre- defined oversubscription ratios and can be very hard to characterize given how short-lived these events may be.
• Unnecessary N-Way Routes: Each spine node will have a direct point-to-point interfaces to each leaf node. We expect adjacencies to be established between each spine node and every leaf node. Now consider a scenario where ospf adjacency has not yet been established between spine-1 and leaf-1 or we have a faulty cable between these devices. In this state, spine-1 learns about leaf-1’s host network through every other leaf node.EOS offers a ‘maximum-paths’ feature to limit the number of n-way IGP routes that get installed on a spine device. In smaller deployments where a link-state IGP is adequate, this feature can be used. However, we can prevent n-way routes from being installed altogether by considering an alternative design and routing protocol.

• BGP:

• Consider a design where the spine nodes are configured to be in a single BGP autonomous system while each leaf-node is assigned a unique AS number. The private AS range of 64512-65535 is available for such designs allowing for upto 1023 AS numbers to be assigned within a single pod.
• This approach addresses many of the undesirable side-effects seen in a typical link-state environments. In particular, BGP’s built-in loop suppression capabilities prevent unnecessary control plane churn. With this design, we are able to create a ‘single-pass’ spine, eliminate unnecessary n-way routes and significantly reduce the amount of control plane traffic that would otherwise result when nodes are rebooted or upgraded.
• Also, in BGP, the control plane activity is contant whereas in OSPF there is high control plane activity during link state changes

• Conclusion:

• EOS platforms have powerful control plane architectures and can support both OSPF and BGP topologies very effectively. Although EOS has incorporated additional features to support large OSPF CLOS designs, BGP is better suited to handle large ECMP designs with it’s native loop-suppression and policy framework.

Arista MLAG (Multi Chassis Link Aggregation)

MLAG (Multi Chassis Link Aggregation)

Topology:

        

1. On both switches, ensure that the control plane ACL configuration is compatible with MLAG. These two rules exist in the default-control-plane-acl configuration. You can verify with the command: show ip access-lists default-control-plane-acl

        

2. Create port-channel for the peer-link

1. They can be different number as shown in above picture
2. switch1# config t
   switch1(conf)#interface eth1-2
   switch1(config-if-Et1-2)# channel-group 101 mode active
   switch1(config)# interface port-channel 101
   switch1(config-if-Po101)# switchport mode trunk
3. Similarly, configure on Switch 2 as well with the desired port-channel number
4. Note: It is recommended, for redundancy reasons to use a port-channel. The peer link is recommended to be at least a two port port-channel to avoid having a single point of failure.

3. On both switches, create a VLAN with an unused vlan-id for the MLAG peers to communicate.

1. switch1(conf)#vlan 4094
   switch1(config-vlan-4094)# trunk group mlagpeer
   switch1(config-vlan-4094)# interface port-channel 101
   switch1(config-if-Po101)# switchport trunk group mlagpeer
   switch1(config-if-Po101)# exit
   switch1(conf)#no spanning-tree vlan 4094
2. Use exactly same config on Switch 2
3. Note: The trunk group names for the peer VLAN (mlagpeer in the above example) should be configured to be the same on both switches. In order to successfully establish an MLAG association, the configuration for vlans and vlan trunk groups must be identical
4. Assigning VLAN4094 and Port-Channel10 to trunk group ‘mlagpeer’ prevents VLAN4094 from being carried on any trunk other than Po10. This allows you to safely disable Spanning-Tree on VLAN4094
5. Another option other than using trunk groups is to prune Vlan 4094 from all other Vlans which is cumbersome

4. Configure the SVI for peer-to-peer communication:

1. On Switch 1:

switch1(conf)#int vlan 4094
        switch1(config-if-Vl4094)# ip address 10.0.0.1/30

switch1(config-if-Vl4094)#no autostate

2. On Switch 2:

        switch2(conf)#int vlan 4094
        switch2(config-if-Vl4094)# ip address 10.0.0.2/30

        switch2(config-if-Vl4094)#no autostate

3. Check for connectivity by pinging each other
4. Note: The The local and peer addresses must be located on the same IP address subnet. Autostate should be disabled on the SVI configured as the local interface.

5. Configure the MLAG peering on both the switches:

1. On Switch 1:

switch1(config)#mlag
switch1(config-mlag)#local-interface vlan 4094
switch1(config-mlag)#peer-address 10.0.0.2
switch1(config-mlag)#peer-link port-channel 101
switch1(config-mlag)#domain-id mlag1

2. On Switch 2:

switch2(config)#mlag
switch2(config-mlag)#local-interface vlan 4094
switch2(config-mlag)#peer-address 10.0.0.1
switch2(config-mlag)#peer-link port-channel 201
switch2(config-mlag)#domain-id mlag1

6. Verify MLAG operation:

1. Check if the MLAG is up by running (config)#show mlag and checking if the MLAG STATUS is shown as ACTIVE

---

Troubleshooting: MLAG Status not becoming ACTIVE:

1. Check if the configuration is similar on both the peers: domain-id, vlan, ip address in same subnet, trunk group name.
2. Verify that Spanning tree disabled on Vlan
3. Check if lower layer layers are up and not errDisabled. If yes, then, shut and unshut to bring them up

Troubleshooting: MLAG Status ACTIVE but INCONSISTENT:

1. Use this command to see the inconsistencies: (config)#show mlag config-sanity
2. To check for inconsistencies in MLAG (even though MLAG is active):

1. Check if different Vlans are configured on the peers that allow the MLAG port-channel. (eg: On switch 1, po10 is allowed on Vlan 4094, default, Vlan 2 and Vlan3; whereas on Switch 2 , po10 is allowed on Vlan 4094, default)
2. VLANs must be created on each MLAG peer. The primary MLAG peer does not communicate VLAN information to the secondary. So, Take care to configure VLANs and port settings (Port-specific bridging configuration comes from the switch where the port physically lives. This includes switchport access vlan, switchport mode, trunk allowed vlans, trunk native vlan, and switchport trunk groups) identically on both MLAG peers

3. (config)#show vlan   —> check if other vlans have po10 and also if u can see all peer interfaces as pE
4. Verify if same EOS versions on both the peers

---

7) Configure MLAG Services:

1. Note: The mlag identification number does not have to match the port-channel number
2. Note: The port-channel numbers grouped in an MLAG must match, they cannot be two different values.
3. Note: A port-channel in an MLAG can have multiple members.
4. In short: Port channels configured as an MLAG must have identical port channel numbers. Although the MLAG ID is a distinct parameter from the port channel number, best practices recommend assigning the MLAG ID to match the port channel number. The following example does not follow this convention to emphasize the parameters that are distinct (see that po20 has been used but mlag id is 12...though not recommended).
5. These Switch1 commands bundle Ethernet interfaces 3 and 4 in port channel 20, then associate that port channel with MLAG 12.

        switch1(config)#interface ethernet 3-4

switch1(config-if-et3-4)#channel-group 20 mode active switch1(config-if-et3-4)#interface port-channel 20 switch1(config-if-po20)#mlag 12

switch1(config-if-po20)#exit

switch1(config)#

6. These Switch2 commands bundle Ethernet interfaces 9 and 10 in port channel 15, then associate that port channel with MLAG 12.

1. Note that same mlag id and same port-channel number (for downstream device) [here: mlag 12 and po20] should be used on both the peers

switch2(config)#interface ethernet 9-10 switch2(config-if-et9-10)#channel-group 15 mode active switch2(config-if-et9-10)#interface port-channel 20 switch2(config-if-po20)#mlag 12

switch2(config-if-po20)#exit

switch2(config)#

7. These commands configure the port channels that attach to the MLAG on network attached device:

1. Note that on the device, there is no MLAG specific configuration. It is configured as a regular port channel

NAD(config)#interface ethernet 1-4

NAD(config-if-Et1-4)#channel-group 1 mode active

NAD(config-if-Et1-4)#exit

NAD(config)#

---

• FOR ADVANCED TOPOLOGY CONFIGURATION, see the EOS Config Manual (there is an example in that with full config)
• FOR more details on MLAG, see EOS Config Manual
• To view any syslog messages, you will need to change MLAG level to debugging: Switch(config)# logging level mlag 7
• Troubleshooting and Debugging Mlag- Useful commands:

• Show mlag detail
• Show mlag interface detail
• Show mlag tunnel counter detail
• Show lacp nei
• Show lldp nei
• Trace commands
• Cd /var/log/messages
• Cd /var/log/agents

Arista Command CAPI/ eAPI

        Arista Command eAPI (CAPI) 

• The Arista Command API is a simple and complete API that allows you to configure and monitor your Arista switches.
• Once the API is enabled, the switch accepts commands using the industry standard CLI syntax, and responds with machine readable output and errors serialized in JSON, served over HTTP.

CONFIGURING CAPI:

• It is very easy to configure eAPI
• Although disabled by default, it is very simple to get the Command API server running on your switch.
• bash$ ssh username@myswitch
    Password: <passw0rd>
    myswitch> enable
    myswitch# configure terminal
    myswitch(config)# management api http-commands
    myswitch(config-mgmt-api-http-cmds)# no shutdown
    myswitch(config-mgmt-api-http-cmds)# show management api http-commands
    Enabled:            Yes
    HTTPS server:       running, set to use port 443
    HTTP server:        shutdown, set to use port 80
    Local HTTP server:  shutdown, no authentication, set to use port 8080
    Unix Socket server: shutdown, no authentication
    VRF:                default
    …
• This enables eAPI only for HTTPS. For using HTTP, switch to it as shown below:

• From configure mode, enter management api http-commands mode. In this submode, you can turn on or off the server by typing [no] shutdown, switch between accepting HTTP or HTTPS traffic via [no] protocol http[s], and adjust the ports the server should listen on using protocol http[s] port <portNumber>.
•   myswitch> enable
   myswitch# configure terminal
   myswitch(config)# management api http-commands
   myswitch(config-mgmt-api-http-cmds)# [no] shutdown
   myswitch(config-mgmt-api-http-cmds)# [no] protocol https [port <portNumber>]
   myswitch(config-mgmt-api-http-cmds)# [no] protocol http [port <portNumber>]
   myswitch(config-mgmt-api-http-cmds)# [no] protocol http localhost [port <portNumber>]
   myswitch(config-mgmt-api-http-cmds)# [no] protocol unix-socket

• On-box usage of CAPI: It is often useful to run scripts that use Command API directly on the switch itself. The first is an HTTP server bound to localhost (on port 8080 by default), which only accepts connections arriving from the same machine.  The other solution is a Unix domain socket. Both can be used simultaneously also.

• Once Command API is enabled then you access via the local domain socket unix:/var/run/command-api.sock

 switch = Server( "unix:/var/run/command-api.sock" )

• If configured to use HTTP over localhost, your script can access the API as follows:

 switch = Server( "http://localhost:8080/command-api" )

Configuring a Certificate:

• Because clients use HTTP basic authentication to send usernames and passwords to the switch, we recommend using HTTPS so no passwords are sent in the clear over the network.
• By default a self-signed certificate will be used.
• You can view the current certificate using show management api http-commands https certificate

Exploring the Command API:

• To explore the API, point your web browser to http[s]://<switch-name>/, after enabling Command API.
• This web-app lets you interactively explore the protocol, return values, and model documentation.

Using Command API with Python:

• Install jsonrpclib library for installing Python JSON-RPC:

 admin:~ admin$ sudo pip install jsonrpclib

• from jsonrpclib import Server
• switch = Server( "https://username:passw0rd@myswitch/command-api" ) #Note that both username and password are compulsory. If no password, give the username itself in password field also
• response = switch.runCmds( 1, ["show version"] ) #instead of 1, we can also use “latest” to take latest version
• print "The switch's system MAC addess is", response[0]["systemMacAddress"]

• Another easy way is to import CAPIClient library and use as per its documentation on: https://github.com/arista-eosext/CAPIClient  

How it Works:

• The client starts by sending a JSON-RPC request via an HTTP POST request to http://<yourswitch>/command-api, which encapsulates a list of CLI commands it wishes to run, and the switch replies with a JSON-RPC response containing the result of each CLI command that was executed.
• If any of the commands emit an error, no further commands from that request are executed, and the response from the switch will contain an error object containing the details of the error that occurred.

Command Specification:

• In most cases, the client will use a simple string to specify the CLI command in the cmds parameter in the request. In certain cases, however, clients may wish to specify additional parameters during the command's execution.
• To use complex commands, pass a JSON object in lieu of a string, with the following attributes:

• cmd (mandatory): specify the CLI command to run.
• input (optional): specify a string to be provided as standard input while running the cmd
• revision (optional): in the case of 'show' commands that have been modified over the course of different EOS releases, this parameter allows clients to request an old model format. At this time, all models are at revision 1, and this attribute will be ignored.

• For example, to set the message of the day to Hello World!, the client should set cmds to

[ "enable", "configure", { "cmd": "banner motd", "input": "Hello World!\nEOF" } ]

• Similarly, if the switch requires an enable password, the following cmds value would let you enter exec mode and clear interface counters

[ { "cmd": "enable", "input": "hunter2" },  "clear counters" ]

Error Codes:

• The responses generated by the client library usually follow language conventions.
• For example, in Python, an error response results in an Exception being thrown, while Javascript expects an error handler callback.

Unsupported Commands:

• Certain commands are not permitted and will always return an error.
• The largest class of such commands are interactive commands .ie. those that need a response back from user or shows output continuously to user:

• watch
• reload #can be overcome by using the non-interactive ‘reload now’ command

• The bash command is only allowed with the timeout <timeout> argument, ie. bash timeout <timeout> <ARG>.
• Commands that attempt to use CLI pipes are also not allowed.

• (e.g. show interfaces | grep Ethernet1 )

• Also, no abbreviations are allowed in commands. This is necessary because future versions of EOS may add more commands, rendering previous abbreviations ambiguous.

Unconverted Commands:

• Although you can access almost any CLI command via the Command API, not all show commands have been converted to return formatted data, and trying to run the command with the format parameter set to json will result in an error.
• However, you can still get the CLI ASCII output for the unconverted command by setting the format parameter to text.

SEE: Command documentation for the respective command: http://<Switch name>/documentation.html