Julian,
thanks for the command - what I was really looking for was the cisco
equivalent :-)
if you had read the rest of the thread (20 or so messages) you would see
that this *is* a cisco-related query. I am looking for a way to do
something on Ciscos, and was bemoaning the fact that I could do what I
wanted easily under JunOS - Peter asked how I would do it with that OS, so I
posted the config excerpt.
thanks anyway
Andy
Julian Eccli wrote on July 19, 2001 at 7:54 AM:
> Andy,
>
> Try the following for the 7-to-5 aggregate translation which can also be
> converted to a filter by setting the "restrict" knob at the end:
>
> [edit protocols ospf area 0.0.0.10]
> nssa {
> area-range 10.0.0.0/8;
> }
> }
>
>
http://www.juniper.net/techpubs/software/junos42/swconfig-routing42/html/osp
f-co
> nfig6.html
>
> I am curious, why don't people take Juniper questions to the Juniper
> Groupstudy
> news group? I know for a fact that a number of folks within Juniper lurk
on
> that newsgroup but not on the Cisco one.
>
>
> -Julian
>
>
> ""Andy Harding"" wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> : ** excuse the change of email and name - just changed provider
> :
> : on a Juniper:
> :
> : [edit protocols ospf]
> : root@router# show
> : export type-5-suppress;
> :
> :
> :
> : area 0.0.0.10 {
> : area-range 172.16.0.0/16;
> :
> : }
> :
> : [edit policy-options]
> : root@router# show
> : policy-statement type-5-suppress {
> : term area-0-suppress {
> : from {
> : protocol ospf;
> : area 0.0.0.10;
> : external;
> : }
> : to {
> : protocol ospf;
> : area 0.0.0.0;
> : }
> : then reject;
> : }
> : then accept;
> : }
> :
> : I would groom out the externals from being advertised across the area
> : boundary as per above, then permit anything else to be processed as
normal
> : with an area-range statement to summarize.
> :
> : I'm interested in how one might summarize at the type-7 to type-5
> : translation at an NSSA border. Do you have the command(s) to hand?
> :
> : thanks
> :
> : Andy
> :
> : Peter Van Oene wrote on July 19, 2001 at 12:56 AM:
> :
> :
> : Ok, good scenario.
> :
> : Assuming your network has grown to a point where type 5's are stressing
the
> : AS, some scaling effort must take place. There are a number of poorly
> : scaling cludges to this type of scenario outside of OSPF, but I've seen
> NSSA
> : areas used here with some success. The net result is that your
individual
> : areas have no awareness of the more specifics in other areas which isn't
> bad
> : assuming your aggregation strategy is clean as they can simply follow
the
> : aggregates put out by the ASBRs. Within the area, the type 7's provide
> : enough info for intra area routers to make informed decisions re paths
out
> : toward the customer networks. Your backbone will naturally see all
> external
> : info which shouldn't be an issue as a mid size ISP should have some good
> : routers therein.
> :
> : The key point is again that type 5's are unmodified at area borders.
They
> : in fact flood untouched throughout the AS. Hence, unlike normal
> summarizes,
> : 5's aren't repackaged at each ABR before they hit other areas. For that
> : reason, you cannot control their flooding scope once they hit the domain
> : without using area modifications like stubinness. Interestingly, due
to
> : type 7's needing to be converted to 5's by ABR's, they are repackaged
> before
> : entering the backbone and thus can be summarized via area-range like
> : commands at ABR's. Another reason why this is a viable solution to your
> : situation.
> :
> : I'm also curious how you can do this with a Juniper? Can you provide a
> : quick outline?
> :
> : Thanks
> :
> : Peter
> :
> :
> : *********** REPLY SEPARATOR ***********
> :
> : On 7/18/2001 at 4:54 PM [EMAIL PROTECTED] wrote:
> :
> : >okay, let me give you a scenario:
> : >
> : >say you have a mid-sized ISP network - a size such that it's not really
> : >worth going with confederations, etc.
> : >
> : >say that you have a couple of PoPs and a couple of colo/hosting
centres.
> : >
> : >let's suppose that we want to run an area0 backbone between the sites,
and
> : >have the infrastructure of each site be an OSPF area.
> : >
> : >a bunch of your customers want to multi-home within a particular
location
> : >to
> : >multiple switches/routers, and since you don't really want the customer
to
> : >participate in your IGP (auughhh) you have to statically route them,
and
> : >redistribute the routes within the area. summarizing lsa type-5s at
each
> : >ASBR is out, as a customer could drop their uplink to that ASBR,
without
> : >the
> : >summarizing ASBR dropping the aggregate which would kinda kill their
> : >traffic
> : >- good ol' CEF keeps a-load-balancing half the traffic to the router
> : >without
> : >a route... ;-)
> : >
> : >hence, this is why I want full specifics intra-area, and aggregate-only
> : >inter-area.
> : >
> : >I could do it on a Juniper dammit...
> : >
> : >take care :-)
> : >
> : >Andy
> : >
> : >Peter Van Oene wrote on July 18, 2001 at 9:14 PM:
> : >
> : >Ahh, I did indeed mean to suggest that you filter at the ingress ASBR
(the
> : >one that creates the type 5 in the first place) Type 5's are
unmodified
> : >throughout the AS and thus there is no mechanism within the protocol to
> : >control their flow between areas. However, I'm confused as to why you
> need
> :
> : >the full specifics advertised to the area and only the summary to the
rest
> : >of the AS. Even if you have multiple customer networks attached to the
> : >ASBR, you are still going to pull traffic destined toward them to the
ASBR
> : >via the aggregate. What are you gaining by not using the summary
address
> : >command on the ASBR?
> : >
> : >
> : >*********** REPLY SEPARATOR ***********
> : >
> : >On 7/18/2001 at 3:34 PM [EMAIL PROTECTED] wrote:
> : >
> : >>hi all,
> : >>
> : >>thanks for all the replies - gave me some stuff to chew over
> : >>
> : >>have been looking into this some more - it's still bugging me.
> : >>
> : >>my investigations revealed:
> : >>
> : >>* making the area stub or total-stub will not work as type-5s are not
> : >>permitted in the area. all routers set E=0 in the options field to
> denote
> : >>stub, and won't talk to non-stub neighbors. no fooling them
> apparently...
> : >>
> : >>* summary-address will only summarize external routes originated on
that
> : >>local router - hence cannot use to summarize for non-local type-5s
> : >>
> : >>I cannot believe that it is not possible to do something as simple as
> this
> : >>without resorting to multiple OSPF instances and redistributing
between
> : >>them!!
> : >>
> : >>cheers
> : >>
> : >>Andy
> : >>
> : >>Peter Van Oene wrote on July 13, 2001 at 6:43 PM:
> : >>
> : >>
> : >>> Making the area stub will explicitly deny the use of type 4/5 in the
> : >>area,
> : >>> hence, this should not work. Summarization at the ABR would make
the
> : >>most
> : >>> sense to me. Odd that it doesn't seem to work.
> : >>>
> : >>> pete
> : >>>
> : >>> *********** REPLY SEPARATOR ***********
> : >>>
> : >>> On 7/12/2001 at 6:40 PM John Neiberger wrote:
> : >>>
> : >>> >Could you accomplish this by making the area containing the ASBR a
> : >>> >stubby area? IIRC, you can put an ASBR inside a stubby area but
the
> : >>> >Type-5 LSAs will not leave the area. I'm not sure about that, but
I'd
> : >>> >swear I read that somewhere recently.
> : >>> >
> : >>> >Okay, I just checked this in Giles, 2nd edition. According to him,
> the
> : >>> >above is true. But who knows if it works in the real world.
> : >>> >
> : >>> >Good luck!
> : >>> >
> : >>> >John
> : >>> >
> : >>> >>>> "[EMAIL PROTECTED]"
> : >>> > 7/12/01 1:58:11 PM >>>
> : >>> >hi all,
> : >>> >
> : >>> >have a problem that has been nagging at me for a good long time
now...
> : >>> >
> : >>> >say you have a pair of ABRs sitting at an OSPF area boundary, and
an
> : >>> >ASBR is
> : >>> >originating Type-5 LSAs from inside the non-backbone area. Is
there
> an
> : >>> >easy
> : >>> >way to suppress the propagation of the type-5s outside the area? I
> : >>> >would
> : >>> >have a range statement on the ABRs to advertise the area aggregate,
I
> : >>> >just
> : >>> >want to suppress the more specifics.
> : >>> >
> : >>> >I have tried using 'distribute-list out ' which would do it for
> : >>> >me, but for some reason IOS won't allow this with OSPF:
> : >>> >
> : >>> >router(config)#router os 1
> : >>> >router(config-router)#distribute-list 1 out FastEthernet 0/0
> : >>> >% Interface not allowed with OUT for OSPF
> : >>> >router(config-router)#
> : >>> >
> : >>> >I suppose that allowing this could potentially screw up routing if
> : >>> >done
> : >>> >without some care, but JunOS lets you do exactly this sort of
thing -
> : >>> >you
> : >>> >can produce some wacky policies, but at least you have the option
;-)
> : >>> >
> : >>> >btw - I know I could prolly do this with multiple OSPF instances
and
> : >>> >redistribute between them, but I *really* don't want to get into
this
> : >>> >level
> : >>> >of complexity.
> : >>> >
> : >>> >thanks in advance - this one has been driving me mad
> : >>> >
> : >>> >Andy
> :
> :
> :
> :
> :
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=12929&t=12929
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
