1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Static routes and/or policy routing?

Discussion in 'Internet, Connectivity and Communications' started by millsie, Jan 12, 2014.

  1. millsie

    millsie Byte Poster

    169
    4
    34
    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
     
    Certifications: N+, CCNA, MCDST
    WIP: CCNP route 642-902
  2. Simonvm

    Simonvm Kilobyte Poster

    472
    13
    41
    Can you make a quick network diagram? :)
     
    Certifications: MCITP: EST, MCDST, MCTS, A+, N+, CCNP, CCNA Wireless
    danielno8 likes this.
  3. danielno8

    danielno8 Gigabyte Poster

    1,305
    48
    92
    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 :)
     
    Certifications: CCENT, CCNA
    WIP: CCNP
  4. millsie

    millsie Byte Poster

    169
    4
    34
    Network1.jpg

    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
     
    Certifications: N+, CCNA, MCDST
    WIP: CCNP route 642-902
  5. danielno8

    danielno8 Gigabyte Poster

    1,305
    48
    92
    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?
     
    Certifications: CCENT, CCNA
    WIP: CCNP
  6. millsie

    millsie Byte Poster

    169
    4
    34
    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
     
    Certifications: N+, CCNA, MCDST
    WIP: CCNP route 642-902
  7. danielno8

    danielno8 Gigabyte Poster

    1,305
    48
    92
    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.
     
    Certifications: CCENT, CCNA
    WIP: CCNP
  8. millsie

    millsie Byte Poster

    169
    4
    34
    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
     
    Certifications: N+, CCNA, MCDST
    WIP: CCNP route 642-902
  9. danielno8

    danielno8 Gigabyte Poster

    1,305
    48
    92
    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.
     
    Last edited: Jan 15, 2014
    Certifications: CCENT, CCNA
    WIP: CCNP
  10. millsie

    millsie Byte Poster

    169
    4
    34
    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
     
    Certifications: N+, CCNA, MCDST
    WIP: CCNP route 642-902
  11. danielno8

    danielno8 Gigabyte Poster

    1,305
    48
    92
    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,
     
    Certifications: CCENT, CCNA
    WIP: CCNP

Share This Page

Loading...