New Book - Network Programmability and Automation

Several people have asked me what I thought the future of a network engineer looks like.

I didn't have a great answer for them, other than it would look different, but is still needed:  abusedbits: Modern Network Engineering

If you want to see how it'll be different, Jason Edelman, Scott S. Lowe, Matt Oswalt are authoring a book being published by O'Reilly called Network Programmability and Automation.

I've looked at this book and I believe it is a basis for the answer we're all looking for.

Network Programmability and Automation - O'Reilly Media

This book is currently Early Release, so there may be some rough edges yet.

I will comment more on it as time permits.

Episodic Intransience vs Immutable Infrastructure

Anytime you hear someone using the term Immutable Infrastructure, you are allowed to giggle, snork and/or laugh.  Servers, Networks and Storage are not immutable, they never will be.  If you write about, have recently presented on, or otherwise define, discuss or profess Immutable Infrastructure, my apologies.

Keep in mind, Immutable is the equivalent of Willie Wonka's Everlasting Gobstopper.

Immutable means that the device, construct or mechanism is unchanging or unable to change.  Abstract it as much as you like and some underlying subsystem is absolutely guaranteed to cause change.

With today's infrastructure, we are guaranteed it will physically change sometime within 7 years.  That's typical of equipment vendor product refresh.  Plus purchasing infrastructure equipment without the continuous improvement provided by product evolution cycle would result in some extremely old school equipment.  Not to mention that memory use is transient, storage is needfully consumed and the network bursts and caches as needed.  And, don't get me started on drivers.  The equipment infrastructure is not immutable.

The operating system is guaranteed to change much more rapidly, with patch release examples measured in days or weeks, the operating system infrastructure is not immutable.

Virtualization system, changes literally on demand, be it manual or automated.  So, not immutable. 

Some of the Docker aficionados talk about an immutability in the container delivery pattern.  This is tied to a repeatable, to the tune of possibly minutes,  application development process.  If it is immutable, why would it ever need to be repeatable (changing).  Just saying, it's not.

In this I tend to concur with John Willis, "no example in my 35 years of working with IT infrastructure of a system or infrastructure that is  completely immutable…"

So, what are we really talking about?  It's not immutability in any of the delivery patterns associated with modern application development.

What we are taking about is a level of intransience certainly.  The architectural pattern must be well defined, repeatable and largely inexhaustible.  It's more like Episodic Intransience, where change/improvement/SCRUM cycle delivery exist between durations of intransience.  

Spine and Leaf Nodes

This drawing (or one resembling it) seems to keep popping up in Spine and Leaf discussions.  This is an incomplete view of the mechanism of the art.  The Spine and leaf architecture is certainly compelling for a variety of good reasons, not the least of which is a horizontal scaling model that far exceeds more traditional methods of networking.

See  sdxcentral article

The actual story of this design model may actually much more interesting to the network developer.  If this model were the sole construct of the network design, it wouldn't be, necessarily, special.

But if the design model indicated a requirement for redundancy in the Top of Rack (ToR) or if there was a special need physical configuration like a 3-cabinet-wide Logical Rack, those may also be supported by the Spine and Leaf Network model, fairly simply in the guise of a Leaf Node arrangement.

That's not all though.  To scale above the reasonable size of a traditional network, it may be necessary to start thinking about the routing protocol, in order to avoid those pesky all encompassing broadcast domains, delivering what is largely L3 all the way down to the host.

Then topping it off with a healthy dose of the art of the possible, utilizing the routing protocol constructed in the previous model to create a delivery platform for logically isolated networks utilizing VxLAN.  Also, when you get to this size, don't forget to add the Management Network VRF, need a way for those 1000's upon 1000's of physical systems to get back to the monitoring and management.

Hopefully you can recognize the original drawing in the last drawing.  It's still there, but nothing like the switched network of old.

Book Review - The Unwritten Laws of Engineering by W.J. King

I was intrigued enough by a twitter conversation about this book that I purchased a copy online.

Over my career, should I have written down things that apply to engineers, I've a feeling that many of the topics in this book would have made it into my notes.

As an example, and relevant to me this very day, "Cultivate the habit of seeking other peoples' opinions and recommendations."

Had I not asked "Jerry" to review some materials I was working on, I would not have known that a partial solution was already completed and those materials were available to me to extend the work of a predecessor(s).  I would have liked to have my name on the total solution, but as it turns out, the solution was expedited by days if not weeks.

The reason this one thing seems so difficult for engineers to understand is that it isn't a sign of weakness or lack of knowledge or how to apply response to problem.  It's more about understanding the background of the issue and acting with more relevant information.

This book is replete with examples such as this one that may well be applied to engineers in all professions on a daily basis.

If you're in the mood for some truths, if not entirely Laws of Engineering, I recommend you pick up this book.  

The 6 laws (for reference)

I'm posting this with references mostly for my own archiving purpose.

http://www.techrepublic.com/article/the-6-laws-every-cloud-architect-should-know-according-to-werner-vogels/?utm_campaign=buffer&utm_content=buffer5c6e4&utm_medium=social&utm_source=twitter.com

This blog is excerpted from techrepublic above.  Appreciation to Werner Vogels for the discussion and Conner Forrest for the article.

