Show 196 – EVPN Introduction & Use-Cases with Russ White + Jeff Tantsura

This week, Packet Pushers’ hosts Ethan Banks and Greg Ferro queue up a discussion about a new technology, exploring EVPN with Russ White & Jeff Tantsura from Ericsson. What’s EVPN? Well, it’s short for Ethernet VPN, and it’s a way of using BGP as a routing system for MAC addresses. If that sounds like SPB […]

Author information

Ethan Banks

Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks

The post Show 196 – EVPN Introduction & Use-Cases with Russ White + Jeff Tantsura appeared first on Packet Pushers Podcast and was written by Ethan Banks.

EIGRP Query bounding.

In the process of restudying EIGRP as a protocol, and more specifically as to how it converges, you can’t avoid running into the saying “Remember to bound your queries!”.

From a conceptual point of view its fairly easy to understand that the further out you ask for a prefix the longer the convergence process will take. But what really takes place when you have different tools in place to bound the query from taking place?

There are 3 different types of “Query Bounding” techniques that can be utilized:

1) Filters (fx. distribute lists).
2) Summarization
3) Stub routers.

How do they actually work to limit the query scope?

Well, the basic premise for EIGRP queries is the fact that you are asking your fellow EIGRP neighbour for an exact prefix, fx. 172.16.1.0/25. If for any reason you EIGRP neighbour does not have this in his topology table, it will simply respond right away that it doesn’t have a path to this prefix. Query stopped right there.

By using filters such as distribute lists you are removing the prefix from ever getting advertised to the neighbour and as such he will never receive it in his topology Continue reading

Explanation: TunnelX temporarily disabled due to recursive routing

I wanted to take a few minutes to share a scenario that some seem to struggle with. This scenario is a routing issue that sometimes occurs when an interior routing protocol allows routes to leak back through a tunnel. To demonstrate this, I’ve built a lab with three routers. R1 and R3 are participating in EIGRP and have a GRE tunnel configured directly between them.

Topology

TunnelRecurse

 

Router Configurations

R1

hostname R1
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
interface Tunnel0
 ip address 192.168.13.1 255.255.255.0
 tunnel source 192.168.12.1
 tunnel destination 192.168.23.3
!
router eigrp 1
 network 192.168.0.0 0.0.255.255
!
ip route 0.0.0.0 0.0.0.0 192.168.12.2

R2 (hub)

hostname R2
!
interface FastEthernet0/1
 ip address 192.168.12.2 255.255.255.0
!
interface FastEthernet0/1
 ip address 192.168.23.2 255.255.255.0
!

R3

hostname R3
!
interface FastEthernet0/1
 ip address 192.168.23.3 255.255.255.0
!
interface Tunnel0
 ip address 192.168.13.3 255.255.255.0
 tunnel source 192.168.23.3
 tunnel destination 192.168.12. Continue reading

VyOS x64 Installation on Qemu

VyOS is a community fork of Vyatta, a Linux-based network operating system that provides software-based network routing, firewall, and VPN functionality. The VyOS project was started in late 2013 as a community fork of the GPL portions of Vyatta Core 6.6R1 with the goal of maintaining a free and open source network operating system in response to the decision to discontinue the community edition of Vyatta.

VyOS runs on both physical and virtual platforms. It supports paravirtual drivers and integration packages for virtual platforms. It is completely free and open source.

The aim of the tutorial is to show VyOS installation on Qemu virtual machine and  get it working on GNS3.

VyOS Qemu and VirtualBox virtual disks can be downloaded here.

I created a Bash script deploy_vyos for automatic deployment of VyOS to Qemu image. The script downloads stable VyOS ISO image from the Internet,  creates Qemu disk and starts Qemu virtual machine with attached ISO image. Then is  starts Expect script install_vyos that automatically configure all required configuration options  without user intervention.

deploy_vyos
install_vyos

Just copy both scripts to the same directory, assign run privileges to both scripts with the command below and run the deploy_vyos script.

$ chmod +x Continue reading

Confessions of a Troubleshooting Junkie

“Hey Fish, how good are you at BFD? None of my BFD neighbors will come up.” Two simple sentences and I am “hooked.”  I love troubleshooting!   Troubleshooting is just a blast for me!  It’s like being a Network Detective trying to figure out “whodunit” As I sit down in front of the CLI and the […]

Author information

Denise "Fish" Fishburne

Denise "Fish" Fishburne
CPOC Engineer at Cisco Systems

Denise "Fish" Fishburne, (CCIE #2639, CCDE #2009:0014, Cisco Champion) is a team lead with Cisco's Customer Proof of Concept Lab in Research Triangle Park, N.C. Fish loves playing in the lab, troubleshooting, learning, and passing it on.

The post Confessions of a Troubleshooting Junkie appeared first on Packet Pushers Podcast and was written by Denise "Fish" Fishburne.

Physical Networks in the Virtualized Networking World

[This post was co-authored by Bruce Davie and Ken Duda]

Almost a year ago, we wrote a first post about our efforts to build virtual networks that span both virtual and physical resources. As we’ve moved beyond the first proofs of concept to customer trials for our combined solution, this post serves to provide an update on where we see the interaction between virtual and physical worlds heading.

Our overall approach to connecting physical and virtual resources can be viewed in two main categories:

  • terminating the overlay on physical devices, such as top-of-rack switches, routers, appliances, etc.
  • managing interactions between the overlay and the physical devices that provide the underlay.

The latter topic is something we’ve addressed in some other recent posts (herehere and here) — in this blog we’ll focus more on how we deal with physical devices at the edge of the overlay.

We first started working to design a control plane to terminate network virtualization overlays on physical devices in 2012. We started by looking at the information model, defining what information needed to be exchanged between a physical device and a network virtualization controller such as NSX. To bound the problem space, Continue reading

Courage to change things

This was an internal email that I sent to the CloudFlare team about how we are not afraid to throw away old code. We thought it was worth sharing with a wider audience.

Date: Thu, 10 Jul 2014 10:24:21 +0100
Subject: Courage to change things
From: John Graham-Cumming
To: Everyone

Folks,

At the Q3 planning meeting I started by making some remarks about how much
code we are changing at CloudFlare. I understand that there were audio
problems and people may not have heard these clearly, so I'm just going to
reiterate them in writing.

One of the things that CloudFlare is being brave about is looking at old code
and deciding to rewrite it. Lots of companies live with legacy code and build
on it and it eventuallybecomes a maintenance nightmare and slows the company
down.

Over the last year we've made major strides in rewriting parts of our code
base so that they are faster, more maintainable, and easier to enhance. There
are many parts of the Q3 roadmap that include replacing old parts of our
stack. This is incredibly important as it enables us to be more agile and 
more stable in future.

We should feel good  Continue reading

Potential Issues with Multicast within a VLAN Spanning Switches

Background

I ran into an interesting issue yesterday at work. There is a new video system
being installed, which takes the video output from computers, encodes it and
sends it as multicast to a controller. The controller then displays it on
a video wall. I had been told that the network has to support multicast.
As all the devices were residing in the same VLAN, I did not expect any issues.
However, the system was not able to receive the multicast. At first we expected
it could be the virtual environment and that the vSwitch did not support multicast,
because one server was deployed on the ESX cluster. The topology was this:

Snooping1

Multicast at Layer 2

Before describing the issue, let’s think about how multicast at layer 2 works.
The source will send to a multicast destination IP. This IP is the converted to a
destination MAC address. If the group is 227.0.0.1, this would map to the MAC
address 0100.5e00.0001. Switches forward multicast and broadcast frames to all
ports in a VLAN. This is not effective in the case of multicast as the traffic
may not have been requested by the host connected to Continue reading

CloudFlare Joins Three More Peering Exchanges in Australia

In the coming weeks, connectivity to CloudFlare in Australia is going to a new level. As part of CloudFlare’s ongoing upgrades program, we established connections to three new Internet exchanges: the Megaport Internet exchanges in Sydney, Brisbane, and Melbourne. These connections doubled the number of Australian Internet exchanges we reach and marked the first exchanges outside of Sydney that Cloudflare participates in.

What is Peering?

When two ISPs peer, they agree to exchange traffic directly between each other rather than sending it a third party. By doing this, both partners avoid congested paths between transit providers, and they avoid paying to ship traffic—it's win-win!

What peering exchanges mean for CloudFlare is that we can significantly increase our service performance to users on ISPs that peer with us. Take Australia for example, for users who are currently on ISPs peering at Megaport, instead of CloudFlare sending traffic to the transit providers of those ISPs, we can now route the traffic directly to them. The result is lower latency, and traffic taking paths that are often less congested.

Low latency is crucial for internet speed due to the nature of TCP, the fundamental protocol on which the internet is built. TCP operates Continue reading

Summary Post – Methods to Manipulate OSPF Costs

There are three ways to manipulate the interface cost in OSPF.  One is very direct, one changes the presentation of the interface, and the other changes the calculations for every interface.

Set the cost of the interface directly – Just give it the number you want.  Easy.  This is the number OSPF will use in the SPF calculations without doing any math on the interface.

R1(config-if)#ip ospf cost 8482

Set the bandwidth of the interface – The formula that OSPF uses to calculate interface cost is pretty easy to remember – (reference bandwidth) / (interface bandwidth).  Changing the interface bandwidth will obviously change the result of the calculation.  The same caveat for EIGRP route manipulation holds true here; if you change the bandwidth of the interface, you may affect other things like QoS…or EIGRP, now that I mention it.

R1#sh ip ospf inter brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0        1     0               192.0.2.1/24       10    DR    0/0
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int f0/0
R1(config-if)#bandwidth 10
R1(config-if)#do show ip ospf interf brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0        1     0               192.0.2.1/24        Continue reading

CCIE RSv5 ATC & Baby 3.0 Status Update

Tomorrow’s CCIE Routing & Switching Advanced Technologies Class v5 is postponed, as baby 3.0’s shipping date has arrived ;)   Class will tentatively return the week of July 21st, however I will post more information and updates about workbook changes before that.

