cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7536
Views
18
Helpful
11
Replies

How do you promote a static route over a directly connected?

dave.barton
Level 1
Level 1

Hi all,

I have a need for a static route to be used instead of a directly connected route. (Long story - involving firewalls and anti-spoofing.. but can go further if required)

I am using a Cisco 3750 switch. I notice directly connected routes have a metric of 0, and the highest metric I can give a static route is 1.

Therefore, how is it possible for me to make the switch use the static route and not the directly connected?

Any help would be appreciated!

Cheers,

Ben

11 Replies 11

Aaron Harrison
VIP Alumni
VIP Alumni

Hi

Not sure about your topology but maybe you can remove the connected route (presumably an SVI) and route all traffic via whatever the static route is pointed at?

Aaron

Please rate helpful posts...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

anand1871
Level 1
Level 1

Well u can define a static route with a metric of "0". (try, it is possible).

But you would face one problem.

This solution will only work if the static route you have given is more specific than the directly connected network.

Check and let me know!

Metric value for static route is between 1-255, there is no option for zero. 

Edison Ortiz
Hall of Fame
Hall of Fame

Ben,

You can configure Policy-Based Routing. Set a policy on the incoming interface to use the static route over the connected one.

___

Please rate helpful posts.

Thanks

Ben

If we knew a bit more about the environment we might be able to give better suggestions. But given what you have told us so far I believe that options that might work for you include the suggestion of Policy Based Routing that Edison suggests. The other alternative might be to configure a static route that is more specific that the connected route. For example if the connected route is for a /24 you can configure a pair of /25 routes that cover that address space and since they are more specific they will be used in making the forwarding decision rather than the connected route.

One of the responses asserts that you can configure a static route with an administrative distance of 0. I have tested this extensively and it does not work. There are several articles and books that state that a static route using a connected interface is treated as a connected route. From this many people believe that the static route gets an administrative distance of 0. But it does not. The static route gets an AD of 1.

HTH

Rick

HTH

Rick

Thanks for all the suggestions guys - i was a bit swamped last night and didn't get a chance to reply.

I have been looking into this, and I don't think I really understood the problem.

Let me provide a bit more background knowledge and a few addresses that explain the problem better:

We have a number of VLANs in the 10.0.0.0/16 range which we route between using a Checkpoint firewall, allowing us detailed control over traffic flows - we have a fairly comprehensive ruleset in place to suit our needs.

We also have a large flat switched network currently on a single VLAN. We wish to subnet this network as we are seeing high levels of arp broadcast traffic. However, we do not have any routers or an easy architecture to fit them into at a reasonable cost. We do however run a few multilayer switches on our core network which are capable of routing between VLANs.

I therefore thought a good solution would be to create a set of new VLANs in the 10.1.0.0/16 range (for clarity), and use the multilayer switches to route between these new VLANs. So far so good.

Next step was to create static routes between our checkpoint firewalls and our multilayer switches to allow communication between the two sets of VLANs.

The difficult arises when we enable ip routing on the multilayer switches. They have a management interface on a VLAN that is currently routed by the firewall. This allows us to easily control what can manage the switches without having to use ACLs on each individual switch.

However, as soon as IP routing is enabled we lose communication between our 10.0.0.0/16 networks and the management VLAN. This is due to a packet being routed through the firewall to the management VLAN, but the return packets following the static route on the switches and hitting a different interface on the firewall, causing anti-spoofing to drop them.

We have a similar problem coming from one of the new VLANs to the management VLAN, I believe for the same reason but in reverse.

I am reluctant to relax the anti-spoofing rules on the firewall as this could result in opening a security hole and we don't explicitly trust our internal users. I believe we may need to route packets on the switches based on the source address of the packets. However, being switches and not routers, these switches have a large number of interfaces, and policy routing needs to be applied on a per interface basis. Unfortunately these switches are part of switch stacks and therefore have up to 96 interfaces on them. If we could do policy based routing on leaving an interface aswell as on arriving we might be ok.

