OSPFv3 for IPv4 (hooray address families!)

OSPFv3 is a pretty slick upgrade to OSPFv2. Most of us know as much, but in an IPv4 world we're all just stuck... waiting. Well with recent updates to IOS (I noticed it available in 15.3 - which can run on a 7200 in GNS3 for all you labbers at home) OSPFv3 now supports multiple address families. So much like with EIGRP named mode, we're seeing Cisco migrating routing protocols to follow the format of MP-BGP. The catch 22 with IPv4 routing with OSPFv3 you do have to have IPv6 unicast-routing enabled, AND all participating interfaces have to have IPv6 link-local addressing. The reason being, as we'll see in Wireshark, is that even though we're relaying information about IPv4 prefixes all communication with OSPFv3 is still done in IPv6. So let's get into the configuration, and we'll double back on packet level details.

Topology:

SP-METRO
!
conf t
!
ipv6 unicast-routing
!
router ospfv3 1
address-family ipv4 <-- support for VRF here!
!
!
interface Ethernet0/0
no switchport
ip address 200.1.1.1 255.255.255.252
ipv6 enable
ospfv3 1 ipv4 area 0.0.0.0
!
!
interface Ethernet0/1
no switchport
ip address 200.1.2.1 255.255.255.252
ipv6 enable
ospfv3 1 ipv4 area 0.0.0.0
!
!
interface Ethernet0/2
no switchport
ip address 200.1.3.1 255.255.255.252
ipv6 enable
ospfv3 1 ipv4 area 0.0.0.0

R1
!
ipv6 unicast-routing
!
router ospfv3 1
 address-family ipv4 unicast
!
!
interface Ethernet0/1
 ip address 200.1.1.2 255.255.255.252
 ipv6 enable
 ospfv3 1 ipv4 area 0.0.0.0
!
!
interface Loopback0
 description LAN NETWORK
 ip address 192.168.1.1 255.255.255.0
 ipv6 enable
 ospfv3 1 ipv4 area 0.0.0.0

Also we have very similar configurations on R2 and R3. After a few seconds you should see a nice console prompt "%OSPFv3-5-ADJCHG: Process 1, IPv4, ..." letting us know that we have an OSPFv3 peer within the IPv4 address family. Important take way from this is that if you do enable IPv6 address families, while it will run with the same routing process it does require a second neighbor adjacency. Another important note on that is if you're running both IPv4 and IPv6 address families, you'll have separate OSPF data bases for each addr family.

So show commands! Let's see what we get, then we'll take a look some wireshark info.

R1#show ip ospf neighbor
R1##CRAP
R1#show ip route ospf
R1##Double Crap!!

Wait?! What the hell's going on here?! I can feel the tension building at home, put your pitch fork down. I didn't lie to you. 'show ip ospf' explicitly refers to OSPFv2... and we don't have any v2 neighbors. Same with 'show ip route ospf', we don't have any v2 routes. Let's try this again.

R1#show ospfv3 neighbor
          OSPFv3 1 address-family ipv4 (router-id 192.168.1.1)
Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
200.1.3.1         1   FULL/DR         00:00:39    17              Ethernet0/1
R1#show ip route ospfv3 | b ^Gateway
Gateway of last resort is not set
      200.1.2.0/30 is subnetted, 1 subnets
O        200.1.2.0 [110/20] via 200.1.1.1, 00:55:43, Ethernet0/1
      200.1.3.0/30 is subnetted, 1 subnets
O        200.1.3.0 [110/20] via 200.1.1.1, 00:55:43, Ethernet0/1

Like a promised, here's a quick wireshark off R1's Eth 0/1 interface, again important take away is that even though we're exchanging IPv4 prefixes, v3 send it's hellos and LS information with IPv6 addresses. If you go back to the configuration above, that's why "ipv6 enable" has to be enabled. Alternatively, you can also just assign IPv6 link local addresses manually... if you just like killing time.

Pop Quiz hot shot! FF02::5 is obviously an OSPF multicast address, but which one? Also what do you think the other OSPFv3 multicast address is? Answer here(select text after): FF02::5 is the ospfv3 all ospf routers group, like 224.0.0.5. FF02::6 is the ospfv3 DR group, again like 224.0.0.6.

