[c-nsp] 2 locations, 2 ISPs, 2 ASAs, configuration confusion

Phil Mayers p.mayers at imperial.ac.uk
Tue Jan 23 03:22:53 EST 2007


Winders, Timothy A wrote:
>>>
>>>
>>>           Internet
>>>            /    \
>>>         ISP1    ISP2
>>>          |       |
>>>         ER1 --- ER2
>>>          |       |
>>>         ASA1    ASA2
>>>          |       |
>>>        CORE1 --- CORE2
>>>
>>
>> If you are running iBGP all the way to CORE1 & CORE2 then you will 
>> need a full mesh.  So you are missing iBGp from ER1 to CORE2, ER2 to 
>> CORE1, and CORE1 to CORE2.
>>
>> Alternatively if you use ER1/ER2 as your BGP edge then you could run 
>> OSPF Between the edge routers, and from the edge routers to the ASAs 
>> and inside the ASAs also. If ER1 / ER2 are injecting default routers 
>> into OSPF then I think that would do the trick.
> 
> Thanks, Peter.
> 
> A full BGP mesh would not work.  We need the routing protocol to know
> that CORE2 is 2 hops away from ER1 and vice-versa.  This is what will

You're misunderstanding how iBGP works. iBGP routers advertise their 
iBGP routes as going via their loopbacks, and you additionally run an 
IGP e.g. OSPF which gives you the costs to the loopbacks, which achieves 
what you're talking about.

The full mesh simply refers to a full mesh of routing sessions (which 
are not adjacencies in iBGP) which you would need unless you use a route 
reflector (barely worth it for this number of routers). I imagine iBGP 
was suggested out of a combination of "best practice" and "policy 
control" thinking. Whether it's a reasonable suggestion depends on your 
needs and the size of the routing table, plus whether you've got much 
expertise in running it. If you can, I'd consider using it.

We have a somewhat similar setup to this, thought CORE1 and CORE2 are on 
the same site, not geographically remote. It's currently using OSPF, 
planned to move to iBGP shortly. Some things you need to watch for:

The routing costs from CORE1-ASA1-ER1-ER2 and CORE1-CORE2-ASA2-ER2 need 
to be different. That probably means making the ER1-ER2 link have a cost 
of 10 and the CORE1-CORE2 link a cost of 11, and the ERn-COREn paths 
have a high cost (say, 50) to prevent traffic flowing anywhere odd, such 
as out the firewalls and back in.

If there are any downstream routers attached to both core1 and core2 you 
will similarly need to bias the metrics such that odd things don't happen.

Finally, if you do put a tunnel in via the internet, you probably want 
to rig it such that er1 only advertises core1 and er2/core2 - else the 
traffic might flow into er1, back out via the tunnel and into er2 and 
effectively halve your bandwidth.

Good luck.


More information about the cisco-nsp mailing list