We are keen not to use the firewall to route between the new VLANs, as this puts a great deal more traffic through our firewall than we do currently and would probably result in far greater latency between the new VLANs where we have no requirement for security.

Ben

I appreciate your attempt to explain the environment but I am still not clear about some parts.

I think I understand that you have some routed subnets/VLANs in the 10.0/16 address space (routing provided through the Checkpoint firewall?) which are working ok.

I think I understand that you are attempting to configure some subnets/VLANs in 10.1/16 space which would be routed by multilayer switches which are not working.

You mention a management VLAN on the multilayer switches but I am not clear whether this is in the 10.0/16 address space or is in the 10.1/16 address space.

I am also not clear whether the problem you are having is with the management traffic or is with traffic between 10.0/16 space and 10.1/16 space. The beginning of your explanation seems to be talking about problems between 10.0/16 and 10.1/16 but the later part seems to be talking about management traffic.

If the problem is getting management traffic back to the Checkpoint then I would think that a static route for the Checkpoint address(es) would be more specific than the connected subnet routes and should be effective. If that is not the problem then I need better explanation of what the problem is.

HTH

Rick

HTH

Rick

Rick,

Apologies - its a difficult problem to describe!

You are correct the 10.0/16 VLANs are routed through the checkpoint firewall.

The Management Interfaces of the switches fall on a VLAN in 10.0/16 and as a result traffic is routed via the firewall (which is also used to control who has access to the switches)

The multilayer switches route traffic fine between VLANs on 10.1/16.

The static routes between the firewall and switches allow traffic to route fine between most of 10.0/16 and 10.1/16.

