Home ........ Travels ........ Web 3D ........ Socials

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."

ParameterR1R2
SourceLoopback 1Loopback 1
Redistribute into BGPIPv6 Connected
Set origin IGP
IPv6 Connected
Set 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.

Wednesday, December 05, 2012

Smartphone Snacks

Last night I fed my AT&T Samsung Galaxy S3 some jelly beans - that is, the Android 4.1 Jelly Bean update. AT&T / Samsung announced availability earlier this week. However, they also said there would be no over-the-air update. So this was a manual process - first installing Kies from Samsung.

The Kies install on Windows 7 x64 was kludgy. I started the install and it kept looping at "Installing Hotfix". I pressed "Cancel" and it warned me it hadn't completed the install and asked for a confirmation. I canceled that and allowed the install to continue and that seemed to skip out of the loop as the install proceeded and completed successfully.

The next step was to connect my GS3 to the computer with USB and Kies recognized it. I got a pop-up for the new firmware update and allowed it to go forward. A few confirmations and a very slow loading and update process followed. But again, SUCCESS!

I've only been exploring / using Jelly Bean for a few hours but it seems nice and smooth. I see I have an explicit "Driving Mode" (although I don't know what it does) even though I already side-loaded Google Car Home. I already had loaded Chrome as my default browser so that remained. I didn't like that the Accounts under "Settings" are now all listed in the main Settings menu rather than a sub menu. The previous sub menu had an icon regarding sync status for each account. Now you need to click into each account to see the sync status.

I haven't had a chance to try IPv6 yet. Previously, I would get IPv6 addresses via SLAAC on my home network, but I didn't have access to the IPv6 Internet. I'll do some testing in the next few days when I find the time.

 

Copyright © VinsWorld. All Rights Reserved.