Friday, 7 September 2018

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

        

  1. 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.
  1. 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
  1. 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

  1. 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

  1. Check for connectivity by pinging each other
  2. 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.
  1. 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

  1. 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

  1. 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
  1. (config)#show vlan   —> check if other vlans have po10 and also if u can see all peer interfaces as pE
  2. 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)#

  1. 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)#

  1. 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

Sunday, 2 September 2018

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"]

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 

Tuesday, 21 August 2018

Subinterfaces

SUBINTERFACES

Subinterfaces: we need it when we have more vlans than physical links

As we know, we have  setup a trunking port between the switch and router, then configure the configure the interface and sub interfaces in your router:

Switch(config)#interface fa0/2

Switch(config-if)#switchport mode trunk

Router(config)#interface fa0/1

Router(config-if)#no shutdown

Router(config)#interface fa0/1.1

Router(config-subif)#encapsulation dot1q 1

Router(config-subif)#ip address 192.168.10.1 255.255.255.0

Router(config)#interface fa0/1.2

Router(config-subif)#encapsulation dot1q 15

Router(config-subif)#ip address 192.168.15.1 255.255.255.0

Router(config)#interface fa0/1.3

Router(config-subif)#encapsulation dot1q 35

Router(config-subif)#ip address 192.168.20.1 255.255.255.0

We configure sub interfaces because we have 3 vlan and just one physical link, for this reason we need that all data passing through a single link, how do we fix that?

Creating 3 sub-interfaces, one for each vlan, however it reduces the bandwidth one third.


Physical Interfaces: we need it when we have more physical links than vlans

We  configure a normal ip in each interface, (one per vlan), now in the switch instead of create trunk links, we create access links (one per vlan).

Router(config)#interface FastEthernet0/0

Router(config-subif)# ip address 10.10.10.1 255.255.255.0

Router(config)interface FastEthernet0/1

Router(config-subif)# ip address 10.10.20.1 255.255.255.0

Router(config)#interface FastEthernet0/3

Router(config-subif)#ip address 10.10.30.1 255.255.255.0

Switch(config)#interface range fa0/1, fa0/10

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 10

Switch(config)#interface range fa0/5,fa0/20

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 20

Switch(config)#interface range fa0/8, fa0/30

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 30

Here we have one link per vlan and we  can use the full bandwidth of each interface.

Wednesday, 8 August 2018

Arista FHRP: VRRP