The benefits of deploying OSPFv3 for your IPv4 networks are pretty sweet. The most obvious benefit, it lines you up perfectly for when you actually deploy IPv6 internally (in 1000 years). The next one, that I really like, you can start leveraging v3's security. That's right... IPsec. Lets take a look at that configuration real quick.

Now like ospfv2, authentication can be enabled per-link or globally for an entire area. I'll the area-wide method here, and cover the per-link in a future post/video (it's not vastly different).

SP-METRO
!
router ospfv3 1
 area 0.0.0.0 authentication ipsec spi 912 sha1 0123456789012345678901234567890123456789
 !
 address-family ipv4 unicast
!

 Notice on the area wide configuration you enable IPsec outside of any address-family. Again, making transitioning to IPv6 that much easier, you don't have to reconfigure security. So let's break this down. I think 'area 0.0.0.0 authentication' is pretty straight forward, so is the 'ipsec' portion of the command. Unless you didn't know OSPFv3 secured its routing with IPsec... then that might have been a surprise. The next part "spi" or Security Parameter Index, is a fairly arbitrary number between 256 and 4294967295. When enabling ospfv3 authentication per-interface the SPI has to be unique for each interface on the local router, and spi's have to match between neighbors. Area-wide, a single spi is just fine - since that's the only option for area wide authentication lol. After we specify an spi value we can choose to either use an md5 or sha1 hash. For SHA1 the hash value has to be 40 characters long, so for demonstration purposes I copied '0123456789' into notepad, copied and pasted three times. In the real world, obviously, you'll want something a bit more secure.


So there you have it! I'll have a video coming soon going into a bit more detail, but it's been a while since I posted anything and I thought this would be a good topic to start covering. 

Where I'm at now...

So a quick update, I have passed the 400-101 (v5 written) and I'm back into full swing. Thanks to the awesome re-take policy iPexpert offers, my bootcamp is booked also. So if anyone out there plans to attend OWL in March, I'll be in RTP for that class. All in all, things are shaping up nicely, and I should meet my goal of an April Fool's Day lab attempt. Why April Fool's Day? Well, after sitting for the lab four times now, I've learned MANY things... one of those things is that you don't get to choose many things that happen lab day. You have no control over what your workbook is going to focus on. No control what food is served during lunch, or what computer you sit at during the lab. You can't even pick your own terminal emulator. One thing you do definitely have control over is what day you take your lab, I choose to take mine on a day that makes me smile.

EIGRP OTP - Looking closer part 1

So I'm going to break my closer look at EIGRP Over the Top into a couple smaller posts. Maybe I'll tie it together with a video when I'm done... maybe lol.


So today I thought I'd answer the most basic question of OTP, how the hell does it work?! In my previous post I covered a quick setup of OTP, and talked a little bit about the need to have connectivity between nodes. To reiterate that, the only way I could get OTP to work was to have a static route on each CE device pointing to my MPLS cloud for all other CEs (their MPLS facing interfaces only). That sounds confusing so here's a picture!

Now that you have a visual, all I did so my CEs could reach one another was add a static route 10.255.254.0 255.255.255.0 10.255.254.y where 'y' is the PE for each host. The reason I take time to point this out, again, is because OTP is advertised as an overlay so you don't have to do any dynamic routing with your provider. What it's not is an overlay where you don't have to do ANY routing with your provider, you CEs have to be able to be able to reach one another. Ok, now that I've touched on that fairly obvious topic let's get into some packet captures. What traffic is your provider going to see when you're running OTP?

EIGRP: Your provide CAN see EIGRP packets, again a lot of documentation talks about LISP encapsulation, and it's definitely there... just not for your actual EIGRP traffic. This is may or may not be of concern, but I wanted to throw it out there. I ran a wireshark capture on the PE facing CE3, and here you can clearly seeing that we're sending EIGRP packets without LISP encapsulation.

Also a quick note of on the topic of EIGRP packets, remember in the last post that your EIGRP RR clients need to have a maximum hop count specified for their static neighbor command? You don't remember that?! That's fine, here's what the syntax looks like:

router eigrp OTP
 !
 address-family ipv4 unicast autonomous-system 300
  !
  [...]
  neighbor 10.255.254.2 Ethernet0/0 remote 10 lisp-encap

I used '10' as the maximum hop count. Well, you can actually see that in the capture as CE3 -> CE1's TTL value in the IPv4 header. I know that's pretty basic, but I love seeing evidence that something is working as expected.

