two different approaches on the same problem

Let's presume your isp had the following config on your its side:

interface FastEthernet0/8
description Link to Dan - 1M
switchport access vlan 634
switchport trunk encapsulation dot1q
switchport trunk native vlan 635
switchport trunk allowed vlan 2,635
switchport mode trunk
no cdp enable
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
spanning-tree guard none
service-policy input dan-1024

Why is it trunk? Because in between this switch and myself there is a radio bridge which is currently using vlan2 (for monitoring purpose). All of the sudden this config stops working after an IOS upgrade (says my ISP). (I was accessing vlan 635 on my side : switchport access vlan 634).

Since it was unlikely for my ISP to solve the problem (i don't know exactly what was wrong, they did not know either), here's the two approaches i found for this:

I had a 1800router with a NM8-ESW card

1. moved the cable from the radio unit to the NM-8ESW interface, put one of the fast
interfaces (fe0/0/1) to trunk mode, created vlan 634 (corresponding to
my vlan in the isp network), and after this changed the source
interface for tunnel1 from fast0/1 to vlan634 (which i configured with
ip address x.y.z.6/30). Was working, but had to try the next thing as well (see 2.)

2. put the cable from the radio unit back to fast0/1 , created a subinterface
on this (fast0/1.1) , assigned x.y.z.6/30 and encapsulation dot1q
634. Working again. Moved tunnel source to fa0/1.1

My relevant config:

ip sla monitor 1
type echo protocol ipIcmpEcho z.g.h.3
frequency 5
ip sla monitor schedule 1 life forever start-time now
ip sla monitor 2
type echo protocol ipIcmpEcho h.k.l.2
frequency 5
ip sla monitor schedule 2 life forever start-time now

track 123 rtr 2 reachability

!
interface Tunnel1
description gre pri tunnel
bandwidth 1024
ip unnumbered Loopback0
ip hold-time eigrp 31 60
ip tcp adjust-mss 1300
delay 40000
keepalive 33 3
tunnel source FastEthernet0/1.1
tunnel destination z.g.h.3

interface FastEthernet0/1.1
description radio connection x.y.z.6 to isp
bandwidth 1024
ip address x.y.z.6 255.255.255.252
encapsulation dot1q 634

the other tunnel doesnt matter, my other link was working fine.

Why I posted this? Because I need some advice. The last version is the version I'm using now, but I would like a second opinion on the two versions I've posted. Or maybe some other solution. Thanks in advance.

This summer's (minor) network upgrade.

So, on Friday we started working on extending the data center. What we've done? Well, in order to accommodate the FPSO we really had to work a lot. Started at 20:00 on Friday and finished next day at 12:00. So about 16 hours. First thing done was cleaning the cabinets (ie throwing all the old cables and laying down new ones). Now what's so cool about this is that it will make life a hell lot easier since... well, i will later post a picture with the old cabinets so you'll get the big idea why now it's easier. Next, since the fiber leads were not in place yet (in the new trunking), we had to find some other leads and put them on top of the cabinets. Not a very elegant solution, but it worked. Next, since we Distribution and Access were collapsed into two Cisco 6509 switches doing HSRP. Since we had to accommodate lot of servers for the FPSO, we decided that the 6509s should be placed in the WAN part. So two stacks of 4x 3750 switches were set in place of this 6509s and .... well, to make a long story short , we switched from L2 to L3. Everything seems more organized right now, some parts have become more redundant (we had HSRP only on 6509 switches, now this moved to WAN part and everything became more redundant since everything has 2 or 3 fibers connecting here. Not to mention the new cabinets which each have 2 ups's , and since each router has two power supplies , each router is connected to two different upses. ) Tunnels are now terminating on a 3800 router (they were terminating into a 1800), and soon we'll change the raw internet router (now a 3620 which is barely over the minimum of what we need. not to say that with NBAR on place it used to choke before enabling NBAR on remote routers as well). Moved everything from Vlan1 to Vlan50 (at least for management purpose), made vlan400 for .187.0/24 class (Connecting the oil rigs ,remote locations and so on). Also Rami was kind enough to do some more overtime (I guess the guy spent about 24 hours here), and also upgraded the Call Manager so now it doesn't take like 15 seconds for each login/logoff.

The major network upgrade is not written (but took place). Kept me for almost 37 hours awake. Will post this at a later time.