Tuesday, May 30, 2017

Protect The LAN: IPv6 RA Guard

So while nerding on YouTube, one of my favorite YouTubers Quidsup did a demonstration of using Kali Linux to perform a pretty nifty denial of service attack against Windows 10. The attack has some minor caveats, but none the less is dangerous and relatively easy to pull off. It works by flooding the connected network segment with IPv6 router advertisements (RA). IPv6 RAs assist in stateless autoconfiguration, so that IPv6 hosts on the network can assign themselves an IP, and can also carry default router information. However, since hosts can have multiple IPv6 addresses, Windows ends up trying to autoconfigure an IPv6 address for every RA is receives. This results in pretty hefty CPU spikes, as well as the NIC being completely unresponsive. However; Cisco has a pretty neat little trick we can implement on our access layer switches to mitigate these types of attacks. Based on the title of this blog, I'm sure you guessed what that feature is; RA Guard.

I like to think of RA Guard as being somewhat akin to DHCP snooping. We build a policy, assign said policy to switch ports, and RA Guard will drop unauthorized RAs. The configuration is fairly straight forward, but seeing the difference it can make when implemented is impressive. See video below :-).



Tuesday, May 2, 2017

CCIE status suspended (but then got it back)

So that happened. Now, I know what some of you are thinking based on the title of this post alone.


That's fair. The truth of the matter is, 2yrs sneaks up on you (or at least snuck up on me) really fast. After I passed the lab in 2015, all I wanted in the world was a break. At that point, not many days had gone by that I hadn't thought of, talked about, or studied for my route switch lab. While I love R/S, and find the technologies incredibly interesting, it just isn't my only interest. Not even within the technology field. There were so many other things I wanted to learn, and to be honest... a lot of video games, TV shows, and general lounging about I felt I had missed out on.

Immediately after passing the lab, I sought to do (2) things. First and foremost, catch up on some seriously overdue slacking off time. I bought video games. So many games. I wanted to watch every TV show I had casually overheard co-workers or friends talking about. Secondly, I wanted to start learning something new. Not necessarily to the degree of a CCIE, but just something different. After a few months went by, I started feeling the itch to start working on something new. At that time I was really struggling to find something to scratch that itch. I felt like I didn't want to recertify in R/S, but if not R/S then what?

Data Center

Data Center... DataCenter... Data Centre? I didn't care, I had deployed a handful of Nexus switches. I thought (and still think) VPC and FabricPath were pretty cool. However after a few months, I started realizing that I was interested quite enough to justify going much further with it. That's not to say I'm ruling out CCNP DC, just I didn't see going after the DC written a path forward.

Service Provider

Oh SP, how much I still wish I could have made this make sense for me. It gets all my nerd juices going. For me studying SP was like all my favorite parts of R/S, but on steroids. MPLS is hands down one of my favorite topics, so from an interest level, this made perfect sense. However, after 6 months or so (yeah... 6 months lol), I started realizing that it didn't make much practical sense. I love the technology, but when would I ever get to use this knowledge? I don't work with ISPs often, and I have zero interest in working full time for one. I do work with large enterprise networks that run MPLS internally on occasion, but the R/S material is more than sufficient to support that. So that left me wondering if I could find something I both found interesting and had practical career applications.

Security

The upsides, I was already pretty versed on the ASA and IOS security measures. The downsides. at this time Security v5 had been announced and I knew that I couldn't wait for v5 to be released (January 31st 2017) because there's no way material for that exam would be out in enough time for me to prepare for the written before my number expired April 1st 2017. That left me with a narrow window to learn v4 of the lab (which had a fair bit of older technology). But I decided to go for it, I'd spend 3-4 months prepping for v4  security written, and make my first attempt in December of 2016. My thinking there, that would give me enough time to reasonably be ready for the test, but also enough time that if I failed I could retake before Cisco retired the exam.

Bad News Bears.

I wasn't ready for the v4 written in December, and I only had enough time for (1) retake before the exam retired. Which I also failed lol. Meaning there was no choice to keep my number in active status aside from taking the written for R/S. However, in February I decided I wouldn't do that. I figured "Who cares, I'll let my number go into suspended status until I can pass the v5 security written." Well, turns out I care. The day I got the email from ccie@cisco.com saying CCIE status was now suspended I instantly freaked out. Really really hard.