LISP: Ok so you might be wondering... where does LISP come into play? Well, let's look at the routing table on CE3, specifically at EIGRP learned routes.

CE3#show ip route eigrp | b ^Gateway
Gateway of last resort is not set
      192.168.1.0/32 is subnetted, 1 subnets
D        192.168.1.1 [90/3584640] via 10.255.254.2, 00:09:08, LISP0
      192.168.2.0/32 is subnetted, 1 subnets
D        192.168.2.2 [90/3584640] via 10.255.254.6, 00:09:08, LISP0
CE3#

There's your answer! Any traffic destine to those EIGRP learned prefixes, will be LISP encapsulated. Which brings up a fine point... what does LISP encapsulation actually look like? Well, Cisco's current documentation notes that user data will be encapsulated udp/4341 (ref:here). However I did not find this in practice. For a test I initiated a telnet from CE3 to the loopback address of CE1. Check out the wireshark.

So data is actually being encapsulated udp/4343. Just for fun, let's decode this capture as LISP. If you're not familiar with that function within wireshark (works on ALL kinds of protocols), what I'm doing is going to Analyze > Decode As...>LISP Data. 

Check it out! There's all my decoded traffic, as you can see I sent some pings before firing off my telnet session. I know what you're thinking... I can sense it even now. You're wondering if I can follow that TCP stream (that was encapsulated LISP) and read the telnet output aren't you? Yes dear friend, yes we can.

So that's it ladies and gents, part 1 of my closer look at OTP. Not sure what part 2 will be about... but I'm thinking I might combine OTP with GETVPN, then maybe look at VRF support. 

EIGRP just went... Over the TOP!

So I did a short video with my initial configuration/look at EIGRP OTP. Just thought I'd share it out here as well. I'm going to be looking into it a little more in-depth in the next post, but until then!

New Trouble Ticket -- OSPF NSSA and full reachability

So I bumped into a pretty similar task in my studies not too long ago, and decided tonight that it would make for a pretty good blog post. So first things first, here's our network diagram (sorry it's not as pretty as usual, but suck it up butter cup).

If you're going to attempt the following task, you can IP the connections between routers however you like. I did 192.168.xy.z/24 where x is the lower router number, y is the higher, and z is the router number. So the link between R1 and R2 is 192.168.12.z/24. That being said here are the conditions of the task.

1. Area 13 MUST be an NSSA area.
2. Each router can only have a single OSPF process.
3. You may not add any additional interfaces.
4. Only loopback 0 may be advertised into OSPF using network statement, and it may only have the IP of "192.168.z.z/32" where z is the router number. All other loopbacks must be redistributed into OSPF.
5. No static routes are allowed in this lab.

That being said here's the task.

Both R3 and R4 are redistributing a number of Loopbacks into the network. R3 is an NSSA router, configure R3 to advertise Loopbacks 6, 7, 12, and 13 as a single summary. This summary must been seen throughout the OSPF domain, but should not hinder full reachability. When this task is completed all loopbacks should be reachable from all routers.

Traffic filtering on Lan-2-Lan VPNs (ASA)

So I know this isn't my usual R&S blog post... but I continue to see just terribly stupid approaches to filtering traffic across Lan-2-Lan tunnels between ASAs. So this is my small contribution to end the stupidity. Before we get started, lets draw up a super basic diagram to work from and then I'll decribe the problem, probably rant on the dumb solutions I've seen to the problem for a paragraph, before finally showing how I solve said problem.

Ok cool, we have a pretty picture to talk about now. So here's the problem we're trying to solve, we're CORP and we have this VPN built to a partner company so their users can access services on 172.16.1.100. No big deal right? We build our L2L VPN just like always, maybe use some stronger than normal encryption and hell we even configure PFS. Then concerns form about what all this partner company has access to, because really all they should be able to do is ping, access a web page via https, and maybe we also allow them to SSH to this box (sftp or something). Well, default behavior of a L2L tunnel doesn't make filtering super easy. Here's where people get stupid. So before covering the best solution, let's just make a list called "Shit you shouldn't do"

1. Don't disable sysopt connection permit-vpn. This command is on by default, and if you turn it off, the firewall stops trusting ingress VPN traffic. While it would get the job done, and now you have to permit traffic via your outside interface, never use a cannon to kill a fly. Turning off 'permit-vpn' impacts all VPN traffic, so if you have multiple L2L VPN, any remote access VPN (anyconnect and legacy) you now have to allow traffic on your outside interface to accommodate these connections. It's a dumb solution, stop using it.

