×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Hi all, need advice on OSPF and private vlans

Answered Question
Jan 12th, 2014
User Badges:

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

Correct Answer by Jon Marshall about 3 years 7 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jon Marshall Sun, 01/12/2014 - 14:50
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Ableton34 Sun, 01/12/2014 - 15:03
User Badges:

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

philip daly Sun, 01/12/2014 - 15:28
User Badges:

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?

Jon Marshall Mon, 01/13/2014 - 04:38
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Ableton34 Mon, 01/13/2014 - 05:53
User Badges:

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

Attachment: 
Jon Marshall Mon, 01/13/2014 - 06:27
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Ableton34 Mon, 01/13/2014 - 06:35
User Badges:

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

Jon Marshall Mon, 01/13/2014 - 06:54
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Ableton34 Mon, 01/13/2014 - 07:06
User Badges:

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

Jon Marshall Mon, 01/13/2014 - 07:32
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Ableton34 Mon, 01/13/2014 - 08:01
User Badges:

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

Jon Marshall Mon, 01/13/2014 - 08:04
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Ableton34 Mon, 01/13/2014 - 08:41
User Badges:

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 Mon, 01/13/2014 - 09:20
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Ableton34 Mon, 01/13/2014 - 14:19
User Badges:

Hi again.


So I have been playing with PBR and acl's, so far i have managed to create acl so that only the new subnet from the 3550 is allowed into the connected interface which is fine.


I have also created a pbr map to say that any matching the addressing of that subnet will have a next hop address of the adjacent 6513. However, i have created a new subnet on another interface on the 4507 and i can still reach it.


What I want to do is route all traffic from the subnet off the 3550 and direct it onto the 6513 without having access to any other network on any other interface on the 4507.


Debugging the pbr it is working ok but as I say I can still reach another network off the 4507, any ideas how I can force all traffic from the 3550 to only be allowed to the 6513?


Many thanks


Steve

Jon Marshall Mon, 01/13/2014 - 14:26
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Steve


So you have done all this on the 4500 ?


Can you post the config of what you have done and explain exactly where the config is applied it on which interfaces and also in terms of the acl which direction it is applied.


Also can you specify the source IP subnet and the destination IP subnet.


Jon

Ableton34 Mon, 01/13/2014 - 14:29
User Badges:

Hi Jon,


yes just on the 4507 at the moment, on the interface connected to the 3550


interface FastEthernet0/0

ip address 192.168.200.53 255.255.255.252

ip access-group 101 in

ip policy route-map DAT-Traffic

duplex auto

speed auto



access-list 101 permit ospf any any

access-list 101 permit ip 10.2.1.0 0.0.0.255 any

access-list 101 permit ip host 192.168.200.54 any

!

route-map DAT-Traffic permit 10

match ip address 101

set ip next-hop 192.168.42.5

Jon Marshall Mon, 01/13/2014 - 14:43
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

So the source IPs are 10.2.1.x ?


And 192.168.42.5 is the next hop on the 6500 ?


Your acl is not really doing anything in terms of security as you are allowing 10.2.x.x to go anywhere. It is needed for the PBR though (if we actually need PBR - see below). We can also tighten up the acl so you would have a different acl for security and one for PBR but i need answers to the following -


1) The new subnet that you created on the 4500 that the 10.2.1.x clients can get to. Does the 6500 know about this subnet ? 


2) What is the destination subnet(s) that you want 10.2.1.x to be able to get to ie. presumably the subnet(s) at the other end of the VPN tunnel ?


3) These remote subnets. Is there a route to them in your core routing tables ?


If yes PBR may not be much use. If no then it might well be.


So can you provide answers to all the questions and we can go from there.


Jon

Ableton34 Mon, 01/13/2014 - 14:48
User Badges:

Hi Jon


1) yes the 6500 will know via ospf


2) at present i do not have that info, i have just made one up for testing on my rig. There is currently a static route set up as discussed earlier. 172.17.1.0 255.255.255.0 i think


3) Again yes as static route is being redistributed.


I guess this goes back to what we were talking about before, it is true we will not want the users on 3550 access to the core network and just to be routed direct to the firewall (vpn)