Lucas Critique

"It is naive to try to predict the effects of a change entirely on the basis of relationships observed in historical data."

Gall's Law

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."

Law of Demeter

"Each unit should have only limited knowledge about other units—only units 'closely' related to the current unit. Each unit should only talk to its friends; don't talk to strangers."

Occam's Razor

"The one with the fewest assumptions should be selected."

Reed's Law

"The utility of large networks, particularly social networks, can scale exponentially with the size of the network."

The Gestalt Principle

"The whole is greater than the sum of its parts."

....

The only thing I'd add to this is "don't get inexorably tied to a single mode" as it almost guarantees future failure.  There are exceptions, so it's likely not a law, but there's a lot of truth to it.

....

THE LACK OF HISTORIC KNOWLEDGE IS SO FRUSTRATING -- Ivan Pepelnjak, wish this were a law.  Those who fail to learn from history....

....

rfc1925

Modern Network Engineering

I don't know how to stress this enough, but Network Engineering will NOT go away with the advent of Software Defined Networking.

 Here's why: Software Defined Networking Abstracts the control plane from the data plane. Both the control and data mechanisms continue to exist. What does change is the means by which we interact with them.

 So, as Software Defined Networking and Network Function Virtualization (and SD-WAN, etc, etc) continue to enhance the abstraction, the fundamental knowledge of how the logic of the systems function is still required.

 I can't say, for sure, that the value of someone that knows a particular command line interface is going to be continually valuable though. Look at what happened with the controller (control plane) developments in wireless networking. The value of the CLI diminished drastically with advent of the controller for enterprise wireless networking. The value of how the wireless system actually operates increased and so did the people that could balance the change. The same thing will happen with SDN technology.

REST API and/or eAPI calls are going to replace current system management methods. Any number of programming languages are going to provide the basis for automation of the service. Consider methods like Python scripted interaction with the control plane currently being done with OpenStack and you'll have a glimpse into that future.

 You also shouldn't forget that this isn't the first time software definition has been applied to networking. Some of you may remember TCL. Just saying, not the first time.

 The other element that's driving these advancements in networking can be attributed to the structure of the interface. JSON or similar structure is surely going to play a role in managing software defined elements.

 I urge networkers that are concerned about what looks like an uncertain future in networking to explore the pieces that make up the software defined element. This is the path to value for the individual with Software Defined Networking.

 Take a course, read a book, grab stuff off the web like this and figure out how it's done. You won't regret it.

  Other Reading:

http://searchnetworking.techtarget.com/feature/Network-engineer-job-description-will-evolve-not-evaporate-with-SDN 

http://www.packetdesign.com/blog/no-software-defined-networking-will-not-doom-engineers

http://searchnetworking.techtarget.com/feature/Will-IT-generalists-replace-network-engineering-jobs

http://www.infoworld.com/article/2611908/networking/will-software-defined-networking-kill-network-engineers--beloved-cli-.html 

