[c-nsp] Multi-site single AS architecture

Andy Ashley lists at nexus6.co.za
Wed Jul 8 12:09:20 EDT 2009


Hi,

Apologies for this long post, I am hoping to explain in full:
(there was a similar thread recently but Im looking for slighly 
different info)

Background:
We currently have a primary site which has two 7206 border routers, each 
has an uplink and ebgp session over that into our primary transit provider.
These border routers are also plugged into our two 6500 core switches 
(3BXL holding the full table).

There is also a metro ethernet circuit which is plugged into one of the 
core switches. This circuit goes to another site (plugged into another 
7206 there) on the other side of the city where we pick up some backup 
transit and peers at an exchange. All routers peer with one another in 
the ibgp mesh, the two seperate sites are in a confederation with 
different private AS numbers and externally are announced as the same 
AS. Presently all prefixes are announced via the primary site (tagged 
statics).

We need to make sure that this secondary site is visible should the 
metro ethernet break or the primary site is unavailable.
What we proposed to do was firstly re-address the second site to use 
seperate prefixes (few smaller /22 and /23 out of a larger aggregate 
announced from the primary site)
Then to put a route in at the secondary site to ensure that the prefix 
in use there would would still be announced via the backup transit 
provider and peers should the primary site or metro link have a problem.

We also need to be able to reach services at the secondary site from the 
primary should the metro link go down. This raises the problem of our 
routers not accepting thier own AS in the AS path.
I would prefer not to use the method of telling the routers to accept 
thier own AS in the path if possible. To get around this, we were 
thinking of using an xconnect tunnel to create a virtual backnet between 
border routers at each site. This should hopefully allow the ibgp 
sessions to stay up over this tunnel via the Internet instread of over 
the usually preferred direct connection.

We are using xconnect statements at the moment to extend some VLAN's 
across the metro link between sites (router loopbacks are the end points).
The MTU is set high at 9216 on the metro link and this works fine.

My questions:
1. Will the xconnect (encapsulation mpls) come up if connecting via the 
Internet instead of over a VLAN on the metro link?
2. What interface would be best to configure the xconnect from and to on 
each end?
3. Should we tell ibgp to peer with this interface instead of the 
loopbacks on each border router?
4. How reliable/recommended is this method? Im wary of imlementing 
something flaky..

Any comments or hints you may have to offer would be most welcome!


Thanks.
Andy.






-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the cisco-nsp mailing list