I suppose i just need to know how to get them over to the vpn without access to anything else without having to enter a deny access list on every interface on the 4507, which there are a lot going to different areas and with still using the core network to route them (ospf)


Cheers jon

Jon Marshall Mon, 01/13/2014 - 15:16
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Steve


1) I suspect PBR is sending the packets to the 6500 but because the 6500 has a route to that subnet it just routes it back. Obviously when you setup up PBR all the way this won't happen (see below though)


2)& 3). Okay but the question is will the actual networks be advertised into your network ie. apart from the area 7 users does anyone else need to get to these networks ?


If not then you need PBR. If those networks are to be added to your core then PBR is limited.


So if you are going to advertise the remote subnets into your core area then you only need an acl on the 4500 interface and that is pretty much it for outbound traffic. You would then control inbound traffic on the VPNN firewall ie. the only destination allowed coming in over the VPN is 10.2.1.x and presumably the 3550 address 192.168.200.254.  So rewriting the acls -


acl for PBR -


access-list   permit ip 10.2.1.0 0.0.0.255 any

access-list permit ip host 192.168.200.54 any


acl for the interface -


access-list permit ospf any any

access-list permit ip 10.2.1.0 0.0.0.255

access-list permit ip host 192.168.200.54


then depending on which numbers you used either reapply the acl to the interface or update your PBR config.


So the only remaiing question really is whether you need to add routes for the remote subnet(s) into your core area or whether to use PBR. I don't know what you are going to do about that. If you are then you do not need PBR.


I should point out that an acl on an interface is not really that secure and this is by no means segregation so you are still placing trust to an extent in the users and the remote support staff. You could, if this became an issue perhaps install a firewall between the users and the 4500 which would provide much more security but again that may not be an issue.


Jon

Ableton34 Tue, 01/14/2014 - 06:36
User Badges:

Hi Jon


i've had a chat to my boss and we definately need to just direct the traffic from the 3550 to the external subnet via the vpn.


Therefore I need to create an extended acl with policy routing so that it drops any packets that are not destined for the network 172.17.1.0 coming from 10.2.1.0. He thinks we may be able to do this with a combination of acl, policy routing and using the set default interface null0 to send any packets not destined to 172.17.1.0 get dropped. What do you think? is this possible? I dont really understand the null interface part.


Thanks


Steve

Jon Marshall Tue, 01/14/2014 - 07:17
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Steve


Don't know whether you got the last reply so retyping.


A null0 interface is used like this -


ip route 172.16.10.0 255.255.255.0 null0


a router receiving packets destined for this network would simply drop that packets. It would make sense on the 3550 although there are other ways to do it as well. Bear in mind with PBR, if the next hop is not available then the normal routing table is used. So a soluton may be to not run OSPF between the 3550 and the 4500 so the 3550 does not have routes to any part of your network.  Then you just add static routes for the remote network(s) that they are allowed access to.


I would still recommend using an acl on the 4500 interface that connects to the 3550 though because the 3550 is not going to be under your control so it is an additional layer of security, just in case there is a misconfiguration, for example on the 4500 and the 3550 ends up getting routes again.


PBR could then be used on the other devices to send the traffic to the firewall. You still haven't said whether the remote networks will actually be in your core routing tables. If they are then again PBR is of limited use. You could still use PBR to match the source traffic and send it to null0 if the destination is not the remote subnet but -


1) there are restrictions on which commands can be used on certain L3 switches and also whether the use of the command means the packets are software switched which can have a performance impact on the switch


2) if you only allow the remote subnet routes on the 3550 and have an acl on the 4500 to 3550 interface it is very unlikely you would actually see any traffic for other networks on your 4500/6500 etc.


That said if 2) is highly unlikely then you are probably not going to be face the issue in 1). Up to you really as to how many devices you want to configure and how much complexity you want.


Don't forget that you also need to account for the return path as connections can actually be initiated from the other end as well.


Jon

Ableton34 Wed, 01/15/2014 - 03:08
User Badges:

Hi again Jon.


Thanks for all your help on this, my task has become a bit more complicated. i have had success setting up policy routing from the 3550 over to the 6513. However i now have another issue. The 6513 is connected to the HP with layer 2 switching using port channels. So all traffic is going via vlans.

