Mailing List Archive

On Wed, 9 May 2012 14:29:57 -0700
Morgan Mclean <wrx230@gmail.com> wrote:

> Hi everyone,
>
> I have a two network segments, OSPF area 0 and 1. I have a firewall
> cluster with interfaces in both areas. I need to stop say a default
> route from area 0 making its way into area 1.
>
> I've tried import and export policies but nothing seems to really
> work. Can anybody please give me an example? Is this against how OSPF
> works?
>
> Thanks,
> Morgan

An OSFP filter map should do the job you want. You basically define
which routes are allowed to export/import.

--
Burkhard Ott
System Administrator
Revenuewire Inc.
1205 - 4464 Markham Street
Victoria, BC V8Z 7X8
250-984-1132
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Your export policy must be applied at the announcement router. For example, my area 0 router only announces a default route and nothing else. Set a match and don't forget the reject.

Will

On May 9, 2012, at 4:30 PM, "Morgan Mclean" <wrx230@gmail.com> wrote:

> Hi everyone,
>
> I have a two network segments, OSPF area 0 and 1. I have a firewall cluster with interfaces in both areas. I need to stop say a default route from area 0 making its way into area 1.
>
> I've tried import and export policies but nothing seems to really work. Can anybody please give me an example? Is this against how OSPF works?
>
> Thanks,
> Morgan
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

I tried the restrict statement under area 1 for another route as a test:

[edit protocols ospf area 0.0.0.1]
+ area-range 192.168.30.156/30 {
+ restrict;
+ exact;
+ }

And I still see it on the other end:


192.168.30.156/30 *[OSPF/10] 22:22:03, metric 2
> to 192.168.30.110 via ge-7/0/0.0

Morgan


On Wed, May 9, 2012 at 3:18 PM, OBrien, Will <ObrienH@missouri.edu> wrote:

> Your export policy must be applied at the announcement router. For
> example, my area 0 router only announces a default route and nothing else.
> Set a match and don't forget the reject.
>
> Will
>
> On May 9, 2012, at 4:30 PM, "Morgan Mclean" <wrx230@gmail.com> wrote:
>
> > Hi everyone,
> >
> > I have a two network segments, OSPF area 0 and 1. I have a firewall
> cluster with interfaces in both areas. I need to stop say a default route
> from area 0 making its way into area 1.
> >
> > I've tried import and export policies but nothing seems to really work.
> Can anybody please give me an example? Is this against how OSPF works?
> >
> > Thanks,
> > Morgan
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Will,

You mean the export policy restricting 0/0 from area 0 to area 1 must be on
the srx that has an interface from area 0, and an interface from area 1.
Correct?

I've tried this with no luck on my ospf export policy:

+ term deny-test {
+ from {
+ area 0.0.0.0;
+ route-filter 192.168.30.156/30 exact;
+ }
+ to area 0.0.0.1;
+ then reject;
+ }


On Wed, May 9, 2012 at 3:50 PM, Morgan McLean <wrx230@gmail.com> wrote:

> I tried the restrict statement under area 1 for another route as a test:
>
> [edit protocols ospf area 0.0.0.1]
> + area-range 192.168.30.156/30 {
> + restrict;
> + exact;
> + }
>
> And I still see it on the other end:
>
>
> 192.168.30.156/30 *[OSPF/10] 22:22:03, metric 2
> > to 192.168.30.110 via ge-7/0/0.0
>
> Morgan
>
>
> On Wed, May 9, 2012 at 3:18 PM, OBrien, Will <ObrienH@missouri.edu> wrote:
>
>> Your export policy must be applied at the announcement router. For
>> example, my area 0 router only announces a default route and nothing else.
>> Set a match and don't forget the reject.
>>
>> Will
>>
>> On May 9, 2012, at 4:30 PM, "Morgan Mclean" <wrx230@gmail.com> wrote:
>>
>> > Hi everyone,
>> >
>> > I have a two network segments, OSPF area 0 and 1. I have a firewall
>> cluster with interfaces in both areas. I need to stop say a default route
>> from area 0 making its way into area 1.
>> >
>> > I've tried import and export policies but nothing seems to really work.
>> Can anybody please give me an example? Is this against how OSPF works?
>> >
>> > Thanks,
>> > Morgan
>> > _______________________________________________
>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Also, just to add to this, if I try to deny a route by neighbor or
next-hop, the entire route is denied regardless of where it comes from.

If I try to deny the export of a route from protocol static on the
announcing router, again it doesn't matter to which neighbor, it denies the
entire route.

Am I just SOL? BGP is so much easier to work with....

Morgan

On Wed, May 9, 2012 at 3:58 PM, Morgan McLean <wrx230@gmail.com> wrote:

> Will,
>
> You mean the export policy restricting 0/0 from area 0 to area 1 must be
> on the srx that has an interface from area 0, and an interface from area 1.
> Correct?
>
> I've tried this with no luck on my ospf export policy:
>
> + term deny-test {
> + from {
> + area 0.0.0.0;
> + route-filter 192.168.30.156/30 exact;
> + }
> + to area 0.0.0.1;
> + then reject;
> + }
>
>
> On Wed, May 9, 2012 at 3:50 PM, Morgan McLean <wrx230@gmail.com> wrote:
>
>> I tried the restrict statement under area 1 for another route as a test:
>>
>> [edit protocols ospf area 0.0.0.1]
>> + area-range 192.168.30.156/30 {
>> + restrict;
>> + exact;
>> + }
>>
>> And I still see it on the other end:
>>
>>
>> 192.168.30.156/30 *[OSPF/10] 22:22:03, metric 2
>> > to 192.168.30.110 via ge-7/0/0.0
>>
>> Morgan
>>
>>
>> On Wed, May 9, 2012 at 3:18 PM, OBrien, Will <ObrienH@missouri.edu>wrote:
>>
>>> Your export policy must be applied at the announcement router. For
>>> example, my area 0 router only announces a default route and nothing else.
>>> Set a match and don't forget the reject.
>>>
>>> Will
>>>
>>> On May 9, 2012, at 4:30 PM, "Morgan Mclean" <wrx230@gmail.com> wrote:
>>>
>>> > Hi everyone,
>>> >
>>> > I have a two network segments, OSPF area 0 and 1. I have a firewall
>>> cluster with interfaces in both areas. I need to stop say a default route
>>> from area 0 making its way into area 1.
>>> >
>>> > I've tried import and export policies but nothing seems to really
>>> work. Can anybody please give me an example? Is this against how OSPF works?
>>> >
>>> > Thanks,
>>> > Morgan
>>> > _______________________________________________
>>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi,

