YUM repository is now HTTPS-enabled and also contains .repo file to easily attach the repository to your server yum installation.
Almost all software packages (both binary and source ones) also were updated with their current respective versions.
Probably most of us who tried to build some L2 tunnel over Cisco L2TPv3 implementation (L2TPv3 xconnect) hit the basic MTU issue in the tunnel. MTU seems to be heavily limited, and ICMP responses from routers inside the tunnel try to clamp it.
Here's some solution to the generic MTU issue I found when setting up L2TPv3 interworking ethernet mode tunnel between 1841 and 7200 G2 routers. Critical points of the solution are marked blue.
1. Set up xconnect as usual with interworking ethernet, using proper pseudowire class, L2TPv3 class and other parameters.
2. Make sure pseudowire ip path MTU is lower or equal to the real MTU between routers.
3. Set MTU on xconnect termination interfaces both sides 4 bytes higher than your desired tunnel MTU.
4. Make sure ip virtual-reassembly is enabled on router interfaces that are used to forward L2TPv3-encapsulated traffic (the IP 'uplink' interfaces between the tunneling routers).
5. Push TAGGED VLAN with your traffic to be tunneled over the tunnel. If you need to push multiple VLANs over tunnel, use QinQ. Set/remove this tag you use for tunneling on switches, neighboring routers or any other stuff you have.
Where does this come from: it was confirmed between 1841 (IOS 12.4) and 7200 G2 (IOS 12.2SR) that L2TPv3 tunneling implementation on G1 routers (G2 not tested) mangles anything with IP ethertype, trying to clamp MTU and stuff and dropping packets with DF bit set. But when ethertype is VLAN ethertype, it just passes traffic over, fragmenting L2TPv3 packets where necessary. This allows to carry any traffic with MTU just 4 bytes less than MTU routers interfaces are capable of, over L2TPv3 tunnel. IP DF bit also don't propagate to L2TPv3 traffic when carrying VLAN-tagged frames over L2TPv3 tunnel, so it can be used properly over tunnel without affecting tunnel traffic itself.
So if you just want to push general untagged IP traffic over the tunnel, push it into some trunk VLAN from nearest switch to tunneled port on router and receive the same way on the other side. If you want to push some tagged VLAN or set of tagged VLANs, just push them directly and receive on the other side of the tunnel. If you need both general untagged and tagged traffic, use QinQ on switches to put everything to be tunneled over L2TPv3 under some common dot1q tag, and receive the same way.
I'm not sure if all Cisco router models (especially G2) behave the same way, some may differ, but two 1841s/two 7200s/1841<->7200 are surely doing ok.