Sorry for the delay in my responses.
Some good comments Keegan! Thanks.
Keegan - many providers have a private MPLS network. A very very large one
in the US does! ;-)
It is not a bad idea from a security and stability standpoint and network
management. You can also allow this network to scale without having to be
concerned with interop and testing with the other networks that the SP might
operate.
Any who ...
Interesting to test this default route with OSPF, EIGRP, and BGP. I did not
test it on RIP ... , however, after doing this with OSPF and EIGRP, you can
see what needs to be done.
Use this link as a guideline for EIGRP:
http://www.shafagh.net/2009/11/internet-through-mpls-default-route.html
However, you do not need the default-information command under the eigrp
configs on the far side PE. BGP is even easier ... (as someone earlier
mentioned ...)
So ... long story short, thanks Andy for the original post and all the
back-in-forth team.
Andrew Lee Lissitz
On Tue, Nov 17, 2009 at 7:19 AM, <Keegan.Holley_at_sungard.com> wrote:
>
> Also, I doubt seriously that providers keep separate core's for the
> different kinds of traffic. The whole point of running MPLS is to be able
> to separate customer traffic regardless or source or destination IP. Also,
> they will need to deliver both services from the same long distance pop. It
> would mean tossing out CRS and 7600 series routers all over the place to do
> something that can be accomplished in software.
>
>
>
> From:
> ALL From_NJ <all.from.nj_at_gmail.com>
> To: Keegan.Holley_at_sungard.com Cc: andy thomas <thomasandy32_at_gmail.com>,
> Cisco certification <ccielab_at_groupstudy.com>, nobody_at_groupstudy.com Date: 11/16/2009
> 07:45 PM Subject: Re: Internet Access
> Sent by: <nobody_at_groupstudy.com>
>
> ------------------------------
>
>
>
> Hey team,
>
> Was thinking more about this ... and while my set up will work for a lab
> and
> lab testing ... it may not be as real life as it should be. It is fun to
> tshoot a silly design, but I think a little more color should be added to
> this posting.
>
> Here is what I mean, each customer has their own routing and internet
> access
> point.
>
> Keegan in the example I gave, you can create a default route via bgp from
> the PE. This gets propagated ok and works. In the real world the provider
> is not going to generate this via the PE, although in our labs this can
> make
> for some easier testing.
>
> From the customer's perspective, they do not 'see' MPLS or any of the L3
> VPN
> stuff ... they only see routing and route tables. A customer likely has
> two
> links at the core / head-end office:
>
> 1st link - FW and NAT to the internet
> 2nd link - Into the MPLS cloud for site to site connectivity
>
> I am making the assumption that most large MPLS providers have a separate
> network for private site to site MPLS networks and another for internet
> access and single sites. Both of these can run MPLS, however the routing
> will obviously be different internally to the SP and externally from a
> global perspective.
>
> What I will lab up tonight:
>
> 2 CE routers, one pretending to the head-end / core router, and another CE
> router pretending to be the spoke / edge.
>
> On the head end / core CE, I will have two uplinks. One going into my
> global network after being NAT'ed, and FW. The other link going into the
> MPLS 'cloud' and generating a default route via OSPF for the remote site.
>
> This is a bit more realistic. Any thoughts team? HTH,
>
> Andrew Lee Lissitz
>
>
>
> On Mon, Nov 16, 2009 at 4:54 PM, <Keegan.Holley_at_sungard.com> wrote:
>
> > Sorry I'm more used to juniper, but what does the route look like in the
> > bgp table for that vrf?
> >
> >
> >
> > From:
> > andy thomas <thomasandy32_at_gmail.com>
> > To:
> > Cisco certification <ccielab_at_groupstudy.com>
> > Date:
> > 11/16/2009 07:24 AM
> > Subject:
> > Internet Access
> > Sent by:
> > <nobody_at_groupstudy.com>
> >
> >
> >
> > Hey Experts,
> >
> >
> >
> > A------B--------C-------------Customer D (MPLS VPN)
> > |
> > |
> > E---------------(Customer F remote site)
> >
> > B is the internet gateway originating a default route via
> > OSPF(default-information originate) pointing a static default route to A
> > which is providing a internet access to router B ,C,and E. I want to
> > provide
> > a internet access to customer VRF D and am pointing to global route table
> > for the route of B interface,Everything is working fine customer D is
> able
> > to go on internet.
> >
> > Customer D & F is exchanging same RT and they are able to exchange
> private
> > routes amoung themselves but when the default static route for the
> > internet is redistributed in VRF on router C it is not advertised to
> > Router
> > E for customer F,why??? any specific reason.???? Added a defualt static
> > route on E same what i did on C pointing to global route table of
> > Interface
> > B to let customer F go on the internet.
> >
> > Configs:
> >
> > Router C:
> >
> > ip route vrf customer D 0.0.0.0 0.0.0.0 (router B Interface) global
> >
> > address-family ipv4 vrf cutomer D
> > redistribute connected
> > redistribute static
> > no synchronization
> > exit-address-family
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
>
>
-- Andrew Lee Lissitz all.from.nj_at_gmail.com Blogs and organic groups at http://www.ccie.netReceived on Thu Nov 19 2009 - 13:12:43 ART
This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:29 ART