ODPF - How to not propagate default gateway between areas?

ODPF - How to not propagate default gateway between areas?

NewsGroups | Search | Tools
 alt.certification.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
ODPF - How to not propagate default gateway between areas? Sailor 12-01-2007
Posted by Sailor on December 1, 2007, 11:31 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Hello.

Two OSPF areas (0 and 1) are connected with ABR (Area Border Router).
Every area has it's own default gateway (DG), that should be propagate
only in a scope of this area.

Information about networks in area 0 should be propagate to area 1.
Information about networks in area 1 should be propagate to area 0.
Information about DG from area 0 should not be propagate to area 1.
Information about DG from area 1 should not be propagate to area 0.


Example diagram (use monospace font):

(Internet)
|
|
|
(cloud of routers from AREA0)
|
|
|
R_AREA0 <----serial----> ABR <----serial----> R_AREA1
|
|
|
|
                (cloud of routers from AREA1)
|
|
|
|
                                         (Internet)


I try to use filter-list on ABR, but it do not work as I would like to.
Information about particular internal networks is easy to filter, but DG
are always distribute between areas and this makes a problem.

DG is propagate through command "default-information originate" and it's
seen by other routers as "OSPF external type 2". I've read somewhere
that external routes can't be filter by filter-list in ABR. That
explains why DG routes are propagate between areas. But I would like to
know, if there is possibility to resolve the problem.

Part of routing table in cloud of routers from AREA1 (notice E2 route)
O*E2 0.0.0.0/0 [110/1] via 192.168.167.6, 01:15:55, FastEthernet0/0


Part of configuration from ABR:

router ospf 1
area 0 filter-list prefix area1nets in
area 1 filter-list prefix area0nets in
network 192.168.0.0 0.0.127.255 area 0
network 192.168.128.0 0.0.127.255 area 1

ip prefix-list area0nets seq 5 permit 192.168.12.0/24
ip prefix-list area0nets seq 10 permit 192.168.24.0/24
ip prefix-list area0nets seq 15 permit 192.168.23.0/24
ip prefix-list area0nets seq 20 permit 192.168.34.0/24
ip prefix-list area0nets seq 25 deny 0.0.0.0/0
!
ip prefix-list area1nets seq 5 permit 192.168.146.0/24
ip prefix-list area1nets seq 10 permit 192.168.156.0/24
ip prefix-list area1nets seq 15 permit 192.168.167.0/24
ip prefix-list area1nets seq 20 deny 0.0.0.0/0


--
Best regards,
Sailor

Network Magic 20% Off NMEASY coupon code spring banner 468x60
Posted by pk on December 1, 2007, 12:30 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Sailor wrote:

> DG is propagate through command "default-information originate" and it's
> seen by other routers as "OSPF external type 2". I've read somewhere
> that external routes can't be filter by filter-list in ABR. That
> explains why DG routes are propagate between areas. But I would like to
> know, if there is possibility to resolve the problem.

Maybe I'm not understanding correctly, but can't you just avoid
using "default-information originate"?


Posted by Sailor on December 1, 2007, 1:06 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
pk pisze:
> Sailor wrote:
>
>> DG is propagate through command "default-information originate" and it's
>> seen by other routers as "OSPF external type 2". I've read somewhere
>> that external routes can't be filter by filter-list in ABR. That
>> explains why DG routes are propagate between areas. But I would like to
>> know, if there is possibility to resolve the problem.
>
> Maybe I'm not understanding correctly, but can't you just avoid
> using "default-information originate"?

Do you mean to configuring default gw on each router as alternative? I
would like to avoid this.

--
Best regards,
Sailor

Posted by Sailor on December 1, 2007, 1:12 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
pk pisze:
> Sailor wrote:
>
>> DG is propagate through command "default-information originate" and it's
>> seen by other routers as "OSPF external type 2". I've read somewhere
>> that external routes can't be filter by filter-list in ABR. That
>> explains why DG routes are propagate between areas. But I would like to
>> know, if there is possibility to resolve the problem.
>
> Maybe I'm not understanding correctly, but can't you just avoid
> using "default-information originate"?

Is there another method to propagate information about default gateway
to routers in area?

--
Best regards,
Sailor

Posted by pk on December 2, 2007, 9:57 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Sailor wrote:

>> Maybe I'm not understanding correctly, but can't you just avoid
>> using "default-information originate"?
>
> Is there another method to propagate information about default gateway
> to routers in area?

Ok, so IIUC the internet-connected routers generate the default routes, and
you'd like to block them at the ABR. Topology:

internet----r1a0---(area0 routers)---ABR---(area1 routers)---r1a1---internet

IIUC, r1a0 and r1a1 originate a default route, which is meant to serve as
the default route for the routers of the area.

1) filter-list only filters type 3 LSAs, so in this case it does nothing to
default routes.

2) if you are worried about having multiple default routes, then have the
ASBRs originate the default route using metric type 1. This way, routers
internal to an area will use the "closest" default route (which will
probably be the one originated by the area's ASBR; if this is not the case,
you'll probably be able to adjust the metrics to make this happen).

3) even if you use the default metric type 2, routers internal to an area
will still prefer the default route advertised by the closest ASBR, so the
same concepts expressed in 2) apply, but this time you have to adjust the
metric *to the ASBR*, not the metric of the default route.

4) you didn't say anything about what default route should be used by the
ABR. If you don't want it to load-balance between the two (and you probably
don't), then make sure its metrics to the two ASBR are not equal, or that
it receives the default routes with different metrics.

5) external LSAs are flooded throughout the whole OSPF domain by definition
(unless stub or nssa areas are used, but in your case one of the areas is
area 0 so this is not an option). If you still think that you want to
filter external LSAs, you might run two different OSPF processes on the
ABR, and do mutual route redistribution between them, filtering out the
unwanted default routes using a route map. No need to say that this
solution is awkward to say the least, making all the routes coming from the
other "area" look external. If you need to do that, it's usually a symptom
of bad network design, so you better reorganize your network in a different
way.


Similar ThreadsPosted
a very basic question about default route and default gateway December 6, 2005, 12:29 am
Default Gateway March 3, 2006, 8:21 am
PIX Default gateway September 14, 2006, 7:26 pm
Pix configuration - default Gateway? March 4, 2005, 10:05 pm
CCNA 640-801..how to find default gateway on a switch... October 19, 2005, 5:23 pm
Multiple OSPF Stub Areas March 17, 2006, 5:56 pm
Scenario 4: Multi Areas OSPF May 29, 2006, 9:20 am
CCIE or CCVP wanted in the NY area! (other areas also considered) September 11, 2006, 6:24 pm
gateway of the last resort February 15, 2005, 4:23 pm
trying to make a gateway May 3, 2008, 5:24 pm

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map