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/ospf-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=12917&t=12917
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
