[c-nsp] EIGRP and OSPF

[Brad Swanson]

One good thing about NOT having area 0, no inter-area routes are learned 
between non-area 0 areas.  This removes the requirement today to have to 
filter between areas, as long as we do NOT have an area 0.  (test lab proved 
this out)

I want to trust the IBM-supported IBM mainframes but now that I read the 
last few lines of your reply, I am mistaken in my trust.  The routing 
updates are outside my area of control, and since this is a somewhat 
important piece of the puzzle here (understatement), I need to implement 
controls around a possible fat-finger.

So, seems like I have some options:

1)  make MF's stub, this may not be an option as I have been down this path 
before with IBM'ers and Cisco folks, there are some drawbacks.

2)  I prefer not use to ABR Type 3 LSA filtering, so...

3)  use multiple OSPF processes.  I suppose there are CPU issues with this 
option, I will dig into this further.

and without question:

4)  filter using dist list in cmd on vlans I want to control.

With all this, the minute we implement an area 0, I will need to use a dist 
list in cmd on all area 0 participants.  I proved this in the lab excersize 
yesterday, it makes sense why the routes are passed when an area 0 is used, 
and a dist list in will prevent bogus routes from being inserted with the 
always-popular corpulent pointer...

Thanks,
brad


>From: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
>To: "Brad Swanson" <lakepepin at hotmail.com>, <cisco-nsp at puck.nether.net>
>Subject: RE: [c-nsp] EIGRP and OSPF
>Date: Wed, 12 Oct 2005 10:09:56 +0200
>
>Brad Swanson <> wrote on Tuesday, October 11, 2005 3:47 PM:
>
> > The overall config:
> >
> > Standard Cisco three tier design - core/dist/access.
> >
> > OSPF with three areas, but NO area 0.  OSPF is used for a very basic
> > IBM mainframe OSPF implementation.
> >
> > All IBM MF's land on the same L2 access swt with the OSPF happening
> > at the dist layer for ALL OSPF areas.
> >
> > All routes from OSPF are redist. into the network-wide routing
> > protocol EIGRP.
> >
> > What I want to be able to do is limit the routes learned from the
> > MF's to xxxx since I do not have control over the devices sending me
> > routes.  Is what I have below gonna get me where I want to be?
>
>Yes, but:
>
> > Again, I do not want devices participating in OSPF NOT in their area
> > to learn other routes from other OSPF devices.
>
>This is a different requirement.
>
>So: "distribute-list 40 in" will prevent your router from ever putting
>routes matching this acl advertised by any of the OSPF speakers into its
>routing table and will thus prevent them from being redistributed into
>EIGRP. This effectively limits the harm the MF's can do (you might want
>to extend the ACL to other prefixes and also replace it by a prefix-list
>which allows for a more granular control than a standard ACL).
>But it will not prevent this prefix to be flooded into the other areas
>attached to your ABR, so those devices would still see all the prefixes
>via Type 3 or Type5 LSAs.
>Do you care if one MF messes up the routing table of another MF as long
>as your router and your core-IGP are fine? You might not ;-)
>
> > router ospf 132
> > log-adjacency-changes
> > network 10.116.110.0 0.0.1.255 area 112
> > network 10.116.120.0 0.0.1.255 area 122
> > network 10.116.130.0 0.0.1.255 area 132
> > default-information originate
> > distribute-list 40 in
> >
> > Do devices in area
> > 112 have to go into EIGRP to get to devices in area 122?
>
>what do you mean by "go into EIGRP"?
>
>If you don't want area 112 know about routes in other areas, you have
>several options:
>
>1) make it stub or nssa (requires the chance on all MFs as well)
>2) if (1) is not possible, use "ABR Type 3 LSA filtering" feature to
>filter type3 summaries (will not work for type5)
>3) use multiple OSPF processes
>
>You definitly want to limit the prefixes advertised into OSPF, as well
>as summarize them if possible. if one of the MFs advertises a couple of
>thousand "valid" prefixes, this could blow up your EIGRP.. so you do
>want to use a tight control on the prefixes redistributed into your
>EIGRP.
>
>	oli