Routing

last person joined: 4 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  OSPF design

    Posted 09-30-2009 02:14

    Not entirely juniper related but here goes anyway.

     

    I have a cluster of two SSG550's. south side is a juniper EX4200 cluster configured with 9 VLANS each VRF'd to provide L3 and a seperate routing table. North side is the core.

     

    Currently, the fwl cluster is in area 0, together with the core. I am thinking of splitting the area at the firewall and place the south side VRF's in to their own area, but do i create an area for each vrf or place them all in one. Can anyone expalain the dis/adv's of both options, and obviously if they are reasonable suggestions. I beleive that there will be processing overhead etc.

     

    The reason for this is to autosummarise the routes. I noticed that when enabling ospf on one of the firewalled vrfs the table is not summarised and probably room for some optimisation. All VRF's need to participate in ospf, but not necessarily have hundreds of routes in their table as they will mostly use their default gateway. The VRF;s generaly provide a firewalled connection to a remote subnet, data service, nothing special.

     

    HD

     



  • 2.  RE: OSPF design

    Posted 09-30-2009 14:55

    Contrary to popular belief, OSPF ABR does not autosummarize the LSA1/LSA2 routes.It sumply takes any LSA1 or LSA2 route from any connected area, creates exactly the same LSA3 route and advertises it into all other connected areas. "Same" means identical prefix and mask length. You have to manually define less specific/shorter mask prefixes to be advertised as LSA3 if you wish to summarize.

    And LSA5 routes can be summarized only on ASBR.

    Having said that, putting all VRFs into same OSPF area is not a good idea if there are backdoor links (not across the core). If communication between VRFs is possible only via core, then have a look into OSPF "domain-id" feature.  



  • 3.  RE: OSPF design

    Posted 10-01-2009 02:42

    Thanks.

     

    The VRFs will be fairly small and only contain 1 network each which is why i was thinking it excessive for a new OSPF area for each VRF.  Putting them in the same one i was hoping would  reduce the ip networks advertised in to the area, and also advertised in to the core area 0.

     

    Some of the networks themselves i guess are stub networks as they will not have any other connectivity other than via the core area. There are several that provide connectivity to external parties, and one of these implementing RIP.Connectivity will only be possible between the VRF's via the SSG cluster which will be the ABR between core and others. In fact, most of the networks will never need to comunicate to anywhere other than via the core. Several will need to communicate, but again, via the SSG for security reasons. Im hoping that inter network traffic will not touch the core hardware itself unles it originates from the core and its other networks.

     

    If you recomend multiple areas I will give this a go.also looking in to domain ID

     

     



  • 4.  RE: OSPF design

    Posted 10-01-2009 03:10

    Well, James Bond used to say "never say never" 🙂

    If majority of your VRF networks are stub (no backdoor links) _AND_ not multihomed therefore do not need load-balance outgoing traffic,

    then they are perfect candidates to reside in a single "totally stub" OSPF area. I would avoid "stub" OSPF areas for sake of future expansibility/adaptability, e.g. you might wish to connect an external customer to such network-> OSPF area type needs to be changed. What would I do is to make each stub VRF network to reside in same OSPF area and advertise conditional 0/0 via OSPF from core towards each stub VRF network. Conditional being dependent on route towards your Internet peering router or maybe your IPv4 route-reflector being present in your IGP. Have a look into "condition" knob in JUNOS routing policy language.

     

     



  • 5.  RE: OSPF design

    Posted 10-01-2009 03:59

    After your advice, heres the plan of attack.

     

    On the SSG cluster :

    create one totally stubby area for all networks that have only one entry/exit point to the network

    create one area for those interfaces to the VRF's with links in to the core and out to another network, private or not

    leave the interface conections to the core in area 0

     

    sound good?

     

    out of curiousity, will the SSG autosumarise or do I need to implement a configuration to do this. What will result of the extra area on the platform?

    Message Edited by harrydanger on 10-01-2009 04:00 AM


  • 6.  RE: OSPF design
    Best Answer

    Posted 10-01-2009 14:24

    If I visualise your network correctly, your plan is:

    - put "stub" VRF networks connected only to the core into totally stub OSPF areas with one area number - OK with me

    - put multihomed and/or backdoor-ed VRF networks into regular OSPF areas with unique area numbers - OK with me

    - each OSPF area extends from core across SSG to VRF networks over separate logical link (802.1Q VLAN) - not sure if I get it right? In this case SSG won't be an ABR but your next question about summarization implies that.

    Or is your plan to have a single SSG-core logical link in OSPF area 0? This would mean all traffic between VRF networks being routed by SSG as opposed to being routed by PE. SSG would be able to summarize in this case (but not _AUTO_summarize):

     

    By default, an ABR does not aggregate routes sent from one area to another area.
    Configuring an area range allows a group of subnets in an area to be consolidated
    into a single network address to be advertised in a single summary link advertisement
    to other areas. When you configure an area range, you specify whether to advertise
    or withhold the defined area range in advertisements.

    http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ce_Routing.pdf , page 59



  • 7.  RE: OSPF design

    Posted 10-02-2009 01:10

    To confirm

     

    on the SSG cluster create multiple areas. Therefore the SSG will become th ABR between all areas and the core

    0.0.0.0 - links connectect to the core

    0.0.0.v - links connected to multiple totally stubby VRF's on a juniper chassis (no back dorr)

    0.0.0.x - connected to one not so stubby area (back doored) on a juniper chassi VRFx

    0.0.0.y - connected to one not so stubby area (back doored) on a juniper chassi VRFy

    0.0.0.z - connected to one not so stubby area (back doored) on a juniper chassi VRFz

     

    Thanks for your help, much appreciated

    Message Edited by harrydanger on 10-02-2009 01:25 AM