I presume I would just have to create a vlan interface to route the traffic via the port channel and onto the HP? I was doing really well until i came across this!! Nightmare! There are free gig interfaces on the 6513 but presume it would be easier to do a vlan?


Any advice as always greatly appreciated!


Steve

Jon Marshall Wed, 01/15/2014 - 03:23
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Steve


I'm not sure why you have to create a new L3 vlan interrace if the 6500 is already connected to the HP. Just use the one that is already there.


I'm assuming this is for the return traffic from the VPN box ie. you don't apply PBR to outgoing interfaces you apply it to incoming interfaces so -


1) from the 3550 to the HP switch you would use the interface on the 6500 that connects to the 4500


2) from the HP switch to the 3550 you would use the L3 vlan interface that is used to connect to the HP switch


On the 6500 you need to be careful with your PBR acls because the interfaces you apply it to may well have traffic for other users so make sure you only specify the source and destination subnets you actually want to policy route.


If i have misunderstood themn please clarify.


Jon

Ableton34 Wed, 01/15/2014 - 04:32
User Badges:

Hi again


I'll try and explain a bit better.


The physical interface between the 6513 and the HP is a trunked switchport using port channel. Then on the HP there is a physical trunked switchport to the firewall interface.


There is a vlan 363 which is labelled firewall inside.

Do i need to create a vlan interface on the 6513 then trunk that to the HP, trunk that vlan from HP to the firewall?


There is no policy routing that i can see at all on the HP, only ospf and static routes then the gig trunk port to the firewall.


Any ideas? I cannot reference a vlan as the next hop IP addres in my policy routing on the 4507 or the 6500 can I?


ive also noticed this on the 6500


interface Vlan363

description Vlan to N3

ip address 192.168.36.125 255.255.255.224


N3 being the core network that the vpn will go over


then on the HP end:


interface Vlan-interface363

ip address 192.168.36.126 255.255.255.224


Presumably then on the 4507 the next hop would be the vlan interface 363 on the hp?


Thanks


S

Jon Marshall Wed, 01/15/2014 - 04:50
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Steve


I have been asuming that the HP switch is L3 but it sounds from your description as though it might only be a L2 switch so the next hop from the 6513 would be the firewall.  If the 6500 has a trunk link and multiple L3 vlan interfaces for that link it sounds as though the 6500 is routing for vlans on the HP switch.


You need to confirm this one way or the other before we can proceed.


I don't think you will need to create a new L3 vlan interface, you should be able to use vlan 363 (if i am understanding correctly) but that will only be for return traffic from the firewall.


To clarify, for PBR you apply the route map to the incoming interface. For traffic from the 3550 to the firewall the L3 vlan interface connecting the 6500 to the firewall (via the HP switch) will never be the incoming interface. For return traffic from the firewall though it will be the incoming interface so you will need to apply a route map but i just want you to be clear as to what we are doing.


You can apply a route map to a L3 vlan interface just as you would a physical L3 interface.


So can you confirm whether or not the HP switch is a acting as a L2 or L3 switch ?


Jon

Ableton34 Wed, 01/15/2014 - 04:55
User Badges:

Hi, ive just updated the above with:


ive also noticed this on the 6500


interface Vlan363

description Vlan to N3

ip address 192.168.36.125 255.255.255.224


N3 being the core network that the vpn will go over


then on the HP end:


interface Vlan-interface363

ip address 192.168.36.126 255.255.255.224


Presumably then on the 4507 the next hop would be the vlan interface 363 on the hp?



As regards to L2 or 3 the HP has both switched interfaces and is using ospf


I am ok up to the point on the 6500 where i have policy routed to but then Im getting stuck


Cheers


S


thanks


S

Jon Marshall Wed, 01/15/2014 - 05:12
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Steve


Presumably then on the 4507 the next hop would be the vlan interface 363 on the hp?

So if i understand correctly the 192.168.36.96/27 network is used to connect the 6500 to the HP switch ?

If so you can do this, it is called a recursive next hop where the next hop is not directly connected ie. the 4500 has to send the traffic to the 6500 first and then the 6500 send it to the HP switch.  That will work as long as the 4500 has a route for the vlan 363 network. Then the 6500 would not need PBR config for the traffic from the 3550 to the firewall. To set a recursive next hop in the PBR route map you use -


