Static routes and/or policy routing?

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Need some advice on a routing issue.

OSPF area 0, and one other area, area 7.

Need to get area 7 traffic routed through 3 core switches which are all in area 0 out to a firewall (which is not included in the ospf domain) and onto a vpn out to another private network. The traffic needs to be segregated from all the other normal traffic in this core network.

Now I could put a static route on the core device that attaches to the firewall so that ospf knows the route out over the vpn and redistribute that into ospf but not sure if that will segregate the traffic, I was wondering if I might also need to add policy routing to route all traffic from area 7 towards the firewall? Presumably that would be added to the core device that area 7 attaches to?

Any ideas guys?

Cheers, Millsie

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Can you make a quick network diagram?

 

Yep a diagram will help massively. By the sounds of things you may want to create a VRF on the core switches with an interface facing the area 7 ABR and an interface facing the firewall. Diagram will help get the right solution

 

Hopefully that worked! Need to get users in area 7 seperated from the rest of the core network and out to the vpn between the firewalls.

Thanks guys

Millsie

 

I presume this network is not located in the same office, so cabling direct to firewall isn't an option.

Without knowing much else about the requirements other than segregating area 7 and area 0, or existing set up, I would suggest using a vrf to accomplish the goal. Although a pretty straightforward configuration, there are a couple ways to do it, and it would depend on how those core switches are connected to each other mostly. VRF will give you a separate routing table specifically for Area 7 traffic (and any other networks you decide to add to that VRF). To do this you need an interface to assign into the VRF across the core. This could be accomplished by sub-interfaces or additionally physical patching between switches.



Another method, which would remove the requirement for reconfiguration of the core network devices, would be to stick a Cisco router between the 3550 and the first core switch, and a Cisco router at the other end between the firewall and the HP core switch, and build a GRE tunnel between both of those across the core network.

Either of those sound like possibilities?

EDIT: if you can upload the visio file i can update showing what i mean if that helps?

 

Cheers Daniel

I had thought about vrf light but it is not an option as it would mean reconfiguring core devices which we cannot do.

Also we wanted to avoid any spend where possible so to less complicate the network and to save spend the routers are out.

I think I need to try route maps again and pbr but have a map on each of the core devices in each direction, I could not get them to work before as when debugging the pbr it was allowing normal forwarding as i had a static route on the HP core connected to the firewall, the HP was redistributing the static route therefore the 4507 connected to the users switch was using ospf to route the traffic normally.

Presumably I could just create vlan interfaces that the users use and place these on all the core devices and map policy routing to the vlans?

It seems like the solution should be easy but feels like I am complicating matters?!

Cheers for your advice.

Millsie

 

hmmm, that is a shame, as really I am not sure what type of segregation you are actually achieving. With PBR, I guess you are attempting to force ALL area 7 traffic (for example, 10.10.10.0/24), no matter the destination, to hop 4507 --> 6513 --> HP 7500? This would then need to be done in reverse for all the external networks IP addresses for the return traffic. You mention not being able to configure the core devices, but any PBR solution is going to require reconfiguration on the core devices?

The solution could be easy, but that would involve some spend (new routers) or vrf-lite I think. I would say PBR looks the most complicated, with the most lines of config, it is also very "static", therefore changes at the firewall side or client side would lead to reconfiguration across all the core devices.

Whip out GNS3, you should be able to play around with this design and test out your PBR configuration though.

 

Cheers Daniel

You might be able to help me with this, I need to create extended acl with policy routing that allows the subnet 10.2.1.0 255.255.255.0 to only access the network 172.17.1.0 255.255.255.0 without being able to send traffic out any other interface on the Cisco 4507. What do you think?

Thanks

millsie

 

I take it an access-list on the inbound Cisco 4507 interface isn't enough to ensure the Area 7 can't access anything other than the 172.17.1.0/24 network?


Cisco 4507

access-list 101 permit ip 10.2.1.0 0.0.0.255 172.17.1.0 0.0.0.255
access-list 102 permit ip 10.2.1.0 0.0.0.255 any

route-map Area7 permit 10
match ip address 101
set ip next-hop X.X.X.X

route-map Area7 permit 20
match ip address 102
set interface null0

interface X/X (interface connected to the 3550)
ip policy route-map Area7

This should be a pretty close starting point....would be worthwhile testing this in GNS 3 or something.

EDIT: This will of course need forced along the path if there is a potential for the core device to allow it to take a different path than desired to the firewall.

 

cheers Daniel, it looks like a simple extended access list has done the trick, however i now cannot get traffic from the external network to go back into the 3550 which is adjacent to the 4507 where i applied the acl to direct traffic from the 3550. do i need to place one on the incoming interface on the 3550?

cheers mate

 

Can you confirm what you have applied so far? Is it just an ACL allowing all traffic from 10.1.2.0/24 to 172.17.1.0/24, and denying everything else?

If so, there should be no reason the traffic from the external network (172.17.1.0/24?) cannot reach 10.1.2.0/24 after you have applied that ACL. Please confirm testing scenarios you have done as well. May be/it is likely the firewall rules are one way.....i.e 10.1.2.0/24 has to initiate traffic to 172.16.1.0/24 (or vice versa) for it to be allowed. Put as much info on what has been done as you can.

Cheers,