cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3521
Views
0
Helpful
32
Replies

Hi all, need advice on OSPF and private vlans

Ableton34
Level 1
Level 1

Hi all.

I have a project to complete and need some help on the possible solution I can use.

Basically we have ospf area 0 and the users in question are in ospf area 7 and is a stub.

I need to route the traffic from these users out through area 0 through 3 core devices, onto an external firewall interface to be placed onto the vpn that sits on it. The firewall is not included in the ospf domain.

My thinking was that the firewall has a default route back into the ospf domain so dont need to worry about traffic coming in, however my job is to segregate these users and take them out of our core network and place them onto an external network via this vpn.

Not sure how to achieve this apart from static routing redistributed but surely this does not seperate their traffic only points the route to ospf?!

I was thinking I might have to use private vlans or policy routing but when I try policy routing the policy gets ignored due to normal forwarding.

Any help and advice would be greatly appreciated.

Cheers

Steve

1 Accepted Solution

Accepted Solutions

Steve

Please don't take this the wrong way but you need to read my answers more carefully ie.

1) you need to use "set ip next-hop recursive x.x.x.x"  because the next hop is not directly connected. That is assuming the recursive next hop feature is supported on the 4500.

2) if this is for traffic to the firewall then unless you were using dummy IPs in your initial posts the source IPs should be the area 7 user subnet ie. 10.2.1.0/24 but they aren't in your example (although they were in a previous example).

What is int gi3/12 connecting to. If it is the 6500 then you are applying the PBR to the wrong interface as well as the interface acl and could well affect other traffic.

If this is traffic to the firewall this config should be -

1) applied to interface connecting the 4500 to the 3550

2) the source subnets should be 10.2.1.x and what you have as the source subnets should presumably be the destination subnets.

If the gi3/12 interface is the one connecting to the 6500 and the 4500 is used by other people within your network if you had applied that configuration you would have effectively cut off all users that go via the 4500 to area 0.

Jon

View solution in original post

32 Replies 32

Jon Marshall
Hall of Fame
Hall of Fame

Steve

Depends what you mean by "segregate". It's not clear what the exact requirement is.

I'm not sure why your PBR didn't work but even if it did that is really no more segregating traffic than using statics and redistributing into OSPF unless you are actually using PBR so only those subnets can get to the firewall.

If the users are in area 7 and the firewall in area 0 then private vlans would not help because you need to route the traffic to the firewall across areas.

So what is the actual issue ie.

1) what do you mean by segregate

2) is the firewall internal interface routable within OSPF or is that why you are trying to use PBR ie. you don't want to have the firewall interface accessible to all areas just to those subnets that need to use the VPN ?

Jon

Hi Jon, thanks for the quick reply.

Basically the users will remain based in one of our buildings but we are handing them over to an external company to manage, so we need to put their traffic out of our core and onto the vpn that goes out to the external company via the Checkpoint firewall.

In answer to your questions, what i mean by segregate is that although they will still be physically at our site their traffic needs to be seperated from ours, does that make sense?

The firewall interface will remain out of the ospf domain and yes various other subnets use the vpn.

I guess I wanted to use pbr but as I say, I created a map etc but in a test rig that matches the network but the policy fails as after adding the static route on the core device attached to the firewall the static route was redistributed therefore the policy map wasnt required, the switch just did normal forwarding.

Basically I have been asked to come up with a solution on how to move these users from our network onto another external one without physically seperating them!

Thanks a lot

Steve

HI Steve,

Do you want the external companies traffic to go over the VPN only and further as in overlapping subnets. what i mean is that even their internet traffic goes over the VPN first?

Steve

We really need to see the topology in terms of how many network devices are between the users in area 7 and the firewall accessible from area 0.

There are a number of different options eg. VRF-Lite, PBR, GRE tunneling but without knowing the devices it's difficult to recommend anything at the moment.

Is area 7 only for these user or are there mixed with users who can access the full network ?

What device routes the vlans for the users ?

Jon

Hi Jon

The users in area 7 have a 3550 and they connect to a 4507, the 4507 connects to a 6513 the 6513 connects to an HP 7506. All core switches mentioned are in area 0 and the firewall is outside.

There is a WAN link between the 4507 and the 6513 (they are at 2 different core sites seperated by about 1 km).

Area 7 is only for the users mentioned, literally only about 12 people! They do have a voice and data vlan.

The 3550 routes the vlans. We do have other external sites that use a vpn out to this external company and for them there is just static routes set up on the HP core connected to the firewall.