2. Don't limit interesting traffic to filter the connection. This means on your crypto ACL you get hyper specific with allowed hosts, subnets, and protocols/ports. Yes... I've seen people specify port numbers in their crypto ACLs, it causes magically unpredictable behavior. While limiting allowed hosts/subnets isn't a bad practice, if you start getting crypto ACLs that are 10, 15... 20 lines you have a problem. Remember each line your crypto ACL (think crypto map VPN 10 match address crypto_acl) is a separate IPsec security association both firewalls have to track and negotiate. Again, stop doing this.


Now that we covered that, lets go over what I consider to be "The Most Correct Way... ever." So again, we'll use tcp 22/443 and icmp as examples of our allowed traffic. The CORP firewall should drop all other traffic coming over this tunnel, and we'll even have an explicit deny statement just to track hits that get dropped.

Before Filtering:

access-list IPsec extended permit ip 172.16.1.0 255.255.255.0 10.1.1.0 255.255.255.0
!
crypto ipsec transform-set ESP-AES esp-aes esp-sha-hmac
crypto map VPNMAP 10 match address IPsec
crypto map VPNMAP 10 set peer 200.1.1.100
crypto map VPNMAP 10 set transform-set ESP-AES
crypto map VPNMAP interface OUTSIDE
!
crypto isakmp enable OUTSIDE
crypto isakmp policy 10
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400
!
tunnel-group 200.1.1.100 type ipsec-l2l
tunnel-group 200.1.1.100 ipsec-attributes
 pre-shared-key cisco123

Ok, so I'm actually saying "Anything on my corporate LAN is considered interesting." That's fine, maybe there's future growth or something. Now let's filter the tunnel so 10.1.1.0/24 can only talk to 172.16.1.100 on tcp/22&443, and icmp.

After

 access-list PARTNERL2L-Filter extended permit tcp 10.1.1.0 255.255.255.0 host 172.16.1.100 eq ssh
access-list PARTNERL2L-Filter extended permit tcp 10.1.1.0 255.255.255.0 host 172.16.1.100 eq https
access-list PARTNERL2L-Filter extended permit icmp 10.1.1.0 255.255.255.0 host 172.16.1.100
access-list PARTNERL2L-Filter extended deny ip 10.1.1.0 255.255.255.0 any
!
group-policy PARTNER_L2L_VPN internal
group-policy PARTNER_L2L_VPN attributes
 vpn-filter value PARTNERL2L-Filter
!
tunnel-group 200.1.1.100 general-attributes
 default-group-policy PARTNER_L2L_VPN

 That's all you have to do! *SPECIAL NOTE* If the L2L VPN is up and active when you make this change, you'll need to clear IPsec SA for that peer. So in my case that's:

clear ipsec sa peer 200.1.1.100

When the tunnel re-establishes, boom your filter is in place. I'll do the actual demo in my video, but here's the hit counter on my filter ACL.

CORP-FW# sh access-l PARTNERL2L-Filter
access-list PARTNERL2L-Filter; 3 elements
access-list PARTNERL2L-Filter line 1 extended permit tcp 10.1.1.0 255.255.255.0 host 172.16.1.100 eq ssh (hitcnt=5)
access-list PARTNERL2L-Filter line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 172.16.1.100 eq https (hitcnt=0)
access-list PARTNERL2L-Filter line 3 extended permit icmp 10.1.1.0 255.255.255.0 host 172.16.1.100 (hitcnt=1)
access-list PARTNERL2L-Filter line 4 extended deny ip 10.1.1.0 255.255.255.0 any  (hitcnt=10)

So that's it everyone, stop doing dumb shit. Video coming later tonight... maybe tomorrow.

GNS3 IOU Server (GNS3 1.0 Beta 2)

Just thought I'd share this video out from my YouTube channel here also. So the two people who mistakenly read my blog this week can see how this is done.

GNS3 IOU Server

L2 Image I use -- i86bi-linux-l2-ipbasek9-15.1e.bin
L3 Image I use -- i86bi-linux-l3-adventerprisek9-15.3.1.3T.bin

================================================

Modify this conf file on the server: /etc/sysctl.conf

# Mitigate %AMDP2_FE-6-EXCESSCOLL iou error
net.unix.max_dgram_qlen = 2000000