If you want to summarize from area 0 to area 1 you should put the
'area-range' in area 0. Did you try that? Don't forget the restrict to
filter the route.

HTH
Ivan,

On Thu, May 10, 2012 at 5:06 AM, Morgan McLean <wrx230@gmail.com> wrote:

> Also, just to add to this, if I try to deny a route by neighbor or
> next-hop, the entire route is denied regardless of where it comes from.
>
> If I try to deny the export of a route from protocol static on the
> announcing router, again it doesn't matter to which neighbor, it denies the
> entire route.
>
> Am I just SOL? BGP is so much easier to work with....
>
> Morgan
>
> On Wed, May 9, 2012 at 3:58 PM, Morgan McLean <wrx230@gmail.com> wrote:
>
> > Will,
> >
> > You mean the export policy restricting 0/0 from area 0 to area 1 must be
> > on the srx that has an interface from area 0, and an interface from area
> 1.
> > Correct?
> >
> > I've tried this with no luck on my ospf export policy:
> >
> > + term deny-test {
> > + from {
> > + area 0.0.0.0;
> > + route-filter 192.168.30.156/30 exact;
> > + }
> > + to area 0.0.0.1;
> > + then reject;
> > + }
> >
> >
> > On Wed, May 9, 2012 at 3:50 PM, Morgan McLean <wrx230@gmail.com> wrote:
> >
> >> I tried the restrict statement under area 1 for another route as a test:
> >>
> >> [edit protocols ospf area 0.0.0.1]
> >> + area-range 192.168.30.156/30 {
> >> + restrict;
> >> + exact;
> >> + }
> >>
> >> And I still see it on the other end:
> >>
> >>
> >> 192.168.30.156/30 *[OSPF/10] 22:22:03, metric 2
> >> > to 192.168.30.110 via ge-7/0/0.0
> >>
> >> Morgan
> >>
> >>
> >> On Wed, May 9, 2012 at 3:18 PM, OBrien, Will <ObrienH@missouri.edu
> >wrote:
> >>
> >>> Your export policy must be applied at the announcement router. For
> >>> example, my area 0 router only announces a default route and nothing
> else.
> >>> Set a match and don't forget the reject.
> >>>
> >>> Will
> >>>
> >>> On May 9, 2012, at 4:30 PM, "Morgan Mclean" <wrx230@gmail.com> wrote:
> >>>
> >>> > Hi everyone,
> >>> >
> >>> > I have a two network segments, OSPF area 0 and 1. I have a firewall
> >>> cluster with interfaces in both areas. I need to stop say a default
> route
> >>> from area 0 making its way into area 1.
> >>> >
> >>> > I've tried import and export policies but nothing seems to really
> >>> work. Can anybody please give me an example? Is this against how OSPF
> works?
> >>> >
> >>> > Thanks,
> >>> > Morgan
> >>> > _______________________________________________
> >>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> >>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>>
> >>
> >>
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



--
Best Regards!

Ivan Ivanov
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Thursday, May 10, 2012 04:06:26 AM Morgan McLean wrote:

> Also, just to add to this, if I try to deny a route by
> neighbor or next-hop, the entire route is denied
> regardless of where it comes from.
>
> If I try to deny the export of a route from protocol
> static on the announcing router, again it doesn't matter
> to which neighbor, it denies the entire route.
>
> Am I just SOL? BGP is so much easier to work with....

Link state routing protocols don't generally like to be
filtered, as a consistent, holistic view of the global
network topology is the only way to avoid loops in your link
state IGP network.

Yes, there is some kind of filtering available in routing
implementations for link state routing protocols, and as you
can see, it behaves rather strangely and might not do
everything you want, the way you want or expect. For some
implementations, I've seen filtering on inbound to be more
successful, while in others, it's been the reverse.

At the heart of it, while it is possible to filter prefixes
being announced/received, the filters don't really filter
the entire IGP message, as what is exchanged among neighbors
is LSA's (OSPF) and LSP's (IS-IS), and not routes as in the
case of BGP.

I have been in your exact situation before where we've had
to originate a default route to various Access switches in
Metro-E rings, and IS-IS seemed like an obvious way to do it
between the PE Aggregation routers and the Access switches
directly. But while you could originate the default route to
the Access network, it wasn't easy to prevent said route
from being announced to other parts of the network where it
"wasn't" needed (especially since we were a flat Level-2 IS-
IS network). Unlike BGP, route exchanges among neighbors is
not unicast in nature (yes, it can be in certain cases), so
controlling which routes/LSA's/LSP's go where isn't easy.

We ended up going with BGP, getting those default routes
announced to all Access switches from the control-plane-only
route reflectors in the network, and relying on MPLS to
ensure proper forwarding of traffic (away from the route
reflectors that were originating those default routes).

Hope this helps.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp