Almost identical setup has been discussed on Nanog mailing list in the beginning of June. Search the archives.
XCONNECT probably won't work over the Internet without MPLS/GRE/IP setup and then you'll hit the MTU issues. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -----Original Message----- > From: Andy Ashley [mailto:li...@nexus6.co.za] > Sent: Wednesday, July 08, 2009 6:09 PM > To: cisco-nsp@puck.nether.net > Subject: [c-nsp] Multi-site single AS architecture > > 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. > > > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