The problems arise between the Management VLAN (we'll call it 10.0.50/24 for argument sake), and the desktop VLAN (10.0.20/24 for argument sake).

Traffic from 10.0.20/24 gets routed by the firewall to 10.0.50/24, however, the return traffic uses the switches static route and gets sent back to the firewall on a different interface, and then gets dropped due to anti-spoofing. I don't want the switch to route this traffic at all.

Traffic from 10.1/24 to 10.0.50/24 gets routed by the switch, and therefore bypasses the firewall - this is a security problem for me. Also the return packets get routed by the firewall and dropped due to anti-spoofing as the firewall never saw the source packets.

Really I only want the switch to route traffic from 10.1/24 to the firewall. I don't want it to attempt to route on 10.0.50/24 at all. But I don't know how to achieve this!

Does that make more sense?

Cheers,

Ben

Ben

Thanks for the additional information. It helps though I still am not understanding parts of what is going on.

One aspect that is puzzling me is that the original post indicated that part of the problem involved static routes versus connected routes. But this explanation does not touch on that at all.

I am trying to follow the logic of your explanation: you say that traffic from 10.0.20/24 is routed by the firewall which would seem to indicate that 10.0.20/24 is not connected to the multilayer switches. Is that correct?

If the firewall routes 10.0.20/24 to the multilayer switches, then you need the return path to also be through the firewall. Obviously the multilayer switches have something that they are using to route toward 10.0.20/24, and it seems that it is not using the next hop that you want it to use. I do not see why you do not set up a route in the multilayer switches that indicates that the route to 10.0.20/24 should have the next hop address that leads it back to the correct interface on the firewall.

I am also puzzled by your statement that you do not want the multilayer switches to route the 10.0.20/24 to 10.0.50/24 at all. When you turn on routing on the multilayer switch it must be able to route any IP packet. It becomes a question of how it routes it. It sounds like you are asking it to route some traffic and bridge other traffic. If the problem existed on a router we might look to Integrated Routing and Bridging as a solution which can route some and bridge others. But that does not work on the multilayer switch (as far as I know).

Can you help us understand thsi a bit better?

HTH

Rick

HTH

Rick

Hi Rick,

Thanks for your patience.

Maybe I should start again.

Initially we had 16 VLANs within the 10.0/16 address space. We have some Cisco 3750's connected by dark fibre accross a couple of kms and then lower access switches all hanging of these by some means. The network is flat.

We have a checkpoint firewall hanging off one of the 3750s connected using a TRUNK port. The firewall has an IP address on all VLANs and is used to route traffic between VLANs based on its ruleset.

So if I have a user in VLAN 10 who wants to talk to VLAN 20, they travel to the firewall, if a rule permits the access, the firewall routes the packet on to VLAN 2 and the switches deliver at Layer 2.

The switches all have their default VLAN 1 disabled, and have an IP address on our management VLAN to allow us to manage the switches.

Its quite important that this IP is on a secured management VLAN as we don't want just anyone being able to snoop switch logins etc..

If we need to login to a switch, the firewall routes our traffic from whatever VLAN we are on to the Management VLAN.

One of our VLANs (the Desktop VLAN) is quite large (approx 1300 hosts) and suffers a great deal from too much arp broadcast traffic.

As we have a flat switched network across several kms, the cost of putting in routers to subnet this large VLAN is excessive.

However, the 3750's we have are perfectly capable of routing between VLANs, so we decide to create a load of new VLANs instead of subnetting our large VLAN. We don't want to use the firewall to route between these new VLANs as thats just giving the firewall more to do, and previously all these hosts were on a single subnet, so we have no need for any strict security - at most we can use ACLs on the switches if we even need that!

So far so good.

With 1300 hosts, we obviously can't make sudden topology changes. Therefore we need to be able to route between the Desktop VLAN and the new VLANs.

We therefore introduce the static routes between the firewall and the switches.

So the firewall says:

route 10.1.0.0/16 via Multilayer switch IP on 10.1.0.0/16

The multilayer switch says:

route 10.0.0.0/16 via Firewall IP on 10.1.0.0/16

This allows routing perfectly between the Desktop VLAN and the new VLANs.

However the moment we enable ip routing on the switches we break access between the desktop VLAN and the Management VLAN.

A packet leaves the desktop VLAN through the default gateway on the firewall. This is then routed to the Management VLAN. The return packet doesn't use the Management VLAN default gateway (firewall), it follows the static route on the switch and ends up at the firewall on 10.1.0.0/16. This is subsequently dropped as the firewall knows the packet hasn't come from the 10.1.0.0/16 network, it originally came from the desktop VLAN on 10.0.0.0/16.

It might seem we can define a route on the switch to say:

route 10.0.50.0/24 (management VLAN) via 10.0.50.254 (firewall). However, this would result in all packets from 10.1.0.0/16 being dropped by the firewall.

The other problem is that if we are on a new VLAN and want to talk to the management VLAN. The packet goes to its default gateway on the switch. The switch says - "I have an IP on the management VLAN, its directly connected" - therefore it ignores the static route, and passes the packet on its way. We have now bypassed the firewall, which is bad.

Incidentally the return packets get routed through the firewall and dropped, as the original packet didn't come through the firewall, there is no entry in the state table for its return.

I think if we turned off the management interface on the switch and managed it through the interface on 10.1.0.0/16, I assume everything would work. However, we don't want to do this for a whole load of other reasons I wont go into.

Im sure there must be a fairly simple solution - I just don't have enough experience!

Cheers,

Ben

Ben

Thanks for the additional explanation. I am getting closer to understanding your situation - but not quite there yet.

You started your explanation by saying that there were 16 VLANs within the 10.0/16 address space. Then you talk about a flat network. That seems inconsistent. If it were flat I would expect it to be a single VLAN. Perhaps you can clarify.

I am also puzzled at this statement:

The multilayer switch says:

route 10.0.0.0/16 via Firewall IP on 10.1.0.0/16

why would the multilayer route 10.0/16 via 10.1 instead of routing it back via its address in 10.0?

I am not clear from your explanation whether there is a dynamic routing protocol running - though the reference to static routes suggests that there is not. I wonder if a solution to the problem might be in a dynamic routing protocol. With OSPF (2 OSPF process IDs) or with EIGRP (2 AS numbers) you might create two routing domains (10.0/16 in one and 10.1/16 in the other) and have more control over how traffic moves between them.

HTH

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: