I needed to test IPv6 overlay on DMVPN. Easy enough; there are plenty of DMVPN configuration guides out there and even some on IPv6. I tested on a version of 12.4T on 7200-series routers in GNS3 and the config was really as simple as taking my working IPv4 DMVPN setup and adding the same commands with an "ipv6" prefix, using IPv6 addresses and adding IPv6 EIGRP.
Showing posts with label IPv6. Show all posts
Showing posts with label IPv6. Show all posts
Tuesday, November 24, 2015
Tuesday, March 31, 2015
Netcat Proxy on Windows: Part 2 - v4/v6 Translation
In my previous post I looked at a Netcat proxy on Windows using named pipes to emulate how it works on *nix. Now that I got it working in the straightforward case, I decided to see if Netcat could be used as an IPv4 / IPv6 translation proxy.
This of course requires a Netcat that has IPv6 capabilities and because of my setup - works on Windows. Luckily, I have just the thing - nc64 which you can grab here.
The setup is more or less the same as for the IPv4-only test case last discussed: start the named pipe server, start the Netcat proxy, then connect. However, in this case, the Netcat proxy setup is slightly different. We'll need to listen on IPv4 and forward to IPv6 and vice versa for the opposite test case. Let's look at IPv4 to IPv6 first.
Tuesday, September 17, 2013
Android Update Brings IPv6
I was disappointed with AT&T not providing the Android 4.1.2 update when other US-based carriers made it available, especially since we got the 4.1.1 update pretty early. Even more disappointing was when this was finally available - around the beginning of August - my device never upgraded. A Google search the other night showed it was available and when I manually checked for updates - sure enough, it was.
I will say I'm pleased with the update. Multiwindow is pretty cool even if not standard. It doesn't support all apps - and even some common ones I use that would be nice to use in multiwindow mode - like Google Keep.
The best part is that IPv6 now seems to work! At least over WIFI. I have IPv6 running at home and was (again) disappointed when my wife's iPad and iPhone could get to IPv6 sites and my Android couldn't. But after the update, I tried What Is My IPv6 Address from my Android and got an IPv6 address back (you'll see your IPv4 address if IPv6 isn't working)! I confirmed with my favorite IPv6-only site Loops of Zen.
Monday, June 03, 2013
IPv6 to IPv4 Server Load Balancing Testing in GNS3
My last post talked about testing IPv4 / IPv6 web and proxy services using Qemu in GNS3. My next challenge was to understand the "easy" way to IPv6-enable an IPv4-only web site - configure your load balancer to do it.
The simple explanation for Server Load Balancing IPv6 to IPv4 (SLB64) is that it performs traditional server load balancing functions but additionally does address family translation from the requested IPv6 address to the real IPv4 address of the internal servers in the server farm.
I don't have a big name load balancer at my disposal nor does my laptop have the power needed to download a virtual image and spin up VMware connected to my GNS3 simulation. So I went looking for a linux software based alternative and found HAProxy. The site indicates IPv6 support came along in version 1.1 and of course there is a Tiny Core linux package available. That meant following the Qemu "installation" procedure I described in a previous post and doing the proper 'filetool' backup.
My lab looks like the following, including an Apache web server running on Qemu in GNS3 as described in the last post:
IPV6 = 2001:db8
192.168.100.254 192.168.100.1 10.100.100.17
IPV6:192:168::254 IPV6:192:168::1
HOST ------ R1 ------ Web Server
10.200.200.1 (Qemu)
IPv6:AC8:C800::1
|
|
10.200.200.17
IPV6:AC8:C800::254
HAProxy
(Qemu)
The HAProxy package didn't come with a configuration or startup script, so I had to create them. First, the configuration file was pretty simple to create in /usr/local/etc/haproxy.conf:
global user tc group staff daemon defaults mode tcp retries 3 timeout connect 5000 timeout client 50000 timeout server 50000 listen ipv6proxy80 :::80 server ipv4server80 10.100.100.17:80
A little translation: the 'global' and 'default' headings just set some standard parameters for HAProxy operation. The 'listen' heading is where I tell HAProxy to listen for all incoming IPv6 traffic to TCP port 80 (TCP comes from the 'mode tcp' command in the 'defaults' section). HAProxy should then distribute matched traffic to the listed servers - in this case only 10.100.100.17 on port 80. Listening on IPv6 and distributing to an IPv4 server causes HAProxy to do the address family translation from IPv6 to IPv4. Note that you can make this configuration much more secure and/or selective, but this is perfect for my little test.
Next, the startup script in /etc/init.d/services/loadbal:
#!/bin/sh
case "${1}" in
start)
/usr/local/sbin/haproxy -f /usr/local/etc/haproxy.conf -p /var/run/haproxy.pid -D
;;
stop)
pkill haproxy
;;
status)
pidof haproxy
;;
*)
exit 1
;;
esac
HAProxy is now started with "sudo /etc/init.d/services/loadbal start".
To test we need to remember that HAProxy is our load balancer and thus is advertising the "outside" (read: Internet) address of the web server. So on the HOST, I open a browser and point it to:
http://[2001:db8:AC8:C800::254]:80SUCCESS! I get the home page from the Apache web server complete with the link to the CGI script to print my environment variables as described in my last post. That certainly comes in handy to see where the web server thinks the connection is coming from as does a 'netstat -an' on the HAProxy Qemu linux console.
Thursday, May 30, 2013
IPv4 / IPv6 Web and Proxy Server Testing in GNS3
In a previous post, I described how I got some additional packages installed on Tiny Core linux to use with Qemu in my GNS3 simulations. While that post describes how I got a DHCPv6 client loaded on my Tiny Core image, at the time I also loaded Apache. This gave me an IPv4 / IPv6 web server to test with. Additionally, Apache can be run as a proxy server, so I could test IPv4 / IPv6 proxy services with the single Apache install.
The first step was to create a configuration file for both web server and proxy. The default is installed in /usr/local/apache2/conf/httpd.conf and is suitable for the web server configuration. I copied that file to /usr/local/apache2/conf/proxy.conf and edited it. I kept only the "LoadModule" commands and then added:
ServerRoot "/usr/local/apache2" listen 8080 User tc Group staff ProxyRequests On
You can get fancier, but that's all you really need for testing in a closed GNS3 lab environment.
Next, a nice home page on the web server that automatically displays some information would be nice. Printing environment variables like client IP address and server IP address will come in handy when testing through a proxy server to see what address (IPv4 or IPv6, client or proxy server) the "world" will see. Thankfully, the default install has this file. Unfortunately, it didn't work for me.
I had a permission issue and since the CGI script was really a link to the file, I couldn't change the permissions. Easy solution was to simply copy the file to the CGI bin directory and make the appropriate edits.
So first I need an index.html in /usr/local/apache2/htdocs. That looks like this:
<html> <head> <title>Title</title> </head> <body> <h1>It works!</h1> <a href = "cgi-bin/test-cgi-new">Environment</a> </body>
Next, the actual /usr/local/apache2/cgi-bin/test-cgi-new script is create with:
cd /usr/local/apache2/cgi-bin cp ./test-cgi ./test-cgi-new chown tc test-cgi-new chgrp staff test-cgi-new chmod 755 test-cgi-new
Finally, a startup script for both web server and proxy server in /etc/init.d/services:
--httpd--
#!/bin/sh
case "${1}" in
start)
/usr/local/apache2/bin/httpd
;;
stop)
pkill httpd
;;
status)
pidof httpd
;;
*)
exit 1
;;
esac
--proxy--
#!/bin/sh
case "${1}" in
start)
/usr/local/apache2/bin/httpd -f /usr/local/apache2/conf/proxy.conf
;;
stop)
pkill httpd
;;
status)
pidof httpd
;;
*)
exit 1
;;
esac
Now I can start them with "sudo /etc/init.d/services/httpd start" and "sudo /etc/init.d/services/proxy start".
Of course, make sure you do this on Qemu outside of GNS3 and save your configurations by editing the appropriate "/opt/.filetool.lst" file and running "filetool" to backup as described in the previous post.
Then, I created a simple GNS3 lab with a router in the middle. I made one connection bridged to my host machine (loopback interface) and added some routes on the host to point towards the simulation networks. I made another router connection to one instance of Qemu where I run the proxy service. The final router connection goes to another instance of Qemu where I run the web server. Now I can test from my host browser on IPv4 and IPv6 to the test web server and I can also configure the simulation proxy server on my host to test out IPv4 / IPv6 proxy services to the web server in the simulation.
Next, I'll describe how I setup and tested Server Load Balancing 6 to 4 (SLB64) with HAProxy.
Thursday, January 24, 2013
Winsock or Winsuck
In a previous post I talked about updating Netcat to support both IPv4 and IPv6 in a single Windows executable. I added a lot of new features including multicast listener with source specific multicast in IPv4 only.
I added source specific multicast in IPv4 only because the Winsock API did not provide the required structures for IPv6 source specific multicast in a "standard" way. Berkeley sockets did it as you'd expect by adding IPv6 complements for the existing IPv4 functions and structures.
| IPv4 | IPv6 |
|---|---|
| ip_mreq_source | ipv6_mreq_source |
Additionally, the address family independent structures and options are also available.
I recently looked at ssmping and found they did source specific multicast for IPv6 on Windows so I decided to look at the source for guidance and revisit my Netcat.
I still irks me that instead of:
struct ip_mreq_source mreq;
mreq.imr_multiaddr = *mgroup;
...
mreq.imr_sourceaddr = *rad;
I have to do:
#define MCAST_JOIN_SOURCE_GROUP 45
...
GROUP_SOURCE_REQ mreq;
struct sockaddr_in6 g6;
g6.sin6_addr = *mgroup6;
memcpy(&mreq.gsr_group, &g6, sizeof(struct sockaddr_in6));
...
g6.sin6_addr = *rad;
memcpy(&mreq.gsr_source, &g6, sizeof(struct sockaddr_in6));
Moving data back and forth with pointers and addresses, changing the storage structures and those memory copies - argh.
This is why I like Perl. I'm not a programmer by trade. This memory management is hidden from me in Perl and furthermore, Perl code will work across Windows and Linux. Instead in C, I have a bunch of '#ifdef' compiler directives to determine if I'm compiling on Win32 and if I have the proper version. The IPv6 source specific multicast routines aren't available and the address family independent ones are only available on Windows Vista or later (or maybe Windows Server 2008 - the documentation is pretty confusing). Not only do I need separate code for Windows or Linux within those compiler directive branches, I also need legacy and new Windows code if the Windows version is less than Vista.
Ultimately, it works. So I am happy. And since I'm not a "real" programmer and I only do this occasionally, I deal with it - and complain on my blog! Don't even get me started on support for QoS in 'setsockopt()'. How annoying is this for people who program for a living and need to support multiple platforms?
Wednesday, January 23, 2013
Testing DHCPv6: Part 2
In a previous post, I talked about getting a DHCPv6 client on a linux image to use with Qemu and GNS3. That post was mainly focused on documenting the steps to get the DHCPv6 client on the host and ultimately working. I neglected to talk about the DHCPv6 server that I configured on the Cisco router.
Of course, I was just bit by a minor configuration miss that I learned in that exercise and quickly forgot until gently reminded as I watched my DHCPv6 simulation NOT work.
The DHCPv6 server configuration on the router is pretty simple:
ipv6 dhcp pool DHCPv6 address prefix 2001:DB8:A64:6800::/64 dns-server 2001:4860:4860::8888 domain-name dynamips.com
But what I forgot was that SLAAC is mandatory for IPv6 nodes and will work as long as router advertisements are present. So simply setting the M-bit in the router advertisements to force DHCPv6 is not enough. You need to NOT advertise the IPv6 prefix on the interface.
So the interface configuration looks like:
interface FastEthernet2/0 ipv6 address 2001:DB8:A64:6800::1/64 ipv6 enable ipv6 nd prefix 2001:DB8:A64:6800::/64 no-advertise ipv6 nd managed-config-flag no ipv6 redirects no ipv6 unreachables ipv6 dhcp relay destination 2001:DB8:A01:100::1
In the above example, I'm sending the DHCPv6 requests to the DHCPv6 server running on another Cisco router. I've set the M-bit and I've also stopped router advertisements of the prefix with the 'ipv6 nd prefix 2001:DB8:A64:6800::/64 no-advertise' command.
And now it works!
Thursday, December 20, 2012
Multicast IPv6 Anycast RP Design
Like most folks, I heard of multicast but never configured it. That changed back in 2006 when we deployed music on hold over multicast for our Cisco voice infrastructure and also installed VBrick IP television which required multicast. I did the research and created a PIM sparse mode design based on the Cisco Solution Reference Network Design for campus networks.
We used anycast rendezvous points (RP) peered with Multicast Source Discovery Protocol (MSDP). We used a site local multicast scope and properly filtered on the edge. We peered with the multicast RPs in our headquarters site and passed organization local scope groups. Overall, we had a pretty robust, fault tolerant multicast design.
I did more multicast work at my next client through 2011 including dense-mode and simplified multicast forwarding (SMF), custom code for Internet Group Management Protocol (IGMP) joins for multicast on mobile ad-hoc networks (MANET) and lots of other unique designs.
Of course, this was all on IPv4.
Multicast for IPv6 is a different beast and although I haven't seen a requirement to deploy it for a client yet, I wanted to do some testing to get up to speed before the need manifests. I was fortunate to attend the Cisco IPv6 Fundamentals, Design and Deployment class last week. Although much was review for me given my hands-on IPv6 experience over the last 4 years, the multicast module and lab was very informative.
I understood my IPv4 multicast reference design would not map to IPv6. While IPv6 supports anycast RP, there is no MSDP for IPv6. Some (very basic) background:
-
In a Protocol Independent Multicast Sparse-Mode (PIM-SM) design, multicast sources send their multicast streams to the Rendezvous Point (RP). Multicast listeners are directed to the RP to make the connection and start receiving traffic. To make the design redundant and fault tolerant, we use anycast RP. Anycast is the practice of configuring the same unicast address on multiple devices. Traffic is routed towards the closest instance of the address based on routing protocol metrics. This of course can result in multicast sources sending traffic to one anycast RP instance and multicast listeners being routed to a different anycast RP instance. No connection would be made in this case.
To overcome this issue, we use Multicast Source Discovery Protocol (MSDP) to peer the anycast RPs so they share information about the multicast sources. This way, no matter which instance of the anycast RP a listener connects to, it will be able to establish the stream from the multicast source and start receiving traffic.
With the above explanation, the absence of MSDP in IPv6 is a problem with an anycast RP design. Foregoing anycast RP and just using a single RP does not provide fault tolerance should the RP go down. What to do?
RFC 4610 addresses this issue and Cisco implements it in IOS 15 and other flavors like XE. However, I learned in class that Cisco had another approach they called "Anycast RP with prefix arbitration".
The concept is simple using standard routing rules of longest match prefix. Simply configure the anycast address on multiple devices with different masks. Instead of equal cost multipath routing in redundant environments, all traffic will be routed to the anycast instance with the longest prefix (anycast RP primary). Should that RP go down, all traffic will be routed to the anycast instance with the second longest prefix (anycast RP secondary), and so on (anycast RP tertiary ...). This is very similar to "floating static routes"; static routes with a manually configured admin distance to bring up a BRI interface when the primary frame-relay goes down (remember 1990's).
- Configure primary anycast RP with longest prefix
- Configure secondary anycast RP with second longest prefix
- Configure tertiary anycast RP with third longest prefix
- And so on ...
- Advertise the anycast network from each device via routing protocol
This eliminates the need for MSDP to peer the anycast RPs since all traffic - both sources and listeners - will be routed to the same anycast RP instance. Or will it?
Consider an instance where multicast sources and / or listeners are directly connected to the devices which host the primary and secondary anycast RPs. Connected routes override any longest prefix match since they are connected. So there is a possibility where listeners won't be able to find sources. And that's what happened to me when I finished the documented multicast lab and decided to test this design.
The lab was only two routers with a client connected off each, so it's pretty obvious why it failed. I decided to test a more real-world scenario. Consider the following:
The relevant configurations:
C1#show run interface Loopback0 interface Loopback0 description Anycast RP (Primary) no ip address ipv6 address 2001:DB8:AFE:FE00::1/120 ipv6 enable ipv6 eigrp 1 end C2#show run interface Loopback0 interface Loopback0 description Anycast RP (Secondary) no ip address ipv6 address 2001:DB8:AFE:FE00::1/119 ipv6 enable ipv6 eigrp 1 end
With anycast RP primary configured on C1 (/120 mask) and the anycast RP secondary configured on C2 (/119 mask), we expect all traffic to be routed to C1. Indeed it is from both D1 and D2:
D1#show ipv6 route 2001:db8:afe:fe00::1
Routing entry for 2001:DB8:AFE:FE00::/120
Known via "eigrp 1", distance 90, metric 156160, type internal
Route count is 1/1, share count 0
Routing paths:
FE80::C804:11FF:FE44:1C, FastEthernet1/0
Last updated 00:00:12 ago
D2#show ipv6 route 2001:DB8:AFE:FE00::1
Routing entry for 2001:DB8:AFE:FE00::/120
Known via "eigrp 1", distance 90, metric 156160, type internal
Route count is 1/1, share count 0
Routing paths:
FE80::C804:11FF:FE44:1D, FastEthernet1/0
Last updated 00:03:05 ago
"FastEthernet1/0" is the telltale that D1 and D2 will send their traffic for the anycast RP to C1 (see diagram above). When we shutdown the Loopback0 interface (anycast RP primary) on C1, traffic fails over:
D1#show ipv6 route 2001:db8:afe:fe00::1
Routing entry for 2001:DB8:AFE:FE00::/119
Known via "eigrp 1", distance 90, metric 156160, type internal
Route count is 1/1, share count 0
Routing paths:
FE80::C805:11FF:FE44:1C, FastEthernet1/1
Last updated 00:03:25 ago
D2#show ipv6 route 2001:DB8:AFE:FE00::1
Routing entry for 2001:DB8:AFE:FE00::/119
Known via "eigrp 1", distance 90, metric 156160, type internal
Route count is 1/1, share count 0
Routing paths:
FE80::C805:11FF:FE44:1D, FastEthernet1/1
Last updated 00:03:27 ago
So the solution works! But what routes do C1 and C2 see? When operating in steady state (each anycast RP interface on C1 and C2 is up), all routing doesn't point to C1:
C1#show ipv6 route 2001:DB8:AFE:FE00::1
Routing entry for 2001:DB8:AFE:FE00::1/128
Known via "connected", distance 0, metric 0, type receive
Route count is 1/1, share count 0
Routing paths:
receive via Loopback0
Last updated 00:00:28 ago
C2#show ipv6 route 2001:DB8:AFE:FE00::1
Routing entry for 2001:DB8:AFE:FE00::1/128
Known via "connected", distance 0, metric 0, type receive
Route count is 1/1, share count 0
Routing paths:
receive via Loopback0
Last updated 00:19:13 ago
Notice C1 and C2 each see the anycast RP address as their local Loopback0 interface. In the case of C1, that's correct. In the case of C2, it's correct (according to routing rules), but not desired (according to our anycast RP with prefix arbitration design). There isn't a way to "fix" it as it isn't broken, it just highlights a design constraint on the "Anycast RP with prefix arbitration" design:
- Never directly connect multicast sources or listeners to a device acting as an anycast RP
This may not be a problem in the design I tested as most people won't connect end stations to the core layer. But consider collapsed core designs or instances where the RPs may be configured on distribution layer switches that connect servers which are multicast sources.
"Anycast RP with prefix arbitration" is a pretty easy, straight forward design, but like anything new, test first and understand the limitations.
Tuesday, December 18, 2012
IPv6 TFTP from IPv4
No, the title doesn't imply a great new translation technology for that indispensable file transfer protocol TFTP. Instead, this is to highlight an "oversight" - I won't go so far as to call it a "bug" - in Cisco IOS.
I'm testing with version Advanced IP Services 12.4 (24)T on a 7200 series router - just in case that matters.
For many services on Cisco routers and switches, I've been using the "source interface" command to explicitly tell the device what address to source the updates from. Normally, I point it to a loopback interface. This makes looking at logs pretty easy when DNS resolves the loopback address to the device name.
So for example:
ip flow-export source Loopback0 logging source-interface Loopback0 snmp-server trap-source Loopback0 snmp-server source-interface informs Loopback0
In most cases, we'll even use "update-source LoopbackX" for iBGP neighbors.
This makes looking at a Syslog and SNMP Trap aggregator easy. As long as they resolve addresses to names, I see content like:
Router1 Informational Local7 Interface FastEthernet0/0 up SwitchA Emergency Local6 Power supply 1 down
Instead of:
10.254.254.1 Informational Local7 Interface FastEthernet0/0 up 10.254.254.2 Emergency Local6 Power supply 1 down
Now that we've shown why this is good practice, I'll also add that we track nightly TFTP backups of configurations in TFTP logs and the same principle applies. So we use the 'ip tftp source-interface Loopback0' command. Notice however that all previous commands don't start with 'ip', the TFTP 'source-interface' command does. Big deal? With IPv6 it turns out ... YES, it is.
Granted the backup routine tested connected to the devices via IPv4 and requested a TFTP backup via SNMP to the IPv4 address of the TFTP server - so we didn't lose a night's worth of backups and wake up to an error log. The benefits of testing first! However, with IPv6 enabled and an IPv6 address on the Loopback0 interface, IPv6 TFTP should work. And in the test, it didn't.
Here's the relevant configuration:
ip tftp source-interface Loopback0 interface Loopback0 ip address 10.254.254.1 255.255.255.255 ipv6 address 2001:DB8:AFE:FE00::1/128 ipv6 enable interface FastEthernet2/0 description To TFTP Server ip address 192.168.100.1 255.255.255.0 ipv6 address 2001:DB8:192:168::1/64 ipv6 enable
The TFTP server in the test lives at:
192.168.100.254
2001:db8:192:168::254
Again, IPv4 TFTP worked as expected. The Loopback0 address (10.254.254.1) shows in the TFTP logs. But with IPv6, something strange happened:
R1#copy run tftp Address or name of remote host []? 2001:db8:192:168::254 Destination filename [r1-confg]? ..... %Error opening tftp://2001:db8:192:168::254/r1-confg (Timed out) R1#
And the resultant TFTP server log shows:
TFTP# crapps.pl -S tftpd -6 Starting MODE -> TFTP Server Listening on -> [::]:69 (udp) TFTP Root directory -> . afe:fe01:: 62506 WRQ OCTET r1-confg STARTED afe:fe01:: 62506 WRQ OCTET r1-confg STARTED afe:fe01:: 62506 WRQ OCTET r1-confg File './r1-confg' already exists afe:fe01:: 62506 WRQ OCTET r1-confg Timeout occurred on DATA packet 1 ...
Who the heck is "afe:fe01::"? My Loopback0 IPv6 address is "2001:db8:afe:fe00::1". True, but my Loopback0 IPv4 address is "10.254.254.1", or in hex used directly as an IPv6 address is "afe:fe01::". I remember a saying about computers doing exactly what you tell them to. The Cisco router is sourcing the TFTP from the 'ip tftp source-interface Loopback0' - 'ip' as in "IPv4".
So is IPv6 TFTP broken? No, you just need to remove the 'source-interface' command:
R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#no ip tftp source-interface Loopback0 R1(config)#end R1#copy run tftp Address or name of remote host []? 2001:db8:192:168::254 Destination filename [r1-confg]? !! 8774 bytes copied in 5.540 secs (1584 bytes/sec) R1#
And confirmed on the TFTP server:
TFTP# crapps.pl -S tftpd -6 Starting MODE -> TFTP Server Listening on -> [::]:69 (udp) TFTP Root directory -> . 2001:db8:192:168::1 52000 WRQ OCTET r1-confg STARTED 2001:db8:192:168::1 52000 WRQ OCTET r1-confg SUCCESS [8774 bytes]
Much better. Of course now the source is the interface of the router that the TFTP traverses, in this case, FastEthernet2/0. This will also be the same for IPv4 TFTP now.
Nightly TFTP backups are one of those automated tasks we set and forget. Sure there are monitors in place to catch changes and email alerts, but how often does something go wrong? Imagine waking up to an error log an no backups. Not then end of the world, but certainly not something you want to see before your first cup of coffee. Test and test again, especially when incorporating IPv6.
Thursday, December 13, 2012
BGP Redistribution Redo
I've always been weary of redistributing an IGP into BGP rather than using explicit network statements. Sure it automates the process, but if I'm going to be redistributing BGP into the IGP (say for MPLS CPE) - hopefully with a 'route-map' - there is a potential for funky redistribution loops and issues. Better to break the cycle and statically configure BGP with 'network' statements to explicitly advertise only what you want.
Of course, I'll break my own rules in the name of testing or in this case, a lab exercise. I'm in a Cisco IPv6 training class and our BGP routing lab instructed us to:
-
"Configure IBGP between R1 and R2 using the parameters that are listed in the table."
Parameter R1 R2 Source Loopback 1 Loopback 1 Redistribute into BGP IPv6 ConnectedSet origin IGP IPv6 ConnectedSet origin IGP
The original configuration was pretty straight forward. EIGRP was used as the IGP to which we were to add BGP. EIGRP was already advertising the connected routes so the EIGRP admin distance was modified so IBGP would be preferred. I was already cringing, but decided to play along.
The relevant parts of the provided R1 configuration follow. You can assume R2 was identical with the appropriate corresponding addresses for interfaces and peers.
interface Loopback1 ipv6 address 2001:DB9:121:100::1/64 ! interface Loopback2 ipv6 address 2001:DB9:121:200::1/64 ! interface Serial0/0/0 no ip address encapsulation frame-relay IETF frame-relay lmi-type cisco ! interface Serial0/0/0.1 point-to-point description To R2 ipv6 address 2001:DB9:123:1::1/64 ipv6 eigrp 1 frame-relay interface-dlci 122 ! ipv6 router eigrp 1 eigrp router-id 10.12.1.1 no shutdown passive-interface Loopback1 passive-interface Loopback2 distance 250 255
At this point, the BGP configuration was pretty easy. I added the following:
router bgp 65012 bgp router-id 10.12.1.1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 2001:DB9:122:100::1 remote-as 65012 neighbor 2001:DB9:122:100::1 update-source Loopback1 ! address-family ipv6 neighbor 2001:DB9:122:100::1 activate redistribute connected route-map BGPCONN no synchronization exit-address-family ! route-map BGPCONN permit 10 match source-protocol connected set origin igp
It's no surprise that BGP came up and all was working. From R1:
W1P2R1#show bgp ipv6 unicast summary
BGP router identifier 10.12.1.1, local AS number 65012
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB9:122:100::1
4 65012 1027 1044 47 0 0 00:02:05 4
And I could see my R1 routes on R2:
W1P2R2#show ipv6 route 2001:db9:121:200::/64
Routing entry for 2001:DB9:121:200::/64
Known via "bgp 65012", distance 200, metric 0, type internal
Backup from "eigrp 1 [250]"
Route count is 1/1, share count 0
Routing paths:
2001:DB9:121:100::1
Last updated 00:00:59 ago
But a subsequent 'show' command revealed an issue:
W1P2R2#show ipv6 route 2001:db9:121:200::/64
Routing entry for 2001:DB9:121:200::/64
Known via "eigrp 1", distance 250, metric 20640000, type internal
Route count is 1/1, share count 0
Routing paths:
FE80::219:55FF:FE35:1B90, Serial0/0/0.1
Last updated 00:00:00 ago
The route was no longer learned via BGP, but through EIGRP. Weird. The previous command shows the admin distance was correct; iBGP [200] should be preferred over EIGRP [250 - modified]. What was happening?
I did the "up-arrow, enter" troubleshooting technique; that is, I ran the previous 'show ipv6 route ...' command over and over. Of course it worked. I noticed the "Last updated" timer reset every minute as the route flip-flopped between EIGRP and BGP. I started thinking about the BGP walker process and how it runs every 60 seconds.
Since we were in a lab, I had no issues with running 'debug bgp ipv6 unicast updates' on R2 and verified my instinct was correct.
*Dec 13 15:05:50.176: BGP(1): no valid path for 2001:DB9:121:1::/64 *Dec 13 15:05:50.176: BGP(1): no valid path for 2001:DB9:121:100::/64 *Dec 13 15:05:50.176: BGP(1): no valid path for 2001:DB9:121:200::/64 *Dec 13 15:05:50.176: BGP(1): no valid path for 2001:DB9:121:300::/64 *Dec 13 15:05:50.196: BGP(1): nettable_walker 2001:DB9:121:1::/64 no best path *Dec 13 15:05:50.196: BGP(1): nettable_walker 2001:DB9:121:100::/64 no best path *Dec 13 15:05:50.196: BGP(1): nettable_walker 2001:DB9:121:200::/64 no best path *Dec 13 15:05:50.200: BGP(1): nettable_walker 2001:DB9:121:300::/64 no best path *Dec 13 15:06:50.220: BGP(1): Revise route installing 2001:DB9:121:1::/64 -> 2001:DB9:121:100::1 (::) to main IPv6 table *Dec 13 15:06:50.220: BGP(1): Revise route installing 2001:DB9:121:100::/64 -> 2001:DB9:121:100::1 (::) to main IPv6 table *Dec 13 15:06:50.220: BGP(1): Revise route installing 2001:DB9:121:200::/64 -> 2001:DB9:121:100::1 (::) to main IPv6 table *Dec 13 15:06:50.220: BGP(1): Revise route installing 2001:DB9:121:300::/64 -> 2001:DB9:121:100::1 (::) to main IPv6 table
BGP on R2 put the routes for the advertised R1 connected interfaces - including the network containing the address for the R1 Loopback1 interface it was peering with - into the routing table. The routes had a next hop of the R1 Loopback1 interface. When these routes entered the routing table, they displaced the EIGRP routes for the same networks. A minute later when BGP walker ran again, there was no IGP (EIGRP) path to the next hop for those routes, so BGP removed them (as seen in the first 8 lines of the 'debug'). The routes were quickly replaced with the EIGRP routes as seen in the above "show ipv6 route ..." commands. Sixty seconds later when BGP walker ran again, the BGP routes were learned and now had a valid next hop as the IGP routes were in the routing table and BGP introduced the same routes - as seen in the last 4 lines of the above 'debug'. Every sixty seconds this repeated and flip-flopped the routes between EIGRP and BGP.
Knowing the problem, the fix was easy. Just use the existing 'route-map' to block the Loopback1 network from being advertised as a connected route. On R1, I used:
route-map BGPCONN deny 5 match ipv6 address PEER ! ipv6 access-list PEER permit ipv6 2001:DB9:121:100::/64 any
The complementary statements on R2 and a 'clear bgp ipv6 unicast *' had everything working perfectly!
The lesson learned just reinforced my original statement regarding redistribution - proceed with caution.
Friday, December 07, 2012
Testing DHCPv6
I've been doing some research into DHCPv6 for a client and beyond the talk and text, I needed some hands on testing. I can create a DHCPv6 server on a Cisco router in GNS3, but who knew creating a DHCPv6 client would be so troublesome.
I suppose I could have just used my Windows 7 x64 host and connected to the GNS3 simulation on a loopback interface. I've done this before, but I was looking for a way to do this in the simulation. I took a look at the Tiny Core 3.8.2 linux Qemu image available on the GNS3 appliances page and gave it a go. Unfortunately, Tiny Core uses 'udhcpc' as the DHCP client and it only supports IPv4. Partial success.
I had a look at Tiny Core and found that you can load packages and one package was the ISC DHCP package version 4.2.1 including client, server and relay. According to their website, 4.2.1 supports IPv6 so I thought I'd pursue.
The first step was to get the ISC DHCP package installed. Tiny Core comes with a package manager; however, you need to be online to use it and I hadn't played with the Qemu emulator (to run Tiny Core) outside of GNS3. To get network access, Qemu needs a TAP interface, which isn't available on Windows. I had to get one.
OpenVPN offers Windows software that comes with - among other things - a TAP interface driver. So simply download the latest Windows intstaller and run it. Luckily, it asks what components you'd like to install. I unchecked everything except for the Tunnel TAP interface driver. Once the install was completed, I had a new interface under Network and Sharing Center - Adapters, which I renamed to "TUN-TAP".
Simply select my physical NIC - in my case my wireless card - and the new TUN-TAP interface, right-click and select "Bridge Connections".
Armed with my new interface, I was able to launch Qemu and get Tiny Core online to add the proper packages:
C:\> qemu -hda linux-tinycore-3.8.2.img -net nic -net tap,ifname=TUN-TAP
Once loaded, I used the AppBrowser, pressed the "Connect" button and the available packages loaded. I used the search to look for "dhcp" and found "isc-dhcp.tcz". I selected "OnBoot" and pressed "Go". It installed the prerequisites and finished.
Next, I had to change Tiny Core to use 'dhclient' instead of 'udhcpc' and make the change permanent over reboots. First, I edited the "/etc/init.d/dhcp.sh" file. I commented out the line with 'udhcpc' and added two new lines after it:
/usr/local/sbin/dhclient -sf /usr/local/sbin/dhclient-script $DEVICE >/dev/null 2>&1 & /usr/local/sbin/dhclient -6 -sf /usr/local/sbin/dhclient-script $DEVICE >/dev/null 2>&1 &
That will load 'dhclient' (ISC DHCP client) instead of 'udhcpc' and it will do it for all interfaces and for both IPv4 and IPv6.
Finally, to make the change permanent, I edited the "/opt/.filetool.lst" file. I removed the line with "/sbin/dhclient" and replaced with:
/etc/init.d/dhcp.sh
and then ran 'filetool' and did a "Backup". Curiously, I got an error saying the backup failed, but examining the "/mnt/hda1/tce/mydata.tgz" file, I found the "/etc/init.d/dhcp.sh" file with my edits. So, I shutdown and restarted and hoped for the best.
It worked! I verified 'dhclient' was running instead of 'udhcpc':
tc@box:~$ ps -ef | grep dhc 1562 root /usr/local/sbin/dhclient -sf /usr/local/sbin/dhclient-script eth0 1699 root /usr/local/sbin/dhclient -6 -sf /usr/local/sbin/dhclient-script eth0 1762 tc grep dhc
The final test was to check DHCPv4 and DHCPv6 functionality in the GNS3 simulation. I had a 7200 series router configured as a DHCPv4 and DHCPv6 server and connected a Qemu host with the newly updated Tiny Core image. The host booted in the simulation and got both an IPv4 and IPv6 address. This was verified on the router by looking at:
R1>show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
10.100.104.17 00ab.298c.3e00 Dec 07 2012 03:48 PM Automatic
R1>show ipv6 dhcp binding
Client: FE80::2AB:29FF:FE8C:3E00
DUID: 000100011855208300AB298C3E00
Username : unassigned
IA NA: IA ID 0x298C3E00, T1 43200, T2 69120
Address: 2001:DB8:A64:6800:9D60:EF10:536A:28BF
preferred lifetime 86400, valid lifetime 172800
expires at Dec 09 2012 11:47 AM (172618 seconds)
The one thing to remember is that Qemu doesn't save any changes to the actual image file when in a GNS3 simulation. All changes are saved to a FLASH disk in the working directory. If that file or directory is removed, the Qemu host is back to defaults. I learned this the hard way the first time through. The answer is to load any packages and make any edits by running Qemu itself - as shown in the first command of this post - and then using the updated image in the GNS3 simulation.
NOTE: You can do the same for Micro Core linux by using the command line AppBroswer 'ab' and using the 'filetool.sh -b' command to commit the changes.
Tuesday, November 27, 2012
IPv6 over IPv4-only MPLS with 6to4
Last year, I researched, created and presented training on 6VPE technology for our internal consultants. Passing IPv6 routes and traffic over an IPv4-only MPLS network is a problem. 6VPE solves that problem from a carrier perspective allowing the MPLS carrier to provide dual-stack IPv4 and IPv6 at the LAN side interface of the customer edge devices.
But what if your MPLS provider has not rolled out IPv6 support?
I knew you could use tunnels to solve this problem from a client perspective. Further, configuring static tunnels in a full mesh over MPLS would be an awful management burden so automatic 6to4 tunnels could address that. However, I never pursued it further.
Recently, a question about this came up again and forced me to reconsider. Some research yielded Dynamic Routing Over 6to4 Automatic Tunnels which describes how to enable dynamic routing over 6to4 tunnels using BGP - specifically external BGP (eBGP). However, the article doesn't consider an MPLS backbone. I did some testing and it turns out it's not that hard to adapt this concept to an IPv4-only MPLS backbone.
Assume the following scenario:
- MPLS provider offers IPv4-only MPLS VPN access for customers
- Customer A wants IPv6 access
- Customer A has many remote sites so solution must be scalable
Since Customer A wants IPv6 access and the provider doesn’t offer it, the first step is for Customer A to configure tunnel endpoints on each of the remote sites. Static tunnels such as 6in4 will require n(n - 1) tunnel endpoints – essentially an n^2 problem or management burden. Each new site almost exponentially increases the management burden.
The solution is to configure 6to4 tunnel endpoints on each remote site. 6to4 tunnels are dynamic so only a single tunnel endpoint is needed per remote site. Adding a new site now only adds 1 new tunnel interface – a linear increase.
To enable dynamic routing, the customer edge routers already use BGP to connect to the MPLS backbone. We can use the existing BGP configuration to enable internal (iBGP) sessions between the 6to4 addresses and advertise the IPv6 networks.
To begin, let's configure the 6to4 endpoints on each remote site:
ACE1
interface Tunnel2002 ipv6 address 2002:a01:102::/128 tunnel source Serial1/0 tunnel mode ipv6ip 6to4 ipv6 unicast-routing ipv6 route 2002::/16 Tunnel2002
ACE2
interface Tunnel2002 ipv6 address 2002:a01:106::/128 tunnel source Serial1/0 tunnel mode ipv6ip 6to4 ipv6 unicast-routing ipv6 route 2002::/16 Tunnel2002
ACE3
interface Tunnel2002 ipv6 address 2002:a01:10a::/128 tunnel source Serial1/0 tunnel mode ipv6ip 6to4 ipv6 unicast-routing ipv6 route 2002::/16 Tunnel2002
At this point, the sites have reachability to the newly configured 6to4 addresses but not the IPv6 addresses on the LAN of each remote site. To enable reachability to those networks we need to enable routing.
The easiest way is to add some static routes pointing to the remote 6to4 address for the remote sites' IPv6 networks. For example, on ACE1, the static IPv6 routes to add for the four (4) IPv6 networks on ACE2 and the four (4) IPv6 networks on ACE3 are:
ipv6 route 2001:DB8:A64:6800::/54 2002:A01:106:: ipv6 route 2001:DB8:A64:6C00::/54 2002:A01:10A::
Of course, with static routing we've simply shifted the n^2 problem of tunnel endpoint management to static route management, which could actually be much worse if routes are not hierarchical like the /54 summaries above. Imagine managing several static routes per site on each remote router.
The best solution is dynamic routing and as the previous linked article described, an internal gateway routing protocol will not work as the 6to4 addresses are not on the same subnet. BGP solves this with explicit peering definitions and since the edge routers are already running BGP to the MPLS provider, we can use that configuration.
BGP peers will be configured to the 6to4 addresses so BGP routing traffic will be passed as over the 6to4 tunnels the same way data traffic is passed. We use iBGP since the customer edge routers are all in the same BGP Autonomous System. Finally, we offloaded the configuration burden of an iBGP full mesh by configuring ACE1 as a route reflector ACE2 and ACE3 as route reflector clients.
ACE1
router bgp 65100 neighbor 2002:A01:106:: remote-as 65100 neighbor 2002:A01:10A:: remote-as 65100 address-family ipv6 neighbor 2002:A01:106:: activate neighbor 2002:A01:106:: route-reflector-client neighbor 2002:A01:10A:: activate neighbor 2002:A01:10A:: route-reflector-client network 2001:DB8:A64:6400::/64 network 2001:DB8:A64:6500::/64 network 2001:DB8:A64:6600::/64 network 2001:DB8:A64:6700::/64
ACE2
router bgp 65100 neighbor 2002:A01:102:: remote-as 65100 address-family ipv6 neighbor 2002:A01:102:: activate network 2001:DB8:A64:6800::/64 network 2001:DB8:A64:6900::/64 network 2001:DB8:A64:6A00::/64 network 2001:DB8:A64:6B00::/64
ACE3
router bgp 65100 neighbor 2002:A01:102:: remote-as 65100 address-family ipv6 neighbor 2002:A01:102:: activate network 2001:DB8:A64:6C00::/64 network 2001:DB8:A64:6D00::/64 network 2001:DB8:A64:6E00::/64 network 2001:DB8:A64:6F00::/64
Note that we've made no changes to the PE router - meaning the MPLS provider does not need to support IPv6 at all for this configuration to work. You will need to make sure the provider doesn't do any exotic filtering at the edge or in the MPLS backbone such as blocking IP protocol 41 (IPv6 in IPv4 encapsulation).
At this point, we can test the configuration with some BGP show commands and pings to test connectivity. Without the benefit of a live demo here, rest assured these commands produced the provided output:
ACE1#show bgp ipv6 unicast
BGP table version is 17, local router ID is 10.100.103.1
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:A64:6400::/64
:: 0 32768 i
[...]
*>i2001:DB8:A64:6800::/64
2002:A01:106:: 0 100 0 i
*>i2001:DB8:A64:6900::/64
2002:A01:106:: 0 100 0 i
[...]
*>i2001:DB8:A64:6C00::/64
2002:A01:10A:: 0 100 0 i
*>i2001:DB8:A64:6D00::/64
2002:A01:10A:: 0 100 0 i
ACE1#ping ipv6 2001:db8:a64:6800::1 source 2001:db8:a64:6400::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:A64:6800::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:A64:6400::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 148/205/276 ms
ACE1#ping ipv6 2001:db8:a64:6c00::1 source 2001:db8:a64:6400::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:A64:6C00::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:A64:6400::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/167/204 ms
And there you have it! Dynamic routing of IPv6 over an IPv4-only MPLS network without the MPLS provider supporting IPv6.
Friday, November 02, 2012
Windows Virtual PC IPv6: Part 3
The original title of the first post in the this series was "Windows Virtual PC Wireless IPv6", but dropped the "Wireless" before publishing. At that point, I had Part 1 and Part 2 written and knew the problem was with the wireless card versus the wired card, but didn't yet know the root cause. And since I had exhausted my troubleshooting tools (tcpdump and network based analysis) and wasn't about to dive into wireless driver software reverse engineering, I figured I may never have the exact answer. Instead, I focused the posts on discussing the problem and how it relates to the question, "is 'X' IPv6 ready?"
I did want to close the loop and exhaust all possible angles. So I called my friend and colleague Randy who had experience with wireless bridging / routing and virtual machines from a previous client. I remember he would lament about the issues he faced and custom drivers and wireless cards needed to get things only partially working. Since I was only an observer, I didn't have the intimate details, so now I sought them out over a phone call.
I explained my set up and issue and Randy immediately knew the problem. It wasn't IPv6 specific nor was it related to Windows Virtual PC. In fact, it wasn't even the wireless card or its respective drivers (per se), it was the 802.11 protocol itself. Randy explained the technical issues and gave me the proper Google terms to search to flush out the entire explanation.
And sure enough, after our call I started finding links such as:
that detail the IPv6 neighbor discovery problem I encountered when using wireless bridging. In my case, it wasn't a standalone bridge device, but the virtual network bridge when using a virtual machine. Note that in my testing the issue happened with Windows Virtual PC, but Randy's previous work involved VMware, which also had the issue. Again, this is protocol / driver related, not specific to IPv6 (network) or application layer software.
Further complicating the matter was the "incorrect" 'tcpdump' decodes. While the Ethernet header in the packets I posted showed source and destination MAC addresses, it wasn't the full picture. Wireless 802.11 has a different frame format than wired 802.3 Ethernet. However, the *pcap (winpcap in my case) libraries can't decode the 802.11 header if the wireless driver software doesn't pass it along. With my stock Broadcom wireless on a Dell laptop running Windows 7, I was seeing the "fake" header.
This final link from the OpenWRT project does a good job visualizing what is happening. Again, the link details physical bridges versus the virtual bridge introduced with machine virtualization software, but the same holds true.
So what does all this mean? Depending on how you look at this problem, it could be hardware, protocol or software related. For me, it manifested when trying IPv6 on Windows Virtual PC - so that was my first thought. It turns out the answer was much more involved and complicated than I imagined. However, broken IPv6 connectivity was the symptom and the casual user experiencing that will probably just say, "the network is down." No amount of planning is going to identify these unique use cases until they occur - hopefully during a pilot, more likely during production. You're going to need some smart people when you start rolling out IPv6.
Thursday, November 01, 2012
Windows Virtual PC IPv6: Part 2
In the previous post we saw the wireless card was responsible for some IPv6 connectivity issues between a Windows XP Virtual PC and the Internet due to it rewriting the VPC virtual MAC address to the MAC address of the HOST.
Suspecting the wireless card may be the culprit, I physically connected the HOST to the switch on the router and changed the VPC settings to use the wired NIC instead of the wireless one. A quick reset and back to testing - this time in somewhat reverse order.
I first checked the router to see what the MAC address for the VPC was. It was correct!
ROUTER# arp -a ? (192.168.10.102) at C4:17:FE:12:7D:75 [ether] on br0 ? (192.168.10.104) at 00:03:FF:13:7D:75 [ether] on br0
So I started my 'tcpdump' captures and launched the pings from the VPC.
HOST> tcpdump -i2 -nevvXX icmp or icmp6 00:03:ff:13:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv6 (0x86dd), length 94: (hlim 128, next-header: ICMPv6 (58), length: 40) 2001:db8:192:168:203:FFFF:FE13:7D75 > 2607:F8B0:400C:C03::68 [icmp6 sum ok] ICMP6, echo request, length 40, seq 553 0x0000: 586d 8f78 ad40 0003 ff13 7d75 86dd 6000 Xm.x.@....}u..`. 0x0010: 0000 0028 3a80 2001 0db8 0192 0168 0203 ...(:....p...|.. 0x0020: ffff fe13 7d75 2607 f8b0 400c 0c03 0000 ....}u&...@..... 0x0030: 0000 0000 0068 8000 9120 0000 0229 6162 .....h.......)ab 0x0040: 6364 6566 6768 696a 6b6c 6d6e 6f70 7172 cdefghijklmnopqr 0x0050: 7374 7576 7761 6263 6465 6667 6869 stuvwabcdefghi 00:03:ff:13:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 25380, offset 0, flags [none], proto: ICMP (1), length: 60) 192.168.10.104 > 74.125.228.80 ICMP echo request, id 512, seq 9728, length 40 0x0000: 586d 8f78 ad40 0003 ff13 7d75 0800 4500 Xm.x.@....}u..E. 0x0010: 003c 6324 0000 8001 ddbe c0a8 0a68 4a7d .< c$.........hJ} 0x0020: e450 0800 255c 0200 2600 6162 6364 6566 .P..%\..&.abcdef 0x0030: 6768 696a 6b6c 6d6e 6f70 7172 7374 7576 ghijklmnopqrstuv 0x0040: 7761 6263 6465 6667 6869 wabcdefghi
The two packets show the IPv6 and IPv4 pings (echo requests) respectively. Notice the first line of each packet has the VPC source MAC address - '00:03:ff:13:7d:75' - not the HOST MAC address as seen in the previous test on the wireless card.
And the satisfying result:
VM> ping 2607:f8b0:400c:c03::68 Reply from 2607:f8b0:400c:c03::68: time=50ms VM> ping 74.125.228.80 Reply from 74.125.228.80: bytes=32 time=166ms TTL=52
Just to make sure this whole testing regime wasn't an anomaly, I rebooted and reset to my wireless configuration and tested again with same failed results described in the previous post.
Why do the wireless and wired cards behave differently? I haven't answered that yet. Certainly, they are from different manufacturers and have different settings as verified in the "Properties" page, "Configure..." button, "Advanced" tab of each adapter. I did verify the common settings were matched between cards. I have some more research to do to get to the bottom of this one.
So, "does Windows Virtual PC support IPv6?" It's complicated. As we've seen, it depends on the application, the host and virtual machine operating systems, and in this case, the hardware used.
Wednesday, October 31, 2012
Windows Virtual PC IPv6: Part 1
I have a Windows XP Virtual PC for testing - among other things - all the Perl experimenting I've been doing lately around IPv6. Windows XP supports IPv6 if you install it - it's not on by default. However, I've had some issues with IPv6 connectivity from my VPC to the rest of the Internet.
I run in bridge mode as Shared Networking (NAT) doesn't make much sense with IPv6; there is no NATv6. With bridge mode, the VPC should act as another computer on the network with it's own IP(v6) address(es) and a unique MAC address. I should also note at this time, that I use wireless throughout the house and never connect over the wired LAN.
The setup is pretty simple. Note: I've changed the IPv6 prefix to the documentation prefix for this example but was using global unicast addressing for the actual troubleshooting tests.
+-----------------------------------------+
| (HOST) Windows 7 |
| c4:17:fe:12:7d:75 |
| 192.168.10.102 |
| 2001:db8:192.168:c417:feff:fe12:7d75 |
| |
| +-------------------------------------+ |
| | (VPC) Windows XP | |
| | 00:03:ff:13:7d:75 | |
| | 192.168.10.104 | |
| | 2001:db8:192.168:203:FFFF:FE13:7D75 | |
| +-------------------------------------+ |
+-----------------------------------------+
|
|
+-----------------------------+
| ROUTER |
| 58:6d:8f:78:ad:40 |
| 192.168.10.1 |
| FE80::5A6D:8FFF:FE78:AD40 |
| ('radvd' running for SLAAC) |
+-----------------------------+
|
__|_
__/ \__
/ \
| Internet |
\__ __/
\____/
When I try to ping the IPv6 address returned by 'dig' for "www.google.com" from the VPC, I get 'destination unreachables'. I can ping the same IPv6 address from the HOST. To be sure, I also tried the IPv4 address returned by 'dig' for "www.google.com" from the VPC and was successful.
VPC> ping 2607:f8b0:400c:c03::68 Destination host unreachable. VPC> ping 74.125.228.80 Reply from 74.125.228.80: bytes=32 time=22ms TTL=52
So the VPC has network connectivity all the way to the Internet for IPv4, but not for IPv6. Why? A packet capture may help.
HOST> tcpdump -i3 -nevvXX icmp or icmp6 c4:17:fe:12:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 19700, offset 0, flags [none], proto: ICMP (1), length: 60) 192.168.10.104 > 74.125.228.80 ICMP echo request, id 512, seq 19713, length 40 0x0000: 586d 8f78 ad40 c417 fe12 7d75 0800 4500 Xm.x.@....}u..E. 0x0010: 003c 4cf4 0000 8001 f3ee c0a8 0a68 4a7d .< L..........hJ} 0x0020: e450 0800 fe5a 0200 4d01 6162 6364 6566 .P...Z..M.abcdef 0x0030: 6768 696a 6b6c 6d6e 6f70 7172 7374 7576 ghijklmnopqrstuv 0x0040: 7761 6263 6465 6667 6869 wabcdefghi 58:6d:8f:78:ad:40 > c4:17:fe:12:7d:75, ethertype IPv4 (0x0800), length 74: (tos 0x20, ttl 52, id 62188, offset 0, flags [none], proto: ICMP (1), length: 60) 74.125.228.80 > 192.168.10.104 ICMP echo reply, id 512, seq 19713, length 40 0x0000: c417 fe12 7d75 586d 8f78 ad40 0800 4520 ....}uXm.x.@..E. 0x0010: 003c f2ec 0000 3401 99d6 4a7d e450 c0a8 .<....4...J}.P.. 0x0020: 0a68 0000 065b 0200 4d01 6162 6364 6566 .h...[..M.abcdef 0x0030: 6768 696a 6b6c 6d6e 6f70 7172 7374 7576 ghijklmnopqrstuv 0x0040: 7761 6263 6465 6667 6869 wabcdefghi c4:17:fe:12:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header: ICMPv6 (58), length: 32) FE80::203:FFFF:FE13:7D75 > FE80::5A6D:8FFF:FE78:AD40 [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has FE80::5A6D:8FFF:FE78:AD40 source link-address option (1), length 8 (1): 00:03:ff:13:7d:75 0x0000: 586d 8f78 ad40 c417 fe12 7d75 86dd 6000 Xm.x.@....}u..`. 0x0010: 0000 0020 3aff fe80 0000 0000 0000 0203 ....:........... 0x0020: ffff fe13 7d75 fe80 0000 0000 0000 5a6d ....}u........Zm 0x0030: 8fff fe78 ad40 8700 55bb 0000 0000 fe80 ...x.@..U....... 0x0040: 0000 0000 0000 5a6d 8fff fe78 ad40 0101 ......Zm...x.@.. 0x0050: 0003 ff13 7d75 ....}u c4:17:fe:12:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv6 (0x86dd), length 94: (hlim 128, next-header: ICMPv6 (58), length: 40) 2001:db8:192:168:203:FFFF:FE13:7D75 > 2607:F8B0:400C:C03::68 [icmp6 sum ok] ICMP6, echo request, length 40, seq 498 0x0000: 586d 8f78 ad40 c417 fe12 7d75 86dd 6000 Xm.x.@....}u..`. 0x0010: 0000 0028 3a80 2001 0db8 0192 0168 0203 ...(:....p...|.. 0x0020: ffff fe13 7d75 2607 f8b0 400c 0c03 0000 ....}u&...@..... 0x0030: 0000 0000 0068 8000 9157 0000 01f2 6162 .....h...W....ab 0x0040: 6364 6566 6768 696a 6b6c 6d6e 6f70 7172 cdefghijklmnopqr 0x0050: 7374 7576 7761 6263 6465 6667 6869 stuvwabcdefghi
The first two packets show the IPv4 ping (echo request) and reply (echo reply). The next two packets are more interesting (although, if you were paying attention, you could see it in the first two also).
The second two packets are an IPv6 ICMPv6 neighbor solicitation from the VPC asking for the router's MAC address - the IPv6 version of address resolution protocol (ARP), and an IPv6 ICMPv6 ping request (echo request). Let's look closer at the neighbor solicitation message.
You can see "who has FE80::5A6D:8FFF:FE78:AD40" (the router IPv6 link-local address) and the source of the request in line that follows, "source link-address option (1), length 8 (1): 00:03:ff:13:7d:75" - the MAC address of the VPC. However, look at the first line of that packet, "c4:17:fe:12:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv6 (0x86dd)". The source MAC address is the HOST MAC, not the VPC MAC! WHAT?!?!
Is this normal behavior for bridge mode, to rewrite the source MAC of the VPC with the source MAC of the HOST? Why the virtual MAC address on the VPC in the first place? The HOST operating systems sees the virtual MAC:
HOST> arp -a Interface: 192.168.10.102 --- 0xb Internet Address Physical Address Type 192.168.10.104 00-03-ff-13-7d-75 dynamic
Could this be just a 'tcpdump' anomaly, perhaps capturing at a point in the stack before/after a rewrite? Apparently not, because the router confirms the MAC address for the VPC IPv4 address (192.168.10.104) is in fact the MAC address of the HOST, not the virtual MAC of the VPC:
ROUTER# arp -a ? (192.168.10.102) at C4:17:FE:12:7D:75 [ether] on br0 ? (192.168.10.104) at C4:17:FE:12:7D:75 [ether] on br0
This touches on a problem that will manifest in the years to come regarding IPv6 support - "does 'X' support IPv6". The answer isn't really binary (yes or no). In this case, the VM can get IPv6 addresses and ping the HOST over IPv6; however, the wireless card (and I say that because in the next post, I'll show how the wired card does not exhibit this behavior) doesn't handle the virtual and host MAC addresses properly and thus breaks IPv6 ICMPv6 neighbor solicitation.
Thursday, October 25, 2012
More on IPv6 in Perl Modules
Recently, I went on a tear updating my Perl modules on CPAN to support IPv6. Since my modules (and scripts) rely on other core modules like Socket, IO::Socket and some non core modules like Net::SNMP and Net::Telnet(::Cisco), I had a task to make sure the underlying modules supported IPv6.
I already dealt with IPv6 in the core Socket module for Windows in a previous post. So now to deal with a higher level of code written by other developers. Would they be responsive?
Turns out ... YES! I worked with the author of Net::TFTPd a while back to get an ASCII / BIN mode bug fix submitted and he was again very responsive with my IPv6 ask and patch. So IPv6 capable TFTP server - Perl has one!
I also rely on Net::Telnet::Cisco which uses Net::Telnet to do all the heavy lifting. Net::Telnet looked like it hadn't been updated since 2002 but I submitted the query / patch and contacted the author. In a few days he got back to me and we had a pretty detailed dialogue about adding IPv6 support. There may be a coming version which does this "natively", but imagine my surprise when I found Net::Telnet was already IPv6-capable!
The "workaround" - and as workarounds go, this is the least kludgey I've seen - goes like this:
Open a socket using an IPv6 capable module - like IO::Socket::IP:
use IO::Socket::IP -register;
my $socket = IO::Socket::IP->new(
PeerHost => '192.168.10.1' # or 2001:db8:192:168::10:1
PeerPort => 23,
Family => AF_INET # or AF_INET6
) or die "not connected\n";
Then, use the $socket handle as an argument to the 'fhopen' parameter in the Net::Telnet new() constructor:
my $session = Net::Telnet->new(
fhopen => $socket
);
Jay Rogers (Net::Telnet author) is obviously a genius providing IPv6 support in Net::Telnet before Perl core even supported IPv6! Ok, maybe that's a stretch, but certainly the openness of the Net::Telnet API allows for this kind of "plug-and-play" with IPv4/v6 sockets and enables IPv6 right now, while in the background "native" support may be coming.
Thanks Jay!
Monday, August 20, 2012
IPv6 in Perl on Windows
The state of IPv6 support in Perl has long been lamented but there are those trying to change this including Paul Evans who's updating many of the networking modules - including the Socket core module - to support IPv6. It's a shame the C compiler shipping with Strawberry Perl still doesn't accommodate IPv6 on Windows.
I've been using Strawberry Perl after switching from ActiveState since version 5.10. I found myself needing more and more XS modules and the ActiveState PPM process was always lagging behind. I had a copy of MinGW gcc - the free Windows port of the 'gcc' compiler - and with 'dmake', I could build my own modules directly from CPAN. However, I had some issues and when I learned about Strawberry Perl including the gcc compiler in the distribution, I switched. I've used Strawberry Perl on Windows XP 32-bit and now Windows 7 64-bit.
I've also recently been doing a lot of IPv6 work and using Perl as a quick development platform to test the IPv6 protocol proved easy with the Net::Frame modules detailed in an early series of blog posts. However, when looking to create sockets with Perl, I found errors, most notably:
Socket::inet_ntop not implemented on this architecture
The lack of this function prevented the display of IPv6 addresses and it's missing complement - inet_pton - prevents the resolution of IPv6. These functions are certainly present in Windows 7.
The issue lies in the header and library files distributed with MinGW gcc compiler in the Strawberry Perl release. They simply don't identify the functions in the headers, nor provide linkage to them in the libraries. Fortunately, tools shipped with the MinGW gcc compiler in Strawberry Perl can be used to remedy the issue and get full IPv6 functionality. Here's how.
First off, we need to update the header file with the function prototypes. I did this by creating a new header file called 'ws2tcpip-win.h':
#ifndef WS2TCPIP_WIN_H #define WS2TCPIP_WIN_H typedef USHORT ADDRESS_FAMILY; #if (NTDDI_VERSION >= NTDDI_VISTA) WINSOCK_API_LINKAGE INT WSAAPI inet_pton(INT, PCSTR, PVOID); WINSOCK_API_LINKAGE INT WSAAPI InetPtonW(INT, PCWSTR, PVOID); WINSOCK_API_LINKAGE PCSTR WSAAPI inet_ntop(INT, PVOID, PSTR, size_t); WINSOCK_API_LINKAGE PCWSTR WSAAPI InetNtopW(INT, PVOID, PWSTR, size_t); #define InetPtonA inet_pton #define InetNtopA inet_ntop #ifdef UNICODE #define InetPton InetPtonW #define InetNtop InetNtopW #else #define InetPton InetPtonA #define InetNtop InetNtopA #endif #if INCL_WINSOCK_API_TYPEDEFS typedef INT (WSAAPI * LPFN_INET_PTONA)(INT Family, PCSTR pszAddrString, PVOID pAddrBuf); typedef INT (WSAAPI * LPFN_INET_PTONW)(INT Family, PCWSTR pszAddrString, PVOID pAddrBuf); typedef PCSTR (WSAAPI * LPFN_INET_NTOPA)(INT Family, PVOID pAddr, PSTR pStringBuf, size_t StringBufSize); typedef PCWSTR (WSAAPI * LPFN_INET_NTOPW)(INT Family, PVOID pAddr, PWSTR pStringBuf, size_t StringBufSize); #ifdef UNICODE #define LPFN_INET_PTON LPFN_INET_PTONW #define LPFN_INET_NTOP LPFN_INET_NTOPW #else #define LPFN_INET_PTON LPFN_INET_PTONA #define LPFN_INET_NTOP LPFN_INET_NTOPA #endif #endif // TYPEDEFS #endif // (NTDDI_VERSION >= NTDDI_VISTA) #endif
Next, copy that file to the appropriate location:
copy ws2tcpip-win.h c:\strawberry\c\x86_64-w64-mingw32\include
and update the existing 'ws2tcpip.h' file in that location with the following:
#include <ws2tcpip-win.h>
Now we need to create the library. This is done by first exporting the symbols from the appropriate DLL file - in this case, ws2_32.dll - and then creating the link library. The version of the MinGW gcc compiler with Strawberry Perl has 'pexports' included, so simply create the DEF file:
pexports c:\windows\system32\ws2_32.dll > ws2_32.def
Now create the library:
dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libws2_32-new.a --input-def WS2_32.def
Then put the new library in the appropriate location:
copy libws2_32-new.a c:\strawberry\c\x86_64-w64-mingw32\lib
Now we're ready to go. Get the latest release of Socket from CPAN, unzip and extract the tar file. Change into the directory and start the build process:
perl Makefile.PL
Now, before doing the 'dmake', edit the generated Makefile. Find the "DEFINE =" and "LDLOADLIBS =" lines and update them as per below:
DEFINE = -DHAS_GETADDRINFO -DHAS_GETNAMEINFO -DHAS_SOCKADDR_IN6 -DHAS_IP_MREQ -DHAS_IP_MREQ_SOURCE -DHAS_IPV6_MREQ -DHAS_INETNTOP -DHAS_INETPTON -DAF_INET6 LDLOADLIBS = -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lws2_32-new
Finally, 'dmake', 'dmake test' and 'dmake install' and you're good to go with IPv6!
Tuesday, July 31, 2012
Makeshift Mobile IPv6
For all its benefits, IPv6 also has increased support for mobility. This is due to the header structure of IPv6 accommodating extension headers - one of which is a mobility header.
However, given the slow adoption and limited deployment of IPv6, use of the mobility header isn't really prevalent and mobility of IPv6 nodes - my computer in this example - leaves a lot to be desired.
In fact, the only reason I have IPv6 working at home isn't from the forethought of my Internet Service Provider - Comcast, but because I'm tech-savvy and configured a Hurricane Electric 6in4 tunnel through their Tunnel Broker service.
NOTE: Comcast is very far ahead of many ISPs when it comes to IPv6 support including dual-stack support to end customers - unfortunately, just not in my area.
While the HE 6in4 tunnel works fine from my home - terminating on my home router with DD-WRT and providing all equipment in my home network with IPv4/IPv6 support - it doesn't help me when I'm not at home. When I take my computer anywhere - even into the office - I no longer can use IPv6, unless of course the network I connect to has IPv6 deployed (not likely).
My solution albeit not a very elegant one is to use another of the 5 free 6in4 tunnels HE provides me with. The first is for my home network and that stays static. The second one I have configured to a random endpoint which changes based on my location. HE offers a web-based update both manually and via a simple GET URL to change the local endpoint IP address of any of your 6in4 tunnels. The HE server examines the IP address from which it sees your request come from and adjusts the tunnel configuration on the server side. I even wrote a simple batch script to call the HE URL and configure the local tunnel interface on my computer. This works great ...
... but of course there's a catch. HE requires that the local IP address to terminate the tunnel be reachable via Ping. Therefore, if ICMP echo-requests are blocked or echo-replies are not sent, the tunnel won't get built. This is an issue as many sites prevent ICMP for security purposes - in fact, most all home routers disable ICMP from the Internet by default. For my home router, I can change the setting to have the tunnel built, but when I'm travelling, I'm relying on the network to allow ICMP so my mobile IPv6 tunnel can be built. Again, not the most elegant solution.
There are other options. SixXS offers a tunnel broker service and a client AICCU that provides AYIYA (Anything In Anything) support. This may provide a client-based alternative that doesn't rely on a provider network to support IPv6 or ICMP to build a 6in4 tunnel. I may test this next time I'm away.
Posts