Routing & Switching

So after a couple weeks of getting back up to speed on R/S written material (c'mon, like you expect me to work with IS-IS and Multicast routing everyday), I sat for my R/S written last Friday and passed. It was a bitter sweet moment, on the one hand I got my number back in active status, and all the perks that come with that. On the other hand, I felt like I spent my first two years as an IE spinning my tires. So what now? Security, I'm coming for you. As for this blog, I'm back here as well. Focused on R/S, SP, and Security technologies just like before. 





In keeping with my ususal standard of blogging, I'm not proof reading this post until much much later. Have fun grammar Nazis. 

















Wednesday, January 18, 2017

I'm Alive!!

Just thought that'd be worth sharing... I guess. CCIE Security studies have been consuming most of my time. However, I'm just about at the point where I can publish some stuff. I've had drafts for my FlexVPN with dynamic spoke-to-spoke tunnels sitting in draft for months now. So that'll likely come first, after that I may get into some FirePOWER posts.


Monday, August 15, 2016

Dynamic Site-2-Site VPNs with Cisco ASA

So let's take a moment and assume your life is too easy, and you want to punish yourself. But how?! Here's a way, let's use the ASA for sites-2-site VPN. Even better, the spoke sites have be able to have dynamic IPs, and also need connectivity to other spokes. Also, IKEv2. Just because. Everyone ready?! I know I am.




Honestly, it's actually incredibly easy. If you're not familiar with the ASA's ability to form dynamic L2L tunnels this post might be an eye opener. The tricky part is getting spoke to spoke connectivity in a reasonable fashion. However, we'll cross that bridge when we come to it. Let's look at the amazingly complex and overwhelming topology we'll be working with today.


Give yourself a few minutes to study all the minute details. Alright, let's get the hub configured. Luckily this is actually really easy.

crypto ikev2 policy 10
 encryption aes-256
 integrity sha512
 group 2
 prf sha      
 lifetime seconds 28800
!
crypto ikev2 enable OUTSIDE
!
crypto ipsec ikev2 ipsec-proposal AES256
 protocol esp encryption aes-256
 protocol esp integrity sha-512
!
crypto ipsec security-association lifetime seconds 3600
!
crypto dynamic-map DYNAMIC-S2S 1 set pfs 
crypto dynamic-map DYNAMIC-S2S 1 set ikev2 ipsec-proposal AES256
crypto dynamic-map DYNAMIC-S2S 1 set reverse-route
crypto map VPNMAP 65535 ipsec-isakmp dynamic DYNAMIC-S2S
crypto map VPNMAP interface OUTSIDE
!
tunnel-group DefaultL2LGroup ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco123
 ikev2 local-authentication pre-shared-key cisco123

That's about it for the crypto. The tunnel-group name has to be DefaultL2LGroup. One thing of particular note that I do not care for, with this model any dynamic tunnel peers have to share the same PSK. You'll also take notice I didn't specify any interesting traffic, nor did I set any peers. I also really like using reverse-route to inject static routes into the RIB, if you're going to do that on the Hub just keep in mind you have to do this under the dynamic map.

Now on the Hub, let's setup our nat exempt which will look a little different than it does on spoke ASAs.


object-group network ALLSITES
 network-object 192.168.1.0 255.255.255.0
 network-object 192.168.2.0 255.255.255.0
 network-object 192.168.3.0 255.255.255.0
!
nat (any,OUTSIDE) source static ALLSITES ALLSITES destination static ALLSITES ALLSITES
!

So pretty basic, we're just using a single object-group with our subnets included. Then in the actual NAT configuration we're saying the internal nameif is "any". This is because as traffic transits the hub from spoke-2-spoke, we want this policy to pick that up along with traffic from the Hub's inside to Spokes. Alternatively, you could have separate NAT statements. One for (INSIDE,OUTSIDE) and another for (OUTSIDE,OUTSIDE). The later of which being for spoke-2-spoke communication. Alright! Moving along, the config on the spokes looks a little something like this.

crypto ikev2 policy 10
 encryption aes-256
 integrity sha512
 group 2
 prf sha      
 lifetime seconds 28800
!
crypto ikev2 enable OUTSIDE
!
crypto ipsec ikev2 ipsec-proposal AES256
 protocol esp encryption aes-256
 protocol esp integrity sha-512
!
crypto ipsec security-association lifetime seconds 3600
!
object-group network LAN

 network-object 192.168.2.0 255.255.255.0
!
access-list L2LVPN extended permit ip object-group S2 192.168.0.0 255.255.0.0 
!
crypto map VPNMAP 1 match address L2LVPN
crypto map VPNMAP 1 set pfs 
crypto map VPNMAP 1 set peer 200.1.1.1 
crypto map VPNMAP 1 set ikev2 ipsec-proposal AES256

crypto map VPNMAP interface OUTSIDE
!
tunnel-group 200.1.1.1 type ipsec-l2l
tunnel-group 200.1.1.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco123

 ikev2 local-authentication pre-shared-key cisco123
!
nat (INSIDE,OUTSIDE) source static ALLSITES ALLSITES destination static ALLSITES ALLSITES
!


That's right, stock standard L2L VPN tunnel back to the hub. The above config is applied to ASAv2, however the only change in the configuration on ASAv3 is in "object-group network LAN", instead of 192.168.2.0, ASAv3 has 192.168.3.0. For our interesting traffic we're saying anything from our local subnet going to 192.168.0.0/16. This is pretty important, in order to have consistent and mostly reliable communication between spokes, we need the SA formed with the hub to also cover traffic to other spokes. I demonstrated why in my video below. The quick and dirty answer is, the Hub doesn't build tunnels outbound. Just by design, it's responder only within the DefaultL2LGroup tunnel. So while ASAv2 will build it's SA for S2>>S3 to the Hub, the Hub can't actually build the second half of that connection. Leaving you seeing a single SA for 192.168.2.0>>192.168.3.0 with the peer being ASAv2. The hub can receive that traffic, but will be unable to build the new SA out to S3 to actually forward it along. Again though, this is a non-issue if your Spokes are building tunnels where the destination covers all remote spoke subnets.


Well I could ramble on a bit longer, but that's the jist of it boys and girls. Linking the video below.


Sunday, July 31, 2016

How to Not Suck at Web Filtering: Cisco's Web Security Appliance Part (1)

So I'll start off by saying, configuring the WSA isn't too terribly hard. What seems to be tricky, is getting all the components working together in a way that provides a seamless experience for users, while providing accurate reporting and filtering. In this two parter, I'm going to attempt to get us from a based environment (Active Directory Domain, (1) DC, (1) Client PC, and an ASA Firewall) all the way to having the following requirements met: 

  • HTTP Filtering
  • HTTPS Filtering/Decrypting
  • Transparent Proxy 
  • AD Integration
  • Single Sign-on

Again, none of this is too difficult, there's just a lot of moving pieces. Sadly, many of those pieces are on the Systems side. So buckle up! In this first part, we're going to kick out all the server side stuff that makes web filtering as transparent and effective as possible. I know, I know "But JJoooooonnnnnnnn, this is a networking blog!! I don't like doing systems work!!"




I don't like it anymore than you. That said, it's important to know all these things so you can accurately make demands of your Server team! Also, if you want a working lab or POC, you'll have to do this stuff anyway. That said, I'm not a fan of text only guides for Windows. They just don't translate well, AND I loathe taking a million screen shots. So, I'll outline the general tasks below and then link to my YouTube video for this 1st part.


Prereqs:
  1. Windows Server 2008 (or newer) Domain Controller
  2. Windows 7 (or newer) client, joined to the domain
  3. Cisco ASA or IOS Router with WCCP support
  4. Cisco Web Security Appliance (using WSAv w/45 day demo license for this post)

Ingredients:
  • Active Directory Certificate Services (Enterprise Root)
    • Web Enrollment supported
  • Root CA certificate for WSA (or any cert with Subject Type=CA)
  • Server Certificate for WSA
  • URL to WSA in Window's "Trusted Sites"
    • Trusted Sites set to "Automatic Logon with Current Username and Password"
    • Can be done with GP, login script, or manually.
  • WSA joined to AD domain
  • Identification Policies for AD Users
    • And whatever access policies based on users/groups.
  • WCCP configured on router/firewall to redirect http/https traffic to WSA.

Video:



Monday, June 20, 2016

Using VXLAN to extend my home lab

So first off, I recently had a change of heart. While I still love Service Provider, I'm continually being pulled in for Security work. So, I've decided to stop resisting and follow the current. That said, CCIE Security (both v4 and v5) have some heavy demands. While my home server has plenty of RAM (96GB) and CPU... I ran out of disk space really fast. So naturally, I ordered some new 1TB drives to help out, but does that mean I should stop studying until the drives arrive?? No.




My workstation upstairs (server is in the garage) has 32GB of RAM, plenty of spare disk space... but how to get my VMs to appear on the same VLANs as VMs running downstairs in the garage. Let's look at the problem really quick.


So, essentially I need to get VM traffic from my host machine, over a wireless bridge, through my 5506, past my lab switch (c4948). There's a couple different ways to do this, but I kept gravitating towards VXLAN. My initial thought was to use a vswitch like vEOS to get the job done. After some light testing, I found that while it did pass traffic the performance was just absolutely awful. I need these VMs to be able to access web services, pull up GUIs from WSA, etc. So vEOS was out the window. Next up was CSR1000v. This guy would probably work... but I was out of demo licenses, and the unlicensed CSR1Kv is limited to 100kb/s. So that's a hard nope. Then it dawned on me... what about Open vSwitch? Granted, it's an openflow switch and without a controller would need some love, BUT the flows I'd need to get my lab working wouldn't be too complicated. So I gave it a go, here's the high level topology.



Essentially on the firewall I just needed to add a rule permitting the eth0 interface for ovs-vtep1 to send udp/4789 to ovs-vtep2's eth0 interface. Additionally, I only needed (2) segments, so instead of working with VLANs I just allocated 2 physically interfaces to each OVS server (Ubuntu 16.04 w/ 1GB of RAM). Then end result was very impressive. I won't go in depth for installing open vswitch in Ubuntu, since it's in the repositories. However, let's look at the config to get my OVS setup up and running. I have (2) VLANs I'm concerned about, VL37 and VL36. Again, OVS isn't doing any tagging (leaving that to vsphere) but I decided to use the VLAN numbers as my vxlan VNIs to keep things simple. So, I'll share the config below then we can break it down.

ovs-vtep1

jonmajor@ovs-vtep1:~$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0c:29:1d:cc:c3  
          inet addr:172.17.0.51  Bcast:172.17.0.255  Mask:255.255.255.0
{...}
!
sudo ifconfig eth1 up
sudo ifconfig eth2 up
!

sudo ovs-vsctl add-br BR1
sudo ovs-vsctl add-port BR1 eth1 -- set interface eth1 ofport_request=1
sudo ovs-vsctl add-port BR1 eth2 -- set interface eth2 ofport_request=2
sudo ovs-vsctl add-port BR1 vtep -- set interface vtep type=vxlan option:remote_ip=172.16.255.51 option:key=flow ofport_request=10
!
!

jonmajor@ovs-vtep1:~$ sudo ovs-vsctl show
e208bb8b-0adc-4d4e-b883-7819a8b63b35
    Bridge "BR1"
        Port "eth1"
            Interface "eth1"
        Port vtep
            Interface vtep
                type: vxlan
                options: {key=flow, remote_ip="172.16.255.51"}
        Port "eth2"
            Interface "eth2"
        Port "BR1"
            Interface "BR1"
                type: internal
     ovs_version: "2.5.0"



ovs-vtep2


jonmajor@ovs-vtep2:~$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0c:29:a9:fb:41  
          inet addr:172.16.255.51  Bcast:172.16.255.255  Mask:255.255.255.0
{...}
!
sudo ifconfig eth1 up
sudo ifconfig eth2 up
!
sudo ovs-vsctl add-br BR1
sudo ovs-vsctl add-port BR1 eth1 -- set interface eth1 ofport_request=1
sudo ovs-vsctl add-port BR1 eth2 -- set interface eth2 ofport_request=2
sudo ovs-vsctl add-port BR1 vtep -- set interface vtep type=vxlan option:remote_ip=172.17.0.51 option:key=flow ofport_request=10
!
!

jonmajor@ovs-vtep2:~$ sudo ovs-vsctl show
c6a89e34-e0e8-41c7-b20d-fd38a262ecab
    Bridge "BR1"
        Port "eth1"
            Interface "eth1"
        Port "eth2"
            Interface "eth2"
        Port vtep
            Interface vtep
                type: vxlan
                options: {key=flow, remote_ip="172.17.0.51"}
        Port "BR1"
            Interface "BR1"
                type: internal

    ovs_version: "2.5.0"


Alright, so what just happened?! Fairly straight forward actually. The (1)st thing I did was bring up eth1 and eth2 interfaces, these are the ports facing my VMs on vtep2 and on vtep1 they're connecting to vsphere on two different port groups where they get their vlan tags. (2)nd,  I created my ovs bridge "BR1" with "ovs-vsctl add-br BR1". (3)rd, I added my ethernet interfaces and created/added a VXLAN interface called "vtep" to the bridge. Ofport_request,  I'm specifying the openflow port number. This will be handy in the next step when I define my flows. So I mapped Eth1 to ofport 1, Eth2 to ofport2, and the vxlan interface to ofport 10. Easy enough right?

So here's where you can get into trouble with OVS if you're not familiar with it. VXLAN doesn't define a control plane protocol, so each vendor does things a little differently. Cisco for example has largely been leveraging multicast for unknown unicast and broadcast traffic between vteps (there is support for BGP to exchange this information now). Open vSwitch, being a switch designed to work with openflow, doesn't have this functionality. You have to specifically tell it how to forward unicast frames, and ARP traffic. If you just let it forward anything, you'll quickly have a bridging loop. Especially if you try to add more than (2) VTEPs. So that said, we need a couple flows defined on each OVS. We need to tell OVS how to forward unicast traffic for local and remote devices, AND we need to tell it how to handle ARP traffic. So I have my flows defined in a text file on each server, and can load them in with a single command. Let's take a quick look then break it down.

ovs-vtep1

jonmajor@ovs-vtep1:~$ sudo su
!
root@ovs-vtep1:/home/jonmajor# cd ~
!
root@ovs-vtep1:~# cat wsa_lab.txt 
table=0,in_port=1,actions=set_field:37->tun_id,resubmit(,1)
table=0,in_port=2,actions=set_field:36->tun_id,resubmit(,1)
table=0,actions=resubmit(,1)
table=1,tun_id=37,dl_dst=00:0c:29:d9:5f:c4,actions=output:10
table=1,tun_id=37,dl_dst=00:1b:0c:0c:9b:bf,actions=output:1
table=1,tun_id=37,arp,nw_dst=136.1.37.100,actions=output:10
table=1,tun_id=37,arp,nw_dst=136.1.37.1,actions=output:1
table=1,tun_id=36,dl_dst=00:0c:29:db:bf:b5,actions=output:10
table=1,tun_id=36,dl_dst=00:1b:0c:0c:9b:bf,actions=output:2
table=1,tun_id=36,arp,nw_dst=172.16.20.100,actions=output:10
table=1,tun_id=36,arp,nw_dst=172.16.20.1,actions=output:2
table=1,priority=100,actions=drop
!
!

root@ovs-vtep1:~# ovs-ofctl dump-flows BR1
NXST_FLOW reply (xid=0x4):
!
root@ovs-vtep1:~# ovs-ofctl add-flows BR1 wsa_lab.txt 



ovs-vtep2

jonmajor@ovs-vtep2:~$ sudo su
!
root@ovs-vtep2:/home/jonmajor# cd ~
!
root@ovs-vtep2:~# cat wsa_lab.txt 
table=0,in_port=1,actions=set_field:37->tun_id,resubmit(,1)
table=0,in_port=2,actions=set_field:36->tun_id,resubmit(,1)
table=0,actions=resubmit(,1)
table=1,tun_id=37,dl_dst=00:0c:29:d9:5f:c4,actions=output:1
table=1,tun_id=37,dl_dst=00:1b:0c:0c:9b:bf,actions=output:10
table=1,tun_id=37,arp,nw_dst=136.1.37.100,actions=output:1
table=1,tun_id=37,arp,nw_dst=136.1.37.1,actions=output:10
table=1,tun_id=36,dl_dst=00:0c:29:db:bf:b5,actions=output:2
table=1,tun_id=36,dl_dst=00:1b:0c:0c:9b:bf,actions=output:10
table=1,tun_id=36,arp,nw_dst=172.16.20.100,actions=output:2
table=1,tun_id=36,arp,nw_dst=172.16.20.1,actions=output:10
table=1,priority=100,actions=drop
!
!
root@ovs-vtep2:~# ovs-ofctl dump-flows BR1
NXST_FLOW reply (xid=0x4):
!
root@ovs-vtep2:~# ovs-ofctl add-flows BR1 wsa_lab.txt 


First time I saw flow entries, I was hot in the face (angry). The above can look a little daunting at first, but if we take a minute to break it down it's not that bad. So, notice the first three lines of "wsa_lab.txt". Remember above where I specified which openflow ports Eth1 and Eth2 were mapped to? This is where that starts becoming important. The first line I'm saying "traffic coming in ofport 1 needs to get a tunnel id (vxlan vni) of 37. Then, after adding that id, please forward the traffic to table 1." The same logic applies for the second line, when traffic comes in ofport 2 (eth2), add tunnel id 36 and then continue processing traffic in table 1. The third rule is just a catch all for table 0, resubmitting to table 1. Now, in table 1 we're doing some interesting stuff. First I'm mapping where to forward traffic based on destination mac addresses. When the output is :1 or :2, those are my local ports eth1 and eth2. If the output is :10, remember from above that's the vxlan interface we named "vtep". In addition to mapping unicast traffic based on dest. mac address, we also need to map ARP traffic, which you'll see done above. If the arp req is for a node connected locally, forward out either port 1 or 2 depending on the dst IP. If for a remote node, forward out port 10. Notice also, for better segmentation, these flow entries are also matching on tun_id (vxlan vni). Lastly, if the traffic doesn't match any of my flow rules, drop it "table=1,priority=100,action=drop".

Finally, we actually load these flows into the vswitch with "ovs-ofctl add-flows BR1 wsa_lab.txt". I can verify that with "ovs-ofctl dump-flows BR1".

ovs-vtep1

root@ovs-vtep1:~# ovs-ofctl dump-flows BR1            
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1.456s, table=0, n_packets=0, n_bytes=0, idle_age=1, in_port=1 actions=load:0x25->NXM_NX_TUN_ID[],resubmit(,1)
 cookie=0x0, duration=1.456s, table=0, n_packets=0, n_bytes=0, idle_age=1, in_port=2 actions=load:0x24->NXM_NX_TUN_ID[],resubmit(,1)
 cookie=0x0, duration=1.456s, table=0, n_packets=0, n_bytes=0, idle_age=1, actions=resubmit(,1)
 cookie=0x0, duration=1.456s, table=1, n_packets=0, n_bytes=0, idle_age=1, tun_id=0x25,dl_dst=00:0c:29:d9:5f:c4 actions=output:10
 cookie=0x0, duration=1.455s, table=1, n_packets=0, n_bytes=0, idle_age=1, tun_id=0x25,dl_dst=00:1b:0c:0c:9b:bf actions=output:1
 cookie=0x0, duration=1.454s, table=1, n_packets=0, n_bytes=0, idle_age=1, tun_id=0x24,dl_dst=00:0c:29:db:bf:b5 actions=output:10
 cookie=0x0, duration=1.454s, table=1, n_packets=0, n_bytes=0, idle_age=1, tun_id=0x24,dl_dst=00:1b:0c:0c:9b:bf actions=output:2
 cookie=0x0, duration=1.455s, table=1, n_packets=0, n_bytes=0, idle_age=1, arp,tun_id=0x25,arp_tpa=136.1.37.100 actions=output:10
 cookie=0x0, duration=1.455s, table=1, n_packets=0, n_bytes=0, idle_age=1, arp,tun_id=0x25,arp_tpa=136.1.37.1 actions=output:1
 cookie=0x0, duration=1.454s, table=1, n_packets=0, n_bytes=0, idle_age=1, arp,tun_id=0x24,arp_tpa=172.16.20.100 actions=output:10
 cookie=0x0, duration=1.454s, table=1, n_packets=0, n_bytes=0, idle_age=1, arp,tun_id=0x24,arp_tpa=172.16.20.1 actions=output:2

 cookie=0x0, duration=1.453s, table=1, n_packets=0, n_bytes=0, idle_age=1, priority=100 actions=drop

ovs-vtep2

root@ovs-vtep2:~# ovs-ofctl dump-flows BR1             
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=2.056s, table=0, n_packets=3, n_bytes=180, idle_age=0, in_port=1 actions=load:0x25->NXM_NX_TUN_ID[],resubmit(,1)
 cookie=0x0, duration=2.056s, table=0, n_packets=1, n_bytes=161, idle_age=0, in_port=2 actions=load:0x24->NXM_NX_TUN_ID[],resubmit(,1)
 cookie=0x0, duration=2.056s, table=0, n_packets=0, n_bytes=0, idle_age=2, actions=resubmit(,1)
 cookie=0x0, duration=2.055s, table=1, n_packets=0, n_bytes=0, idle_age=2, tun_id=0x25,dl_dst=00:0c:29:d9:5f:c4 actions=output:1
 cookie=0x0, duration=2.055s, table=1, n_packets=0, n_bytes=0, idle_age=2, tun_id=0x25,dl_dst=00:1b:0c:0c:9b:bf actions=output:10
 cookie=0x0, duration=2.055s, table=1, n_packets=0, n_bytes=0, idle_age=2, tun_id=0x24,dl_dst=00:0c:29:db:bf:b5 actions=output:2
 cookie=0x0, duration=2.055s, table=1, n_packets=0, n_bytes=0, idle_age=2, tun_id=0x24,dl_dst=00:1b:0c:0c:9b:bf actions=output:10
 cookie=0x0, duration=2.055s, table=1, n_packets=0, n_bytes=0, idle_age=2, arp,tun_id=0x25,arp_tpa=136.1.37.100 actions=output:1
 cookie=0x0, duration=2.055s, table=1, n_packets=0, n_bytes=0, idle_age=2, arp,tun_id=0x25,arp_tpa=136.1.37.1 actions=output:10
 cookie=0x0, duration=2.055s, table=1, n_packets=0, n_bytes=0, idle_age=2, arp,tun_id=0x24,arp_tpa=172.16.20.100 actions=output:2
 cookie=0x0, duration=2.054s, table=1, n_packets=0, n_bytes=0, idle_age=2, arp,tun_id=0x24,arp_tpa=172.16.20.1 actions=output:10

 cookie=0x0, duration=2.054s, table=1, n_packets=4, n_bytes=341, idle_age=0, priority=100 actions=drop



From the above output, you can see each flow's number of packets matched/forwarded. Also note when you dump-flows, the tun_id is represented in hex format. A final note, MTU can be a killer if your network (like mine) can't accommodate the overhead. So, I lowered the MTU in my windows VM to 1200 bytes. I could probably get away with up to 1420 bytes, but I'm getting fantastic performance with 1200, so I'll probably just leave it as is. So what's the final result?






Works like a charm!

***Update***

So, as these things go, I found a way better way to do this. Basically, if I enable spanning-tree I can drastically decrease the amount of config needed to get this working.

ovs-vsctl set bridge BR1 stp_enable=true
!
root@ovs-vtep1:~# cat wsa_lab.txt 
table=0,in_port=1,actions=set_field:37->tun_id,resubmit(,1)
table=0,in_port=2,actions=set_field:36->tun_id,resubmit(,1)
table=0,actions=resubmit(,1)
table=1,priority=100,actions=NORMAL

So much simpler right? Now I'm running 802.1D over VXLAN thereby preventing loops. You can confirm that with the following:

root@openvswitch:~# ovs-ofctl show BR1
OFPT_FEATURES_REPLY (xid=0x2): dpid:0000080027d2f207
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 1(eth1): addr:08:00:27:d2:f2:07
     config:     0
     state:      STP_FORWARD
     current:    1GB-FD COPPER AUTO_NEG
     advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
     supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
     speed: 1000 Mbps now, 1000 Mbps max
 12(vtep12): addr:0a:2d:a5:f8:a9:12
     config:     0
     state:      STP_BLOCK
     speed: 0 Mbps now, 0 Mbps max
 23(vtep23): addr:7e:2a:b3:f5:21:c2
     config:     0
     state:      STP_FORWARD
     speed: 0 Mbps now, 0 Mbps max
 LOCAL(BR1): addr:08:00:27:d2:f2:07
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0