Trunking configuration

[darren-carr]

Hi all

I am in the process of implementing a secondary Internet link into our environment. I am using Fortigate firewalls and Cisco switches in my environment. I am not seeking any assistance with the Fortigate component.

My question is this. On my Fortigate unit I have configured two VLAN interfaces (one for each ISP). VLANS14, 19

I have two switches connected together (2960G's 48-Port).

The Fortigates are configured in a HA cluster so they appear to the network as a single device (I have two of these also connected together).

I have connected the equipment as such

Fortigate1 Port 8 -> Cisco 2960 (Switch1) Port Gi 0/31

Fortigate2 Port 8 Ciscos 2960 (Switche2) Port Gi 0/31

I have configured the Cisco Ports Gi 0/31 as trunk ports. And I have explicitly defined the vlans that are allowerd 14, 19

On switch1 I have defined an access port Gi 0/31 as an access port in VLAN14 and have patched the ISP router into here.

On switch2 I have defined an access port Gi 0/32 as an access port in VLAN19 and have patched the ISP router into here.

Now my question is this, do I need to also allow VLAN1 (which is the native vlan on the switches) also on the trunk?

The switches are running PVST which I want to change to RSTP as part of the implementation.

So to enable RSTP to work properly i.e. in the event of hardware failure be it the Fortigate or Cisco the network will continue to operate? If the Fortigate fails it sends gratuious ARPs and updates the switch MAC-ADDRESS table for all interfaces.

Hope this makes sense? Appreciate this aint no Fortinet forum!!

[cbeswick]

Hi Darren,

Just a few pointers that may help.

1)It is common practice to remove Vlan 1 from all links, including trunk links. If you need to use a native Vlan perhaps use a management Vlan that you use for switch access.

2)Changing your STP protocol to Rapid-PVST may not improve convergence, this is because RSTP is Cisco proprietary (I think??). So you will have RSTP on your switches and standard PVST on your Fortigates. RSTP can interoperate with PVST but it operates in a "fallback" mode of operation relying on the timers set on the root bridge, rather than the fast keepalive mechanism integral to the fast convergence in RSTP.

I would check to see if your fortigates support STP uplink fast, which could help improve STP convergence. Failing that, tweak the STP timers on your root bridges for Vlans 14 and 19.

[darren-carr]

Hi

Thanks for taking the time to reply.

In response to your points

1) I was just hoping, or wanting to confirm, where STP (whichever mode/version) ran, i.e. sending out the BPDU's, is this in your native VLAN? I really don't want to expose this information across the trunk so am happy to not carry it on the trunk to the Fortigate. The Fortigate is configured in NAT/ROUTE mode so I don't think it is capable of forwarding the STP information. You can deploy them in TRANSPARENT mode (into your L2 environment) but I am not doing this in this case. All I am doing is using a VLAN (tagged) to forward the data over the two Internet links.

So I guess the answer is I don't need to carry the native VLAN (VLAN1). STP will just use the port to determine its forwarding decisions for the VLAN it is associated with.

2) I am hoping to use the IEEE standard RSTP, not the Cisco proprietary RPVST (apologies for the confusion). I currently have PVST configured on the two switches (out the box config) and wanted to use RSTP to speed up convergence.

I have configured PORTFAST on all of the access ports that are associated with the Fortigate cluster and have tested failover of the Fortigate (pulling the power of one) and it fails over pretty seamlessly (less than 10 seconds to begin forwarding again).

I would like to confirm however, if you leave your native vlan as vlan1 if this vlan carries all the STP, CDP traffic, etc for the protocols that run on the switch?

Thanks for your help

Darren

[cbeswick]

Darren,

The IEEE version of Rapid PVST is called Multiple Spanning Tree. It works on the premise that you have a number of Vlans blocking on 1 port and forwarding on another, and bundles them together into an "instance". So in essence you have two instances of spanning tree, instead of many different instances for every eventuality. This is only a very basic explanation.

There is a feature on most recent IOS releases known as "Vlan 1 minimisation", I cant remember exactly how it works, but if you remove Vlan 1 from trunk links, all control traffic will still flow over the link, even in the absence of Vlan 1.

Hope this helps.

[sharma16031981]

Hi,

Even if you run switchport trunk allowed vlan except 1 then also vlan 1 will not be removed from that link as all the control traffic will use that vlan

You may check with sh interface x/y switchport command.

hemant

[Chris McCann]

Hi Darren,

Doing a very simular thing but only one ISP but ran into a problem with the fortigate talking to the cisco core switch.

I have a problem, we have a failover fortigate FW pair both linking to a single switch which then has a trunk connecting to our core switch.

If I remove the single switch and run the pair of cables from the fortigate into the core then the FW fails and the ports on the core do not come up. I have the ports on the core configured as access ports.

The switch being removed has almost no config on it. the interfaces to the FW are access vlan 4, back to the core the interface is trunk.

Here is the config from the core switch.

First is the Trunk port that links to the switch I want to remove.

interface GigabitEthernet2/29
description Primary-InsideFirewall
switchport
switchport mode trunk
spanning-tree portfast edge
end

interface Vlan4
description Firewall VLAN
ip address 192.168.1.1 255.255.255.0
ip pim sparse-mode
end

I have configure the two new ports as below, which i want to be direct links to the fortigate.

GI2/30

description Primary-InsideFirewall

switchport

switchport mode access vlan 4

spanning-tree portfast edge

end

Gi1/30

description Secondary-InsideFirewall

switchport

switchport mode access vlan 4

spanning-tree portfast edge

end

But as mentioned when patching direct into the core switch the ports fail to come up.

I got this from the CISCO log.

.Sep 10 07:10:08: %PIM-5-NBRCHG: neighbor 192.168.1.2 DOWN on interface Vlan4 DR
.Sep 10 07:10:08: %PIM-5-DRCHG: DR change from neighbor 192.168.1.2 to 192.168.1.1 on interface Vlan4
.Sep 10 07:16:20: %PIM-5-NBRCHG: neighbor 192.168.1.2 UP on interface Vlan4
.Sep 10 07:16:20: %PIM-5-DRCHG: DR change from neighbor 192.168.1.1 to 192.168.1.2 on interface Vlan4

192.168.1.2 is the firewall virtual IP, 

192.168.1.1 is the core SVI interface for that particular vlan. The second part in bold is when I patched the orginal single switch back in and the FW comes back up.

I know very little about IP PIM. However from my understand since the firewall and core SVI are in the same vlan this should make no difference.

Any advise welcome!