set ip next-hop recursive


however you need to make sure it is supported by your 4500 and that it does not mean packets will be software switched so what IOS is your 4500 running ?


In addition it is important to note that you do lose some control as when it gets to the 6500 there is no PBR to explcitly tell it which next hop to use, it simply uses the routing table. This shouldn't matter as presumably the same next hop would be used whether it is from the routing table or from a PBR route map but it is something to be aware of.


That said it depends on how consistent you want your setup to be ie. traffic from the firewall to the 3550 cannot use PBR on the HP switch (or at least we don't know that it will, you could always look at the documentation). So the first place you can do PBR for the return traffic is the 6500 and assuming vlan 363 is used to connect the 6500 to the HP switch that would be the place to do it . So you may want to use PBR both ways on the 6500.


It really is up to you how you want to do this. As i have said quite a few times if the routing table would send the traffic the same way that your PBR is then you don't get a huge benefit from using PBR. More important are the acls on the interfaces and the routing table on the 3550.


Retrun traffic is harder because there is no device dedicated for area 7 users so you probably do need PBR at least to "force" traffic a certain way.


Again, that said, if the 3550 has a full routing table then PBR is of some use.


Jon

Ableton34 Wed, 01/15/2014 - 06:05
User Badges:

Hi Jon,


Ive just checked and there is a route on the 4500 to the network 192.168.36.96 which the interface of the firewall is on, here is my config so far on the 4500, presumably then I would not need any pbr on the 6500?



Interface g3/12

ip access-group 101 in

ip policy route-map DAT-Traffic

access-list 101 permit ip 192.168.208.128 0.0.0.63 any

access-list 101 permit ip 172.16.68.64 0.0.0.63 any

access-list 101 permit ip host 192.168.200.54 any

access-list 102 permit ip host 192.168.200.54 ………(address of external Subnet via vpn and wild card mask)

access-list 102 permit ip 192.168.208.128 0.0.0.63 ………(address of external subnet and wild card mask) any

route-map DAT-Traffic-out permit 10

match ip address 102

set ip next hop 192.168.36.97

route-map DAT-Traffic permit 20

set interface null0

What do you think?

Thanks

S

Correct Answer
Jon Marshall Wed, 01/15/2014 - 06:23
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Ableton34 Wed, 01/15/2014 - 08:27
User Badges:

Jon,


I must say you've been very helpful. I am quite new to networking at an engineering level so am learning all the time. Apologies if I have not read your replies properly.


All it took was your suggestion of using the recursive next hop command!!


It will not be tested in a live environment yet but in my virtual rig it works perfectly.


However i have just checked to see if the 4500 can do the recursive command it it is not available! Damn!


version is: "bootflash:cat4500-entservicesk9-mz.122-52.SG.bin"


Thanks so much


All the best


Steve

Jon Marshall Wed, 01/15/2014 - 08:57
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Steve


No need to apologise, i just didn't want you to apply the configuration and take down part of the network.


If the recursive next hop is not supported then you need to set the next hop to be the 6500 and do PBR there as well. Again you need to apply the PBR to the interface connecting back to the 4500. I don't think you need acls on the interface as you are controlling that on the 4500 interface and whereas the 4500 interface only connects to the 3550 i suspect the 6500 interface is for a lot of other users as well.


Couple of points -


1) i don't want to sound like a stuck record but you may or may not need PBR on the 6500. If the 6500 has a route to the remote subnets pointing the same next hop as the PBR next hop then it is of limited use. The control of the traffic from the 3550 has already been limited by the use of the interface acl and the PBR there. And also only having static routes on the 3550, i don't know whether you did that or not.


2) this is very important. I am assuming, and i think you confirmed, that the 4500 to 6500 link is used by more than just the area 7 users on the 3550. If so and you decide to do PBR on the 6500 for traffic to the firewall do not use the route map example you posted where in the second permit statement you sent traffic to null0.


You should only use the null0 statement in your PBR on the 4500 interface connecting to the 3550. If you used it on the 6500 you would effectively send all traffic that didn't come from users on the 3550 to null0 and i am pretty sure you don't want to do that


Anything else you need help with just let me know.


Jon

Actions

This Discussion