Over analyzing and need some help

[tommygunnah]

Hey guys and gals,

Long time lurker but first time poster...I need to bounce some things off of you folks and hoping I can get some feedback. 

Our Environment has static routes EVERYWHERE lol... I'm in the process of implementing OSPF to get this cleaned up but in the mean time I need to start getting a SVI going for a new section of the office. We Sonicwall firewall that does some routing, we have a 2821 that is/was the main GW but we are trying to migrate over to the sonicwall for that. Our core is a 3850 and I'm implementing this new SVI on a 2960x.

My question is, is it best practice to put the SVI on the core and just trunk to the 2960x or put it on the 2960x and just trunk the other way to the core?

Thanks for all your help!

[Predrag Jovic · Accepted solution]

Generally, typical design is to create SVIs for all VLANs on collapsed core device and those SVI typically are used as default gateways. On 2960X should be created one SVI and configured default gateway that is pointing to the core (for maintenance purpose) and make trunk uplink to 3850.

Regarding OSPF implementation - on all routers create OSPF process, configure it, check OSPF adjacency between neighbors and OSPF database (are all routes present etc). If all routes are present (and static routes were not redistributed into OSPF :) ) you can remove static routes. and OSPF will populate routing table (it should be smooth transition).

[tommygunnah]

Thank you Predrag!

So if I put the SVI on the switch, wouldn't I need to also temporarily put static routing on the switch to be able to talk to the core?

[mattjones03]

Hi

No, as your L3 communication would take place within the core switch.

As long as the VLAN terminates on your core, the SVI interface would be the default gateway for that particular VLAN.

Hope this helps

[mattjones03]

Hi,

I would agree with ‘Predrag Jovic’ here.

To add to this;

The approach of defining your L3 functionality in a core layer should enable you to vastly reduce your static routing entries distributed throughout your estate, and it’s overall complexity. Some caveats to this approach are;

- Ensure you have a resilient core switch solution (depending on business criticality)

 * Consider; Independently deployed (non-stacked) Cisco 3850 switches and utilising HSRP.

- The traffic cost imposed on bringing the traffic back to the core (High capacity services etc)

Regards

Matt

[tommygunnah]

So we currently have a router that has a default gateway of a 192.168.0.1, the core has a vlan 1 interface with a 192.168.0.2 and then the inside interface of our sonicwall firewall is 192.168.0.3. They want to move everything over to the .3. Right now we have equipment pointing to the .3 and the .1. With this new SVI that im trying to setup would I need to do the routing on switch itself or the core?

int vlan 130

ip address 192.168.130.1 255.255.255.0

then where would I need to put a temporary static route for the two to talk?

[Asemmoqbel]

The best thing to do is to put SVI for vlan 130 on the core as default gateway and make the link between core and the switch as trunk. so now the traffic of vlan 130 when hits the switch it will be forwarded to the core through the trunk for the gateway.

If you want to enable communication between Vlan 1 and Vlan 130, this should be happen at the core by inter-vlan.

[Carlos Villagran]

Tommy,

As per design perspective, everyone is right in telling you to add the SVIs on the Core. However, from troubleshooting perspective (if something gets broken at some point in the future) those SVIs in BOTH Core and Access will be really really helpful.

Regards,