My problem is that I have been asked to seperate these 12 users and place them onto the vpn.

Any advice is great. Hope this helps!

Steve

Jon Marshall
Hall of Fame
Hall of Fame

Steve

Thanks, that helps.

GRE is defintely out because apart from the 6500 GRE tunneling is not supported on the Cisco switches.

It's good that area 7 is only for these users and not mixed up with other users.

So if i understand correcty the 4500 interface connecting to the 6500 is in area 0 and the interface connecting to the 3550 is in area.

Or is the 3550 connected to both areas and the 4500 totally in area 0 ?

Can you confirm the above ?

In terms of keeping them separate there are 2 possible choices. You can either -

1) use VRF-LIte, although i'm not sure whether the HP switch would support this. With VRF-Lite you are in effect creating virtual devices on the same physical device. This means each virtual device has it's own routing and forwarding table so it is quite secure because you would only populate the routing table with the routes needed so there would be no way for users to jump to thes rest of your networks.

The downside is that is can become quite complex to configure. If the 4500 is only used to connect are 7 to area 0 then that would not be a problem but the connection from the 6500 to the HP could and i don't even know whether the HP supports VRF-Lite functionality let alone how to configure it on that switch.

But it would, at least from the 4500 to 6500 to HP provide complete separation in terms of routing and forwarding. Once it got to the HP it wouldn't but that might not be an issue.

2) Use PBR (possibly together with acls). This is easier to configure ie. you configure PBR on the 4500 and the 6500 to get the traffic to the HP switch. But you do not get the actual separation you get with VRF-Lite ie. the traffic simply overrides the existing routing tables.

The other thing to bear in mind with PBR is that you also have to configure the return traffic as well so each device would need multiple PBR configs.

Again i don't know whether the HP supports PBR but it may not be an issue depending on what the routing is on the HP.

You could also use a combination of the above ie VRF-Lite between the Cisco switches and then PBR for the last hop to the HP device.

I should say i don't have a huge amount of experience with VRF-Lite but that should not necessarily stop you using it if it is what you need. There are lots of other people on here so i'm sure there will be other people who can help if i can't.

It still depends on how much separation is required. VRF-Lite is definitely seen as a way to separate traffic running across a shared infrastructure, PBR is not really seen in the same way.  So it may well be worth going back to find out exactly what "segregating" user traffic means.

I don't want to confuse the issue but it's still not entirely clear what the actual requirement is.

Jon

Thanks Jon

Sounds good, its not been made particularly clear to me either!!

Basically the users are on our core network and they need to be managed by another external company that we have a permanent vpn to via our firewalls, they will take ownership of the 3550 and a ups.

Ive tried testing PBR but the 4507 seems to ignore them due to IP CEF being turned on and also OSPF normal forwarding. Basically I put a static route into the HP in a test and the users in area 7 were able to get out to the interface on the firewall. So this seems to work but does not seperate the traffic in anyway.

in terms of the areas looking at the config they are using a default network statement on all core switches thus 0.0.0.0 255.255.255.255 area 0 which puts all interfaces into area 0 but on the 3550 does not have this statement. Area 7 is a stub but the interface connecting from 3550 to the 4507 is not in area 0.

Can you use vrf lite even if we arent using MPLS in our network?

I appreciate the help on this i suppose I need to get further clarification from my boss.

Thanks again

Steve

Steve

Ive tried testing PBR but the 4507 seems to ignore them due to IP CEF being turned on and also OSPF normal forwarding. Basically I put a static route into the HP in a test and the users in area 7 were able to get out to the interface on the firewall. So this seems to work but does not seperate the traffic in anyway.

We can look at that if needed. But as you say a static route does not really separate the traffic. But as i was explaining PBR doesn't really separate traffic, it just "forces" traffic to take a certain path whatever the routing table says. So with PBR you are overriding the routing table.

Whether or not that could be seen as separation i don't really know. Depends on your point of view i suppose.

VRF-Lite does provide logical separation on a physical device. But as i say it is more complex and the equivalent functionality may not be available on the HP.

Couple of further questions if you don't mind to try and narrow it down -

1) the 4500 switch. Is this used purely to connect area 7 to area 0 or are there other areas, or internal users using this switch. I ask because if it is just for area 7 connectivity the uplink to the 6500 would be being used purely for area 7 users.

If it is used by other users do you know what the uplink to the 6500 is ie. a L2 access port, a L2 trunk port or a L3 routed port.

These questions are important if you decide to go with VRF-Lite.