In the meantime the current CCIE RSv5 ATC streaming playlist can be found here, and the download playlist can be found here. Some videos are still in post processing and will be posted within the next few days.

Although we’re only in week 47 of the class (or so it seems), we’ve put a huge dent in the overall topic scope so far.  You can see our current progress in the overall CCIE RSv5 Expanded Blueprint here.  Some of topics that haven’t been covered in the v5 ATC officially yet can be found in the CCIE RSv4 ATC and the RSv4 to RSv5 Transition Technologies addendum at the end of that playlist.

RouterOS x86 Qemu and VirtualBox Appliances Download

MikroTik RouterOS is the stand-alone operating system of MikroTik RouterBOARD hardware. It can also be installed on a PC and will turn it into a router with all the necessary features – routing, firewall, bandwidth, management, wireless access point, backhaul link, hotspot, gateway, VPN server and more.

RouterOS x86 installed on Qemu and VirtualBox disks is not licensed, you have 24 hours in total to run these images.

login/pass: admin / password is not set

1. RouterOS x86 6.15

Qemu
https://drive.google.com/file/d/0B6L2h6R5UKMhQUcxMFl2a1pZZGs/edit?usp=sharing
http://sourceforge.net/projects/gns-3/files/Qemu%20Appliances/routeros-6.15-qemu.zip/download
http://www.4shared.com/zip/HG7nubJlba/routeros-615-qemu.html

VirtualBox
https://drive.google.com/file/d/0B6L2h6R5UKMhODYyNm0tWnFjXzA/edit?usp=sharingv
http://sourceforge.net/projects/gns-3/files/VirtualBox%20Appliances/routeros-6.15-vbox.zip/download
http://www.4shared.com/zip/qPN2tmD7ba/routeros-615-vbox.html

SPAN Destination ports and VLAN Membership

Recently at work, a discussion sprouted up around how to handle/configure local session Switched Port Analyzer (SPAN) destination ports.  A suggestion was made to create a new VLAN just for these SPAN destination ports and place them there.  The justification was that they would be out of VLAN 1, and easily identifiable.  Personally I thought it was a waste of a VLAN for a few simple SPAN destination ports, as SPAN destination ports do not participate in spanning tree, and do not forward traffic.  However, ultimately in this case it was a good decision due to security requirements.
Some key characteristics to know about SPAN destination ports:
  • A destination port can be a physical port that is assigned to an EtherChannel group, even if the EtherChannel group has been specified as a SPAN source. The port is removed from the group while it is configured as a SPAN destination port.
  • The port does not transmit any traffic except that traffic required for the SPAN session unless learning is enabled.
  • The state of the destination port is up/down by design. The interface shows the port in this state in order to make it evident that the port Continue reading

Summary Post – OSPF Network Statement Order and Matching

When you configure OSPF network statements, IOS orders them most-specific to least-specific then does a top-to-bottom match of the interfaces. It doesn’t matter which order you put them in, the configuration will always be ordered with the longest prefix matches first.  Lab time!

I have router R1 with these interfaces.

R1#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            10.0.0.1        YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Loopback100                10.0.101.1      YES manual up                    up
Loopback200                10.2.101.1      YES manual up                    up

Let’s add the OSPF configuration where 10.0.0.0/8 is in area 2 then check what OSPF thinks is happening.

R1(config)#router ospf 1
R1(config-router)#network 10.0.0.0 0.255.255.255 area 2
...
R1#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo100        1     2               10.0.101.1/24      1     LOOP  0/0
Lo200        1     2               10.2.101.1/24      1     LOOP  0/0
Fa0/0        1     2               10.0.0.1/24        10    WAIT  0/0

All the interfaces are in area 2 as expected. Now let’s add 10.0.0.0/16 into area 1 to see what happens.

R1(config-router)#network 10.0.0.0  Continue reading

NSA: walk a mile in their shoes

While this is mostly a technical blog, our most popular posts deal with cyber-rights, supporting Snowden, Weev, and Swartz. Yet sometimes I appear to defend the NSA. People ask me why, so I thought I’d write up a response.

Most American schools force students to read the book To Kill a Mockingbird. It’s a great book for many reasons. Most people think it’s about racism, but it’s not – it’s about bigotry. Racism is just one of the forms of bigotry found in the book. The full message, repeated several times, is that we should get along with others by trying to understand their point of view.

Our society is improving with regards to racism, but other forms of bigotry are alive and well. Webster’s defines bigotry as: “obstinate and unreasoning attachment of one's own belief and opinions, with narrow-minded intolerance of beliefs opposed to them”. Our society praises such bigotry. Tolerance and understanding of other opinions is condemned.

People like Glenn Greenwald, Jacob Appelbaum, and others in the ‘activist’ movement are extreme bigots. There is good reason to oppose the NSA and its leaders who have egregiously mislead the public. Yet, this is still not justification for Continue reading

SDN Started as a Customer Movement (Not a Vendor Innovation)

With the vast marketing budgets from big vendors and their well paid "evangelists", the startups vying to introduce new methods and the clamour of engineers trying to understand new technology it might be time to pause and remember that Software Defined Networking was a customer-driven initiative. Vendors had to be forced to accept that SDN was a necessary change.

The post SDN Started as a Customer Movement (Not a Vendor Innovation) appeared first on EtherealMind.

Response: RFC 7045 – Transmission and Processing of IPv6 Extension Headers

IETF RFC  on the Standards Tracks that talks about the problem of chaining headers in IPv6. I’m getting a sense of deja-vu since this was also has issue with IPv4 and, ultimately, use of chained IPv4 headers died away. If they encounter an unrecognised extension header type, some firewalls treat the packet as suspect and drop it.  Unfortunately, […]

The post Response: RFC 7045 – Transmission and Processing of IPv6 Extension Headers appeared first on EtherealMind.

What is Unidirectional Automation?

I was pleased as punch to wake up the other day and read Marten Terpstra’s blog post on getting over the fear of using automation to make changes on our network infrastructure. He illuminated a popular excuse that I’ve heard myself on multiple occasions – that automation is great for things like threshold alarms, or pointing out the percieved root cause of a problem, but not actually fixing the problem. The idea is that the problems that occur on a regular basis, or even performing configuration changes in the first place – is a specialized task that a warm-blooded human being absolutely, no-doubt must take total control of in order to be successful.1266464746097 What is Unidirectional Automation?

With the right implementation, this idea is, of course, rubbish. I asked a question on Twitter not too long ago in preparation for a presentation I was about to give. I have a decent amount of experience working with VMware vSphere, and knew there were some experienced server virtualization folks following me, so I asked about a feature that was thought of in similar light not too long ago: