Carrier Cutover Trouble

[pbiggs]

If anyone can help me with this issue it would be greatly appreciated. I'm a new Sys Admin working in a Cisco shop. In our headquarters they had moved from using a router to a Cisco 9400 which also handles routing. Currently we have a line connection to one of our branches that is working but they wanted to upgrade the bandwidth and the carrier has installed a new service line. They provisioned the line and gave us instruction it was to be a tagged line for vlan#55. The plan had been to do the changeover early in the morning so it would not cause an outage. We tried this morning and failed. No access whatsoever.

I configured a new port on the 9400 switch similar to what is there and working now. I also configured the router interface as well. Here are the configs: **Please note that the IP had to be changed back on the switch so it would work on the old line for today.

9400#show int g9/0/48 switchport
Name: Gi9/0/48
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: 1,55
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Vepa Enabled: false
Appliance trust: none
9400#

9400(config)#int g9/0/48
9400(config-if)#switchport trunk native vlan 55
9400(config-if)#int vlan 55
9400(config-if)#ip add 10.10.10.53 255.255.255.252

On the Branches router which is an old 2811 the config is:

interface FastEthernet0/1
description EVPL to HQ
no ip address
ip flow ingress
duplex full
speed 100

interface FastEthernet0/1.1
description EVPL
encapsulation dot1Q 55
ip address 10.10.10.54 255.255.255.252

Thank you in advance.

Pete

[balaji.bandi]

If you looking to connect 

Cat 9400---Cisco router 2811

I would suggest below config :

Switch :

interface GigabitEthernet 9/0/48
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 55
 switchport trunk allowed vlan 55
 switchport mode trunk

If you don't need Trunk you can make it as access port that should still work between Router and Switch

interface Gig 9/0/48
switchport
switchport mode access
switchport access vlan 55
spanning-tree portfast

When you move from OLD device to new device, make sure you also clear arp (may be stuck with old MAC address, if default arp config it will stay longer)

[pbiggs]

Thank you for your help with this. I will not be able to attempt this cut over again until next week but I will let you know if it works. Thank you,

Pete

[pbiggs]

Thanks for getting back to me. With regards to it being a trunk the carrier specified this and to use vlan 55 as native. This is a very odd problem since right now we have a circuit using the same setup that is working but just using a different vlan number. I have not tried it set as an access port yet though and will try that out as well. Thank you. 

[balaji.bandi]

no problem keep us the post, also if fails and you have some maintenance window - plan what output you can capture to troubleshoot and help to resolve the issue.

[paul driver]

Hello
I agree with @balaji.bandi  regards the switchport, if the rtr is connecting to the switchport via g9/0/48 and the rtr interface is tagging for only vlan 55 then the switchport can be just an access port in vlan 55, but have your created vlan 55 on the switch?

conf t
vlan 55
exit

Also I don't see any routing protocols on either the switch/rtr, what are your running (BGP/OSPF) and Is routing actual enabled on the switch?

Lastly I cannot visualise how the rtr/switch/isp circuit are connecting together, Maybe post a topology diagram along with the running configuration of the c9400 and branch rtr?

[pbiggs]

Paul,

Thank you for getting back to me. We are under time constraints on this for troubleshooting since the branch needs to be up and we can only handle at odd times but I guess this is normal. One more thing in the mix is that this remote site has no cell signal which makes it so one person needs to be on site and another at the HQ with spotty communication at best. 

The switch is using EIGRP and that was a question I had a well. Will Eigrp cause this issue and should I just add a static route on both sides? 

I have not added the configs for a few reasons but primarily due to the fact that this switched config goes on for days it seems. I'm hoping to resolve this without having to do so. 

[Richard Burts]

Pete

I am not clear what the provider has told you to do about this. But I agree with @Georg Pauwen that the configuration you provide from the remote router

interface FastEthernet0/1.1
encapsulation dot1Q 55

means that the router is treating this as a trunk and is tagging traffic on vlan 55 - not treating it as native. Since this is working I do not think that you want to change the remote side. At a minimum I suggest that you configure the port on 9400 as a trunk but without the specification of vlan 55 as native.

I am a bit puzzled at part of your original post. It has this

Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)

which indicates that the native vlan is 1, but then has this

9400(config)#int g9/0/48
9400(config-if)#switchport trunk native vlan 55

Am I correct in understanding that you did the show interface and then made the config change? If so I suggest that you remove the native vlan 55 from the config.

I would point out this part of your original post:

Operational Mode: down

If the operational mode is down then you need to figure out why that is - and I doubt that it has to do with which vlan is native.

[pbiggs]

Thank you Richard. Yes, the configs were reverted back to allow them to work again. I just specified the changes in the post. This is actually my first experience in a cutover so it is all new to me. When doing this the carrier specified these changes. Also I was going off what had been done by my predecessors. I will try the recommendations you gave. I appreciate all the help I getting here. Glad there is experienced people willing to help.

Thank you 

Pete

[Georg Pauwen]

Hello,

did they tell you to use that Vlan (55) as native ? That could be the problem, as on the branch router, it is configured as tagged (non-native):

interface FastEthernet0/1.1
description EVPL
encapsulation dot1Q 55
ip address 10.10.10.54 255.255.255.252

Check with the ISP what the actual settings are on their side (Vlan 55 set as native or not).

[pbiggs]

Hello

Thank your for your response. Yes, they did specify vlan 55 for tagging and I have added as native.

[pbiggs]

I wanted to give everyone an update on this issue. We had a call with a tech from the carrier this morning to try to work out the issue. He advised that the old Cisco 2811 routers interface had top speed of 100 and we would have to configure both sides at 1000 and that is what is causing the issue. So our plan now is to get a newer router Cisco 4300 in place and try this again. Shouldn’t be too long because I set this router up earlier today. I just have to get it installed now. I will post the outcome. Once again, thank you everyone for your assistance with this issue.

[balaji.bandi]

Good to know -- you are near the solution..

[pbiggs]

I am happy to tell you that we completed the cut over last night. We installed a new router configured both sides router to 9400 switch the same and its up and working. Thanks to everyone for the information you provided. It was very helpful and I now know what to look at first for future issues like this. 

[balaji.bandi · Accepted solution]

good to know all is good, can we mark it as resolved so other users will benefit with the solution?