Macrosegmentation is now in the Networking Lexicon (soon we'll abbreviate it)

Macrosegmentation at the networking level just got a definition today, we're sure to remove the hyphen (Macro-segmentation) and abbreviate it.

A warm up on the details here:

http://www.arista.com/blogs/?p=1245

At its most basic level, macrosegmentation will allow the re-direction of traffic between specific points in the network to enable logical topologies with firewalls and load balancing systems.

Very nifty trick considering:

     Placement of the equipment is location independent.

     Cybersecurity can continue to manage FW rules without blended support requirements.

     It should* work with multi-vendor equipment.

It also brings back fond memories of an Arista whiteboard barstool in VMworld.  Wish I took a picture of it.

VP of Electricity

Randy Rayess on techcrunch proposes that the CIO is the next VP of Electricity.

Imagine the turn of the 20th century, electricity delivery for a company had to be managed.  Often companies would stand up their own infrastructure to deliver electricity within a building or factory.  To support this infrastructure, there would be a team of electrical specialists, electricians, that would maintain the equipment and support the infrastructure.  Once electricity became a utility, much of this was replaced by the vendor and sold as-a-Service to the customer.

Comparing that to the CIO is interesting because there are some parallels, but not entirely and not in the single component delivery requirement that was under the VP of Electricity.

Consider, for instance, that the CIO's primary goal is to keep the IT Infrastructure delivering the application.  Actually applications.  <--  The plural is incredibly important here. It's not a single service, it's tens, hundreds, sometimes even thousands of applications.

These applications need to inter-operate enough to use common foundational services like networking and data center, platform systems and virtualization, and the growing analytics necessary to make ever increasing critical business decisions.  While we may think about them from a consumption perspective, and that reduces many of the applications to in-business-quarter costs, which is great for current business controlling their financial run rate, but

Inter-operation doesn't happen by magic and someone needs to be in a position to manage these as-a-Service applications before they sprawl into a buffet style line of out of control applications that not only don't support the business objectives, but don't deliver the critical value that is required by the business.  Not to mention the potential risks of data breach and loss that happen when applications are deployed without planning.

Then, consider that the cost of electricity isn't going down.  At best, it's stagnant over long periods of time at commercial rates, but the cost is going up and it's guaranteed to go up.  The use of electricity is also increasing as we put in more general purpose hardware to support more applications on even more virtualized platforms.

My contention to the article is that while we don't need the turn of the 20th century VP of Electricity, we do need to continue to think about the sunk cost in the delivery of applications.  We need to have someone thinking about the plethora of applications needed by each industry to operate as well as the infrastructure and critical access to both private and public services.

Who better than the person that understand's the business demand.

Top of Rack - higher speed, higher density

How energy dense do you want to make your rack.

Arista announces two new switches that certainly fit high density, high speed ToR models.

Loaded with QSFP100 and backward compatible all the way to....10Gbps.

100GbE, 40GbE, 4x10GbE, 4x25GbE or 2x 50GbE

New Arista Switches

The thing I find really interesting, because we all know port densities and bandwidth is guaranteed to grow anyway... but,

7W / port

Evidently Arista believes that electrical consumption is a sunk cost in servicing the workload....

So do I.

This really drives the concept of the "logical rack" the number of racks that can be covered by a pair of ToR switches in the Spine and Leaf architectural model.

Let's conduct a short breakdown on the 32 port unit.

~ 28 100GbE connections for hosts (so, 28 hosts in ~ 2 racks at 2U size)

~28 40GbE connections for hosts ( 28 hosts in ~ 2 racks at 2U size)

~112 10GbE or 25GbE connections for hosts  (112 hosts in ~ 7 racks at 2U size)

~56 50GbE connections for hosts  (56 hosts in ~ 4 racks at 2U size)

using a pair of ports for 100GbE uplink and a pair of ports for inner-Leaf connections (not including options with the SFP+ ports)

Makes for some very well connected hosts and at ~18kW / rack, some fairly dense commodity computing....

Hybrid Cloud, how it can look....

Hybrid Cloud Network Model

The control plane is separated from the data plane.

The capability is completely API driven.

Imagine now an environment that is fully automated and orchestrated.  

It has QoS for the Enterprise Application.

It has Bandwidth Management for financial management

It has the possibility to connect at Layer 2, extending an application back to the Private Cloud

It has SLA

It has well understood Latency

It avoids the Internet completely

Want to know more?  Follow the Twitter hashtag #harnessthecloud

Hybrid Cloud, how it used to look....

Islands of automation areas in Cloud connectivity

And I'm not joking about owning every possible problem on the internet.

If you would like to see how it can be done now, please follow this link:

http://www.vdatacloud.com/blogs/2015/09/23/the-network-is-the-computer/

Goats and superChickens

Oddly enough, both of these are IT discussions.

The first one is how to disrupt enough to change the current status quo for Devops to work without breaking the things that work.

https://www.youtube.com/watch?v=9LcQUAMS4XQ

The second is how to build teams that work.

http://www.ted.com/talks/margaret_heffernan_why_it_s_time_to_forget_the_pecking_order_at_work?language=en 

....

In summary:

 -- successful IT needs to have goats (first story) for continuous integration
 -- successful IT needs to have chickens (second story) to have successful teams.

The moral of the story:

Goats are versatile and useful (and cute)

AND superChickens aren't all that good for a team

Oddly enough, goats and chickens get along with each other.

Amazon Web Services in Plain English

https://www.expeditedssl.com/aws-in-plain-english


Funny and ... useful

VMworld 2015 Favorite Quote

Not much more to say about that.

Agile Scrum Training Series

http://scrumtrainingseries.com/

I've been working on a project that is making use of Agile/Scrum in an incredibly complex hardware / hardware / hardware / software / software / software / software ...  (you get the idea).

At this point I'm convinced that this project would have taken 2x to 3x the time to get to the point we're at today AND it wouldn't be half as well documented as it is today.

I'm here to say that Agile/Scrum isn't solely for software development.  It can be used for just about any complex integration task.

Recently spoke with one of my associates and it is apparent that Agile/Scrum is responsible for the elimination of the "chase the shiny object" that often occurs in these types of projects also.

I can't recommend it enough and if you need an introduction, follow the link above to free online training.  It is worth every minute.

What's it running on?

I've a request to share the platform this is all running on.

Here's the itemized list:

As you can tell from the graphic, this is Lab02.  Lab01 is my OpenStack rig identified in the earlier part of the blog.

Before anyone says anything, yeah, the PS is overkill and the motherboard is...interesting, but I've got multiple plans for the box itself.  This is just one use case.  :-)

If you plan on building a unit to do the same, consider the PSU, the CPU, the water cooler and the memory for cost reductions...  You could probably come in under $800 if you really squeezed it.

I can't recommend the SSD enough though.  Fast...

Arista CVX on VirtualBox

So, the next thing to do, set up CVX on Arista.

I'm setting Spine1 as the CVX manager.

configuration was quite simple thanks to Mo from Arista:

spine1(config)#cvx
spine1(config-­‐cvx)#no shutdown

spine1(config)#management api http-­‐commands
spine1(config-­‐mgmt-­‐api-­‐http-­‐cmds)#no shutdown
spine1(config-­‐mgmt-­‐api-­‐http-­‐cmds)#no protocol http
spine1(config-­‐mgmt-­‐api-­‐http-­‐cmds)#protocol https


Here's the drop in config for all of the other switches:

en
config t
management cvx
server host 10.0.0.251
no shutdown
end
wr

Logging back into the spine1 switch, here's the review.

spine1#sh cvx
CVX Server
  Status: Enabled
  UUID: c2b3cbbc-45ed-11e5-8814-080027f4b56b
  Heartbeat interval: 20.0
  Heartbeat timeout: 60.0

spine1#sh cvx connections
Switch 08:00:27:6d:13:80
  Hostname: leaf1-sw01
  Status: up
  Last heartbeat sent: 0:00:11 ago
  Last heartbeat received: 0:00:12 ago
  Clock offset: 252455.861674
  Out-of-band connection: Not secured
  In-band connection: Not secured (SSL not supported)
Switch 08:00:27:89:cf:4d
  Hostname: leaf2-sw03
  Status: up
  Last heartbeat sent: 0:00:11 ago
  Last heartbeat received: 0:00:15 ago
  Clock offset: 253199.591905
  Out-of-band connection: Not secured
  In-band connection: Not secured (SSL not supported)
Switch 08:00:27:a7:c7:17
  Hostname: leaf1-sw02
  Status: up
  Last heartbeat sent: 0:00:11 ago
  Last heartbeat received: 0:00:18 ago
  Clock offset: 252634.767828
  Out-of-band connection: Not secured
  In-band connection: Not secured (SSL not supported)
Switch 08:00:27:cb:45:7c
  Hostname: spine2 <--  Not sure I need it here, but still cool it worked
  Status: up
  Last heartbeat sent: 0:00:11 ago
  Last heartbeat received: 0:00:00 ago
  Clock offset: -45.284555422
  Out-of-band connection: Not secured
  In-band connection: Not secured (SSL not supported)
Switch 08:00:27:4d:ed:74
  Hostname: leaf2-sw04
  Status: up
  Last heartbeat sent: 0:00:11 ago
  Last heartbeat received: 0:00:04 ago
  Clock offset: 252439.728537
  Out-of-band connection: Not secured
  In-band connection: Not secured (SSL not supported)
Switch 08:00:27:34:ea:a9
  Hostname: leaf3-sw05
  Status: up
  Last heartbeat sent: 0:00:11 ago
  Last heartbeat received: 0:00:12 ago
  Clock offset: 252796.489615
  Out-of-band connection: Not secured
  In-band connection: Not secured (SSL not supported)
Switch 08:00:27:30:57:3e
  Hostname: leaf3-sw06
  Status: up
  Last heartbeat sent: 0:00:11 ago
  Last heartbeat received: 0:00:02 ago
  Clock offset: 435612.242123
  Out-of-band connection: Not secured
  In-band connection: Not secured (SSL not supported)


**********

If it doesn't work, verify lldp!

Verify you can ping around the loopbacks  (make sure you source icmp)

Next opportunity, I'll mess with VxLAN a bit.

Current Environment - Arista Spine and Leaf on Virtualbox

Here's the current state of the topology.  I'm having a problem getting past 192.168.1.2 (sw6-E6) in the model.  This is a interface on the virtual network tied to the physical nic on the computer I'm using.

Glad I stopped messing with that to get the BGP working, but it's still nagging at me.

Leaf Switch Configurations - Arista Spine and Leaf on Virtualbox

Switch 1 - Configuration

leaf1-sw01>en

leaf1-sw01#sh run

! Command: show running-config

! device: leaf1-sw01 (vEOS, EOS-4.15.0F)

!

! boot system flash:/vEOS-lab.swi

!

transceiver qsfp default-mode 4x10G

!

hostname leaf1-sw01

!

spanning-tree mode mstp

!

no aaa root

!

username arista privilege 15 secret 5 $1$x5GKrbKk$azBM4Wlv3TzOQjcjeXOHJ.

!

vlan 101

!

vlan 2047

   trunk group mlagL1-L2

!

interface Port-Channel1

   switchport mode trunk

   switchport trunk group mlagL1-L2

!

interface Ethernet1

   no switchport

   ip address 10.180.254.2/30

!

interface Ethernet2

   no switchport

   ip address 10.180.254.130/30

!

interface Ethernet3

   channel-group 1 mode active

!

interface Ethernet4

   channel-group 1 mode active

!

interface Ethernet5

   switchport access vlan 101

!

interface Loopback0

   ip address 10.0.0.1/32

!

interface Management1

   ip address 10.10.10.31/24

!

interface Vlan101

   ip address 172.16.1.252/24

   ip virtual-router address 172.16.1.254

!

interface Vlan2047

   ip address 10.180.254.225/30

!

ip route 0.0.0.0/0 192.168.1.254

!

ip routing

!

mlag configuration

   domain-id mlagL1-L2

   local-interface Vlan2047

   peer-address 10.180.254.226

   peer-link Port-Channel1

!

router bgp 65101

   maximum-paths 4 ecmp 128

   neighbor 10.180.254.1 remote-as 65000

   neighbor 10.180.254.1 maximum-routes 12000

   neighbor 10.180.254.129 remote-as 65000

   neighbor 10.180.254.129 maximum-routes 12000

   neighbor 172.16.1.253 remote-as 65101

   neighbor 172.16.1.253 maximum-routes 12000

   network 10.0.0.1/32

   network 10.180.254.0/24

   network 172.16.1.0/24

!

!

end

leaf1-sw01#sh ip route

VRF name: default

Codes: C - connected, S - static, K - kernel,

       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,

       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,

       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,

       R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,

       NG - Nexthop Group Static Route

Gateway of last resort:

 S      0.0.0.0/0 [1/0] via 10.180.254.1, Ethernet1

                        via 10.180.254.129, Ethernet2

 C      10.0.0.1/32 is directly connected, Loopback0

 B I    10.0.0.2/32 [200/0] via 172.16.1.253, Vlan101

 B E    10.0.0.3/32 [200/0] via 10.180.254.1, Ethernet1

                            via 10.180.254.129, Ethernet2

 B E    10.0.0.4/32 [200/0] via 10.180.254.1, Ethernet1

                            via 10.180.254.129, Ethernet2

 B E    10.0.0.5/32 [200/0] via 10.180.254.1, Ethernet1

                            via 10.180.254.129, Ethernet2

 B E    10.0.0.6/32 [200/0] via 10.180.254.1, Ethernet1

                            via 10.180.254.129, Ethernet2

 C      10.10.10.0/24 is directly connected, Management1

 C      10.180.254.0/30 is directly connected, Ethernet1

 C      10.180.254.128/30 is directly connected, Ethernet2

 C      10.180.254.224/30 is directly connected, Vlan2047

 C      172.16.1.0/24 is directly connected, Vlan101

 B E    172.16.2.0/24 [200/0] via 10.180.254.1, Ethernet1

                              via 10.180.254.129, Ethernet2

 B E    172.16.3.0/24 [200/0] via 10.180.254.1, Ethernet1

                              via 10.180.254.129, Ethernet2

 B E    192.168.1.0/24 [200/0] via 10.180.254.1, Ethernet1

                               via 10.180.254.129, Ethernet2

leaf1-sw01#

Switch 2 - Configuration

leaf1-sw02#sh run

! Command: show running-config

! device: leaf1-sw02 (vEOS, EOS-4.15.0F)

!

! boot system flash:/vEOS-lab.swi

!

transceiver qsfp default-mode 4x10G

!

hostname leaf1-sw02

!

spanning-tree mode mstp

!

no aaa root

!

username arista privilege 15 secret 5 $1$dgmrUK3G$GBhRaYnIvOzIOdgozc9Kb.

!

vlan 101

!

vlan 2047

   trunk group mlagL1-L2

!

interface Port-Channel1

   switchport mode trunk

   switchport trunk group mlagL1-L2

!

interface Ethernet1

   no switchport

   ip address 10.180.254.6/30

!

interface Ethernet2

   no switchport

   ip address 10.180.254.134/30

!

interface Ethernet3

   channel-group 1 mode active

!

interface Ethernet4

   channel-group 1 mode active

!

interface Ethernet5

   switchport access vlan 101

!

interface Loopback0

   ip address 10.0.0.2/32

!

interface Management1

   ip address 10.10.10.32/24

!

interface Vlan101

   ip address 172.16.1.253/24

   ip virtual-router address 172.16.1.254

!

interface Vlan2047

   ip address 10.180.254.226/30

!

ip route 0.0.0.0/0 192.168.1.254

!

ip routing

!

mlag configuration

   domain-id mlagL1-L2

   local-interface Vlan2047

   peer-address 10.180.254.225

   peer-link Port-Channel1

!

router bgp 65101

   maximum-paths 4 ecmp 128

   neighbor 10.180.254.5 remote-as 65000

   neighbor 10.180.254.5 maximum-routes 12000

   neighbor 10.180.254.133 remote-as 65000

   neighbor 10.180.254.133 maximum-routes 12000

   neighbor 172.16.1.252 remote-as 65101

   neighbor 172.16.1.252 maximum-routes 12000

   network 10.0.0.2/32

   network 10.180.254.0/24

   network 172.16.1.0/24

!

!

end

leaf1-sw02# sh ip route

VRF name: default

Codes: C - connected, S - static, K - kernel,

       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,

       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,

       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,

       R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,

       NG - Nexthop Group Static Route

Gateway of last resort:

 S      0.0.0.0/0 [1/0] via 10.180.254.5, Ethernet1

                        via 10.180.254.133, Ethernet2

 B I    10.0.0.1/32 [200/0] via 172.16.1.252, Vlan101

 C      10.0.0.2/32 is directly connected, Loopback0

 B E    10.0.0.3/32 [200/0] via 10.180.254.5, Ethernet1

                            via 10.180.254.133, Ethernet2

 B E    10.0.0.4/32 [200/0] via 10.180.254.5, Ethernet1

                            via 10.180.254.133, Ethernet2

 B E    10.0.0.5/32 [200/0] via 10.180.254.5, Ethernet1

                            via 10.180.254.133, Ethernet2

 B E    10.0.0.6/32 [200/0] via 10.180.254.5, Ethernet1

                            via 10.180.254.133, Ethernet2

 C      10.10.10.0/24 is directly connected, Management1

 C      10.180.254.4/30 is directly connected, Ethernet1

 C      10.180.254.132/30 is directly connected, Ethernet2

 C      10.180.254.224/30 is directly connected, Vlan2047

 C      172.16.1.0/24 is directly connected, Vlan101

 B E    172.16.2.0/24 [200/0] via 10.180.254.5, Ethernet1

                              via 10.180.254.133, Ethernet2

 B E    172.16.3.0/24 [200/0] via 10.180.254.5, Ethernet1

                              via 10.180.254.133, Ethernet2

 B E    192.168.1.0/24 [200/0] via 10.180.254.5, Ethernet1

                               via 10.180.254.133, Ethernet2

leaf1-sw02#

Switch 3 - configuration

leaf2-sw03>en

leaf2-sw03#sh run

! Command: show running-config

! device: leaf2-sw03 (vEOS, EOS-4.15.0F)

!

! boot system flash:/vEOS-lab.swi

!

transceiver qsfp default-mode 4x10G

!

hostname leaf2-sw03

!

spanning-tree mode mstp

!

no aaa root

!

username arista privilege 15 secret 5 $1$PQtScGLc$3eEJepRVOUEahC.wNveqG/

!

vlan 102

!

vlan 2048

   trunk group mlagL3-L4

!

interface Port-Channel1

   switchport mode trunk

   switchport trunk group mlagL3-L4

!

interface Ethernet1

   no switchport

   ip address 10.180.254.10/30

!

interface Ethernet2

   no switchport

   ip address 10.180.254.138/30

!

interface Ethernet3

   channel-group 1 mode active

!

interface Ethernet4

   channel-group 1 mode active

!

interface Ethernet5

   switchport access vlan 102

!

interface Loopback0

   ip address 10.0.0.3/32

!

interface Management1

   ip address 10.10.10.33/24

!

interface Vlan102

   ip address 172.16.2.252/24

   ip virtual-router address 172.16.2.254

!

interface Vlan2048

   ip address 10.180.254.229/30

!

ip route 0.0.0.0/0 192.168.1.254

!

ip routing

!

mlag configuration

   domain-id mlagL3-L4

   local-interface Vlan2048

   peer-address 10.180.254.230

   peer-link Port-Channel1

!

router bgp 65102

   maximum-paths 4 ecmp 128

   neighbor 10.180.254.9 remote-as 65000

   neighbor 10.180.254.9 maximum-routes 12000

   neighbor 10.180.254.137 remote-as 65000

   neighbor 10.180.254.137 maximum-routes 12000

   neighbor 172.16.2.253 remote-as 65102

   neighbor 172.16.2.253 maximum-routes 12000

   network 10.0.0.3/32

   network 10.180.254.0/24

   network 172.16.2.0/24

!

!

end

leaf2-sw03#sh ip route

VRF name: default

Codes: C - connected, S - static, K - kernel,

       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,

       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,

       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,

       R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,

       NG - Nexthop Group Static Route

Gateway of last resort:

 S      0.0.0.0/0 [1/0] via 10.180.254.9, Ethernet1

                        via 10.180.254.137, Ethernet2

 B E    10.0.0.1/32 [200/0] via 10.180.254.9, Ethernet1

                            via 10.180.254.137, Ethernet2

 B E    10.0.0.2/32 [200/0] via 10.180.254.9, Ethernet1

 C      10.0.0.3/32 is directly connected, Loopback0

 B E    10.0.0.5/32 [200/0] via 10.180.254.9, Ethernet1

                            via 10.180.254.137, Ethernet2

 B E    10.0.0.6/32 [200/0] via 10.180.254.9, Ethernet1

                            via 10.180.254.137, Ethernet2

 C      10.10.10.0/24 is directly connected, Management1

 C      10.180.254.8/30 is directly connected, Ethernet1

 C      10.180.254.136/30 is directly connected, Ethernet2

 C      10.180.254.228/30 is directly connected, Vlan2048

 B E    172.16.1.0/24 [200/0] via 10.180.254.9, Ethernet1

                              via 10.180.254.137, Ethernet2

 C      172.16.2.0/24 is directly connected, Vlan102

 B E    172.16.3.0/24 [200/0] via 10.180.254.9, Ethernet1

                              via 10.180.254.137, Ethernet2

 B E    192.168.1.0/24 [200/0] via 10.180.254.9, Ethernet1

                               via 10.180.254.137, Ethernet2

leaf2-sw03#

Switch4 - configuration

leaf2-sw04>en

leaf2-sw04#sh run

! Command: show running-config

! device: leaf2-sw04 (vEOS, EOS-4.15.0F)

!

! boot system flash:/vEOS-lab.swi

!

transceiver qsfp default-mode 4x10G

!

hostname leaf2-sw04

!

spanning-tree mode mstp

!

no aaa root

!

username arista privilege 15 secret 5 $1$w/eAcrc6$V//ELJ..C40cf7I1kYpfH1

!

vlan 102-103

!

vlan 2048

   trunk group mlagL3-L4

!

interface Port-Channel1

   switchport mode trunk

   switchport trunk group mlagL3-L4

!

interface Ethernet1

   no switchport

   ip address 10.180.254.14/30

!

interface Ethernet2

   no switchport

   ip address 10.180.254.142/30

!

interface Ethernet3

   channel-group 1 mode active

!

interface Ethernet4

   channel-group 1 mode active

!

interface Ethernet5

   switchport access vlan 102

!

interface Loopback0

   ip address 10.0.0.4/32

!

interface Management1

   ip address 10.10.10.34/24

!

interface Vlan103

   ip address 172.16.2.253/24

   ip virtual-router address 172.16.2.254

!

interface Vlan2048

   ip address 10.180.254.230/30

!

ip route 0.0.0.0/0 192.168.1.254

!

ip routing

!

mlag configuration

   domain-id mlagL3-L4

   local-interface Vlan2048

   peer-address 10.180.254.229

   peer-link Port-Channel1

!

router bgp 65102

   maximum-paths 4 ecmp 128

   neighbor 10.180.254.13 remote-as 65000

   neighbor 10.180.254.13 maximum-routes 12000

   neighbor 10.180.254.141 remote-as 65000

   neighbor 10.180.254.141 maximum-routes 12000

   neighbor 172.16.2.252 remote-as 65102

   neighbor 172.16.2.252 maximum-routes 12000

   network 10.0.0.4/32

   network 10.180.254.0/24

   network 172.16.2.0/24

!

!

end

leaf2-sw04# sh ip route

VRF name: default

Codes: C - connected, S - static, K - kernel,

       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,

       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,

       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,

       R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,

       NG - Nexthop Group Static Route

Gateway of last resort:

 S      0.0.0.0/0 [1/0] via 10.180.254.13, Ethernet1

                        via 10.180.254.141, Ethernet2

 B E    10.0.0.1/32 [200/0] via 10.180.254.13, Ethernet1

                            via 10.180.254.141, Ethernet2

 B E    10.0.0.2/32 [200/0] via 10.180.254.13, Ethernet1

 C      10.0.0.4/32 is directly connected, Loopback0

 B E    10.0.0.5/32 [200/0] via 10.180.254.13, Ethernet1

                            via 10.180.254.141, Ethernet2

 B E    10.0.0.6/32 [200/0] via 10.180.254.13, Ethernet1

                            via 10.180.254.141, Ethernet2

 C      10.10.10.0/24 is directly connected, Management1

 C      10.180.254.12/30 is directly connected, Ethernet1

 C      10.180.254.140/30 is directly connected, Ethernet2

 C      10.180.254.228/30 is directly connected, Vlan2048

 B E    172.16.1.0/24 [200/0] via 10.180.254.13, Ethernet1

                              via 10.180.254.141, Ethernet2

 C      172.16.2.0/24 is directly connected, Vlan103

 B E    172.16.3.0/24 [200/0] via 10.180.254.13, Ethernet1

                              via 10.180.254.141, Ethernet2

 B E    192.168.1.0/24 [200/0] via 10.180.254.13, Ethernet1

                               via 10.180.254.141, Ethernet2

leaf2-sw04#

Switch5 - configuration

leaf3-sw05#sh run

! Command: show running-config

! device: leaf3-sw05 (vEOS, EOS-4.15.0F)

!

! boot system flash:/vEOS-lab.swi

!

transceiver qsfp default-mode 4x10G

!

hostname leaf3-sw05

!

spanning-tree mode mstp

!

no aaa root

!

username arista privilege 15 secret 5 $1$lXq5jGZ7$dKqbUEZ4amFlNDjwOb40k.

!

vlan 103

!

vlan 2049

   trunk group mlagL5-L6

!

interface Port-Channel1

   switchport mode trunk

   switchport trunk group mlagL5-L6

!

interface Ethernet1

   no switchport

   ip address 10.180.254.18/30

!

interface Ethernet2

   no switchport

   ip address 10.180.254.146/30

!

interface Ethernet3

   channel-group 1 mode active

!

interface Ethernet4

   channel-group 1 mode active

!

interface Ethernet5

   switchport access vlan 103

!

interface Ethernet6

!

interface Loopback0

   ip address 10.0.0.5/32

!

interface Management1

   ip address 10.10.10.35/24

!

interface Vlan103

   ip address 172.16.3.252/24

   ip virtual-router address 172.16.3.254

!

interface Vlan2049

   ip address 10.180.254.233/30

!

ip route 0.0.0.0/0 192.168.1.254

!

ip routing

!

mlag configuration

   domain-id mlagL5-L6

   local-interface Vlan2049

   peer-address 10.180.254.234

   peer-link Port-Channel1

!

router bgp 65103

   maximum-paths 4 ecmp 128

   neighbor 10.180.254.17 remote-as 65000

   neighbor 10.180.254.17 maximum-routes 12000

   neighbor 10.180.254.145 remote-as 65000

   neighbor 10.180.254.145 maximum-routes 12000

   neighbor 172.16.3.253 remote-as 65103

   neighbor 172.16.3.253 maximum-routes 12000

   network 10.0.0.5/32

   network 10.180.254.0/24

   network 172.16.3.0/24

!

!

end

leaf3-sw05#sh ip route

VRF name: default

Codes: C - connected, S - static, K - kernel,

       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,

       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,

       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,

       R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,

       NG - Nexthop Group Static Route

Gateway of last resort:

 S      0.0.0.0/0 [1/0] via 172.16.3.253, Vlan103

 B E    10.0.0.1/32 [200/0] via 10.180.254.17, Ethernet1

                            via 10.180.254.145, Ethernet2

 B E    10.0.0.2/32 [200/0] via 10.180.254.17, Ethernet1

 B E    10.0.0.3/32 [200/0] via 10.180.254.17, Ethernet1

                            via 10.180.254.145, Ethernet2

 B E    10.0.0.4/32 [200/0] via 10.180.254.17, Ethernet1

                            via 10.180.254.145, Ethernet2

 C      10.0.0.5/32 is directly connected, Loopback0

 B I    10.0.0.6/32 [200/0] via 172.16.3.253, Vlan103

 C      10.10.10.0/24 is directly connected, Management1

 C      10.180.254.16/30 is directly connected, Ethernet1

 C      10.180.254.144/30 is directly connected, Ethernet2

 C      10.180.254.232/30 is directly connected, Vlan2049

 B E    172.16.1.0/24 [200/0] via 10.180.254.17, Ethernet1

                              via 10.180.254.145, Ethernet2

 B E    172.16.2.0/24 [200/0] via 10.180.254.17, Ethernet1

                              via 10.180.254.145, Ethernet2

 C      172.16.3.0/24 is directly connected, Vlan103

 B I    192.168.1.0/24 [200/0] via 172.16.3.253, Vlan103

leaf3-sw05#

Switch6 - configuration

leaf3-sw06>en

leaf3-sw06#sh run

! Command: show running-config

! device: leaf3-sw06 (vEOS, EOS-4.15.0F)

!

! boot system flash:/vEOS-lab.swi

!

transceiver qsfp default-mode 4x10G

!

hostname leaf3-sw06

!

spanning-tree mode mstp

!

no aaa root

!

username arista privilege 15 secret 5 $1$9CoSDfo7$P9IyaxO7Ortb6FBkh93Rc/

!

vlan 103

!

vlan 2049

   trunk group mlagL5-L6

!

interface Port-Channel1

   switchport mode trunk

   switchport trunk group mlagL5-L6

!

interface Ethernet1

   no switchport

   ip address 10.180.254.22/30

!

interface Ethernet2

   no switchport

   ip address 10.180.254.150/30

!

interface Ethernet3

   channel-group 1 mode active

!

interface Ethernet4

   channel-group 1 mode active

!

interface Ethernet5

   switchport access vlan 103

!

interface Ethernet6

!

interface Loopback0

   ip address 10.0.0.6/32

!

interface Management1

   ip address 10.10.10.36/24

!

interface Vlan1

   ip address 192.168.1.2/24

!

interface Vlan103

   ip address 172.16.3.253/24

   ip virtual-router address 172.16.3.254

!

interface Vlan2049

   ip address 10.180.254.234/30

!

ip route 0.0.0.0/0 Ethernet6

ip route 0.0.0.0/0 192.168.1.254

!

ip routing

!

mlag configuration

   domain-id mlagL5-L6

   local-interface Vlan2049

   peer-address 10.180.254.233

   peer-link Port-Channel1

!

router bgp 65103

   maximum-paths 4 ecmp 128

   neighbor 10.180.254.21 remote-as 65000

   neighbor 10.180.254.21 maximum-routes 12000

   neighbor 10.180.254.149 remote-as 65000

   neighbor 10.180.254.149 maximum-routes 12000

   neighbor 172.16.3.252 remote-as 65103

   neighbor 172.16.3.252 maximum-routes 12000

   network 10.0.0.6/32

   network 10.180.254.0/24

   network 172.16.3.0/24

   network 192.168.1.0/24

!

!

end

leaf3-sw06# sh ip route

VRF name: default

Codes: C - connected, S - static, K - kernel,

       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,

       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,

       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,

       R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,

       NG - Nexthop Group Static Route

Gateway of last resort:

 S      0.0.0.0/0 [1/0] via 192.168.1.254, Vlan1

 B E    10.0.0.1/32 [200/0] via 10.180.254.21, Ethernet1

                            via 10.180.254.149, Ethernet2

 B E    10.0.0.2/32 [200/0] via 10.180.254.21, Ethernet1

 B E    10.0.0.3/32 [200/0] via 10.180.254.21, Ethernet1

                            via 10.180.254.149, Ethernet2

 B E    10.0.0.4/32 [200/0] via 10.180.254.21, Ethernet1

                            via 10.180.254.149, Ethernet2

 B I    10.0.0.5/32 [200/0] via 172.16.3.252, Vlan103

 C      10.0.0.6/32 is directly connected, Loopback0

 C      10.10.10.0/24 is directly connected, Management1

 C      10.180.254.20/30 is directly connected, Ethernet1

 C      10.180.254.148/30 is directly connected, Ethernet2

 C      10.180.254.232/30 is directly connected, Vlan2049

 B E    172.16.1.0/24 [200/0] via 10.180.254.21, Ethernet1

                              via 10.180.254.149, Ethernet2

 B E    172.16.2.0/24 [200/0] via 10.180.254.21, Ethernet1

                              via 10.180.254.149, Ethernet2

 C      172.16.3.0/24 is directly connected, Vlan103

 C      192.168.1.0/24 is directly connected, Vlan1

leaf3-sw06#