2) I assume the 6500 i used by a lot of other users as well as area 7 users. What is the uplink connected to the HP configured as ie. same questions as in 1).

In answer to your question about using VRF-LIte without MPLS yes you can. It is a kind of limited functionality of a full MPLS VPN solution.

I do think it might be worth asking for a bit more clarification. And depending on the answers to 1) and 2) you may not want to go down the VRF-Lite route because it would mean reconfiguring uplinks on devices within area 0 that are used by all users.

So your boss may be all for the VRF-Lite solution until he realises that means reconfiguring the 6500 in which case he might decide PBR is good enough. So yes, it may be worth talking again to your boss but can you answer the questions above first which would give us an idea of which solution is more pratical.

It may well come down to a tradeoff between practicality vs security/separation of traffic.

Jon

Great thanks Jon.

1) yes it is used for many other areas. 4500 to 6500 will be layer 3 routed. (OSPF)

2) Layer 3 routed. (OSPF)

I'd imagine VRF will be out, theres no way we could cause any downtime to the users off the 6500 as this is one of the major core devices (although there is a back up 6513)

One of my collegues thinks there is not even a need to any PBR etc as we can just use static routes but to me that doesnt resolve any issues related to routing them away from our network.

Thanks for all your advice

Steve

Steve

Sounds like VRF-Lite is out then because you would need a trunk link so you can allocate the vlan interfaces to the correct VRFs.

Using PBR over static routes is still preferable in my opinion because with PBR, as i say, you are overriding the routing table. Using static routing could be used but it could also conflict with other routes and any changes in the routing table could in effect allow area 7 users to access things thery are not meant to.

So yes, i would go with PBR to define the path across the core network from area 7 to the firewall. Don't forget, like i say, you need to also configure PBR for the return path as well.

One last point. L3 switches are high performance because they forward most packets in hardware. They can also do PBR in hardware but it is always worth reading the relevant configuration guide because there are certain things you should not include in your configuration, otherwise it can mean all PBR packets being sent to the main CPU of the switch ie. software switched and this can seriously degrade the performance of your switch.

If you are still having problems with PBR on the 4500 then please feel free to come back for help.

Jon

Hi John, yes it may have been that there was no pbr configured on the return journey, presumably all PBR needs to be on the Cisco 4507 attached to the users 3550 switch? Also, is it not true that if CEF is enabled that the switch will ignore all PBR maps? Or will putting a map on the return journey sort that out?

Thanks

Steve

Steve

It needs to be on every device where you want the traffic to take a different path than the routing table.

If the path taken would be the same using the routing table there is no point in using PBR.

And you need to configure it both ways.

Jon

This is what I cant get my head around, I think I do need to route the traffic towards the vpn on the firewall but when i have tested this just using static routes that are redistributed then I can send pings in the direction of the firewall interface no problem, so why not just use the static routes?

I think I am complicating matters for myself and its frustrating!!

Thanks Jon

Jon Marshall
Hall of Fame
Hall of Fame

Steve

This is why i originally asked what you meant by segregating traffic. If the PBR configuration is sending the traffic the same way that the routing table would then there is no need for PBR.

But you are talking about adding static routes to make this work. If you are having to add static routes it sounds like the routing was not there in the first place for the end to end path. Perhaps you could clarify on the above ie. is there no end to end path without adding routes. How do other users (ie non area 7) get to the firewall. Are there specific routes for their destination subnets in the routing tables ?

You can just use statics and redistribute into OSPF but this in no way provides any segregation because the routing tables contain those routes and are available to all devices (unless you filter them between areas). Even with PBR, as i say, that is not really segregation.

With PBR you send the traffic a different way then the IP routing table would send it. But any next hop you specifiy in the PBR config must still be reachable from the L3 device. It's just that the next hop is not the same one the IP routing table would have picked.

If you have a vendor coming in to manage the 3550 in the area 7 then ideally you want to make sure they cannot go anywhere else. If you simply use statics then on the 3550 they will, in theory be able to access the rest of your network. With PBR you could at least, on the 4500, make sure they are directed the way you want them to be. Without it, they can simply go anywhere within your network.

You could perhaps use acls on the 4500 interface connecting to the 3550 so you restrict their access ie. they can only connect back to their own network. So that may be another option instead of using PBR or with PBR.

So there are a number of options, although i wouldn't call any of them segregation really but it's difficult to be more precise at the moment with the information provided so far.

Jon

Review Cisco Networking for a $25 gift card