VRRP

  • Advantages of using VRRP:
  • If one router goes down, we don’t need to manually configure in the many devices downstream. We use the virtual IP as the gateway on the devices.

  • Process:
  • We give a ID on the routers which we want to be part of VRRP. If we have the same ID on the routers, then, they both create a virtual Mac. (the SRC mac is a new Mac and dest mac is a well-known mac. Also, the destination IP is a well-known multicast IP (224.0.0.18)
  • Then, depending on the priority, physical IP on the routers, the Master and Backup router is determined. The router which has higher priority will win the election (In Arista, the default priority is 100)

  • Note:
  • The routers are expensive.
  • Also, the probability of a complete router going down is less as compared to a link going down
  • So, to use resources effectively, use a different router for different vlan
  • Also, VRRP is interface specific

  • Reelection Process:
  • If the election process is completed and then, the master router goes down, the Backup becomes the new master.
  • Now, if the master comes back up again, will re-election happen?

  • Other than the VRRP control packets, for any data that is being sent to outside network, the packet rewriting at the current Master Router uses the physical Mac address of that router.
  • http://www.programering.com/a/MDM2IzNwATc.html 

Wednesday, 1 August 2018

Linux Networking Utilities for Arista EOS- Part 2

Linux Networking Utilities for Arista EOS 

LINUX NETWORKING UTILITIES:

.

ip netns: (Linux Namespaces or VRF)

  • A network namespace is logically another copy of the network stack, with its own routes, firewall rules, and network devices.
  • By default a process inherits its network namespace from its parent. Initially all the processes share the same default network namespace from the init process.
  • NOTE: If a VRF was created in EOS, then, in order to access then via Linux; append ‘ns-’ to the VRF name.
  • NOTE: If a namespace was created in Linux, then, it won’t show up in EOS.
  • So, always create a VRF in EOS and use it in Linux by appending ‘ns-’ to the VRF name
  • 1. ip netns list - show all of the named network namespaces
  • This command displays all of the network namespaces in /var/run/netns
  • Note that the VRF named ‘tmod’ when viewed in Linux has the name ‘ns-tmod’

[admin@ck338 ~]$ ip netns list

ns-newvrf

ns-tmod

ns-trident

ns-arad

default

  • 2. ip netns add NAME - create a new named network namespace
  • If NAME is available in /var/run/netns/ this command creates a new network namespace and assigns NAME.

[admin@ck338 ~]$ sudo ip netns add testvrf

[admin@ck338 ~]$ ip netns list

testvrf

ns-newvrf

ns-tmod

ns-trident

ns-arad

default

  • 3. ip [-all] netns delete [ NAME ] - delete the name of a network namespace(s)
  • If NAME is present in /var/run/netns it is umounted and the mount point is removed.
  • If -all option was specified then all the network namespace names will be removed.

[admin@ck338 ~]$ sudo ip netns delete testvrf

  • 4. Assigning Interfaces to network namespace (VRF)
  • Bring up the loopback interface in the vpn network namespace.
  • [IMP] 5. Accessing interface in another VRF or namespace via Linux:
  • ip [-all] netns exec [ NAME ] [cmd]
  • If we want to run a command on any VRF, then, use this command. For example, if you want to do tcpdump via Linux on an interface in another VRF
  • If -all option was specified then cmd will be executed synchronously on the each named network namespace even if cmd fails on some of them.
  • ip netns exec ns-tmod ip addr list will show only the related interfaces and addresses, and will not show any interfaces or addresses from the global namespace.

[admin@ck338 ~]$ sudo ip netns exec ns-tmod ip addr list

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default

    link/ipip 0.0.0.0 brd 0.0.0.0

[admin@ck338 ~]$

  • Another useful command that this can be used with is for tcpdump and piping it to Wireshark:
  • The below command does packet capture on interface Vlan10 (which is in VRF dhcpvrf) only on port 67 and port 68 (since dhcp control messages use these ports)
  • ip netns exec ns-dhcpvrf tcpdump -i vlan10 port 67 or port 68
  • Now, in order to view the tcpdump on Wireshark:

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

Tcpdump:

The various flags that can be used with tcpdump are:

  • -i <interface>
  • # tcpdump -i eth0
  • -i any
  • Listen on all interfaces just to see if you’re seeing any traffic.
  • # tcpdump -i any
  • -c <count> -i <interface>
  • Used to capture a specified number of packets
  • # tcpdump -c 5 -i eth0
  • -D
  • Used to display all available iinterfaces for tcpdump
  • # tcpdump -D
  • -e [useful]
  • To get ethernet header as well
  • Should be used if filtering packets based on L2 headers or for L2-only packets
  • -w [useful]
  • Used to capture and save packets in a pcap file
  • # tcpdump -w 0001.pcap -i eth0
  • -r
  • Used to read captured packets file
  • # tcpdump -r 0001.pcap
  • -n
  • Usually when we do tcpdump, the IP address is replaced with the DNS address
  • In order to get the IP address, use -n flag. It will ignore the hostname and print out IP address itself
  • # tcpdump -n -i eth0
  • [useful] To filter packets based on type of packet:
  • To capture packets based on TCP port, run the following command with option tcp.
  • # tcpdump -i eth0 tcp
  • Similarly, replace tcp with icmp to check for ping packets only
  • Similarly, replace with ether for checking only LLDP or LACP packets. You can increase further filtering by adding destination address so that only LLDP or LACP packets destined to me shows up:
  • tcpdump -nevvvi et1 ether dst host 01:80:c2:00:00:0e
  • The -n -e -vvv -i flags are used in above to get advanced tuning
  • dst host is used to filter based on destination mac address
  • Other types that can be used are: fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp and udp
  • [useful] To capture based on port, src ip, dst ip:
  • Similarly, for packets on particular port: # tcpdump -i eth0 port 22
  • Similarly, for packets from particular source IP: # tcpdump -i eth0 src 192.168.0.2
  • Similarly, for packets from a particular destination IP: # tcpdump -i eth0 dst 50.116.66.139
  • [useful] -v, -vv, -vvv:
  • To select amount of packet information in verbose mode

resolv.conf:

  • resolv.conf is the name of a computer file used in various operating systems to configure the system's Domain Name System (DNS) resolver.
  • The file is a plain-text file usually created by the network administrator or by applications that manage the configuration tasks of the system.
  • The file resolv.conf typically contains directives that specify the default search domains; used for completing a given query name to a fully qualified domain name when no domain suffix is supplied. It also contains a list of IP addresses of nameservers available for resolution. An example file is:

search example.com local.lan
nameserver 127.0.0.1
nameserver 172.16.1.254
nameserver 172.16.2.254
nameserver 192.168.137.
2

  • resolv.conf is usually located in the /etc directory of the file system.
  • The file is either maintained manually, or when DHCP is used, it is usually updated with the utility resolvconf.