From: Jongsoo (bstrt2004@gmail.com)
Date: Mon Nov 07 2005 - 21:48:27 GMT-3
Scott
right now...I like to develop any config as long as it has great chance to work.
I am so hungry fo waiting for 3.0 workbook from IE( Dec is just too
long)...so that my gut feeling is running out as well(???)...except
for the one before.
1) Basically, two uni-directional VRFs, 1) from spoke CE-to HUB CE (
up) and 2) from HUB CE to spoke CE ( down) seem to have a good chance
to work.
But in this case of two uni-directional VRFs, I am not sure if we can
make it work using any IGP between CE and PE replacing static because
we will need inter-VRF routing and I think only static is the only
option for that.
for 2nd config, checked "Hub and spoke VPN #2"
Jongsoo
On 11/6/05, Scott Morris <swm@emanon.com> wrote:
> Correct. As long as the spoke would route through the 0/0 route back to the
> hub, then you would achieve what you wanted.
>
> A little odd, but very workable!
>
> Scott
>
> -----Original Message-----
> From: Jongsoo [mailto:bstrt2004@gmail.com]
> Sent: Sunday, November 06, 2005 12:23 AM
> To: Andrew Lissitz (alissitz)
> Cc: swm@emanon.com; C&S GroupStudy; FORUM
> Subject: Re: We've moved to PE-CE routing! (SP-CCIE)
>
> What I am trying to do is to make two uni-direction VRF forwarding table 1)
> from spoke to hub and 2) from hub and spoke.( not from spoke to spoke
> directly)
>
> In order to prevent the connection from spoke to spoke, I think I have to
> place a route filtering to block one spoke's static routes announcement from
> MP-BGP to the other spoke's VRF...
>
> Something like this
>
> PE1
> ip vrf up
> ...
> route-target export 100
>
> ip vrf down
> ...
> route-target import 200
>
> PE2
>
> ip vrf up
> ...
> route-target import 100
>
> ip vrf down
> ...
> route-target export 200
>
> PE3
>
> ip vrf up
> ...
> route-target import 100
>
>
> ip VRF down
> ...
> route-target export 200
>
>
> If PE1 is not RR and there are only two MP-iBGP session 1) between PE1 and
> PE2 and 2) between PE1 and PE2 ( not between PE2 and PE3), then I figure I
> may not need this route-target manupulation.
>
> I am dying to lab this out. But no time. I may do rack rental I also like to
> come up with another way...
>
> Jongsoo
>
>
> On 11/5/05, Andrew Lissitz (alissitz) <alissitz@cisco.com> wrote:
> >
> >
> >
> > Hello Jongsoo,
> >
> >
> >
> > I have not labbed this up for you ... so there may be something to
> > modify or add to your config thoughts, but here goes. Your questions / my
> comments:
> >
> >
> > * Can I use the next hop address instead of interface for "ip route
> > vrf up 0.0.0.0 0.0.0.0 fe1" command ? The answer is yes. Personal
> > preference, I like to use next hop on any multi-access interface.
> > Once you added the vrf keyword to this command, you have told the
> > router which routing table to look in. The next hop address should be
> > found on a connected interface, so this is fine.
> >
> > * For traffic flow from Hub to Spoke - Once you add a static route on
> > the
> > PE2 and PE3 routers pointing the CE2 and CE3 networks, the VRF routing
> > table contains routing information to reach the networks behind CE2
> > and CE3. This is only within the PE2 and PE3 VRF route table until you
> redist into MPBGP.
> > Within the ipv4 vrf up and vrf down address families, you will need
> > to redist static. As you mentioned all PEs will learn this via MPBGP
> > and update their VRF tables as needed.
> >
> > So after PE1 knows how to reach these networks, it will send the
> > traffic to the correct PE.
> >
> > * What are we missing? Well ... in each of these case the CEs only
> > have one way to go and that is to the PE. For the Hub CE, if it runs
> > static routing, will it know where to go? A default static should be
> > added here as well as to all the CEs.
> >
> > Real world perspective ... (sorry about this) ... The hub router would
> > likely be running BGP or an IGP with the PE. In this case, the CE
> > would learn routing information dynamically. In this limited example,
> > the hub router only has one link to the ISP network... so this is more
> simple.
> >
> > Jongsoo, I did not follow the route-target comments you made. Perhaps
> > this is from when you labbed this up? No worries ... I am sure in the
> > lab this up becomes clear.
> >
> > We are all lacking my man ... especially me!!!!
> >
> >
> > ________________________________
> > From: Jongsoo [mailto:bstrt2004@gmail.com]
> > Sent: Friday, November 04, 2005 8:27 PM
> > To: swm@emanon.com; Andrew Lissitz (alissitz)
> > Cc: C&S GroupStudy; FORUM
> > Subject: Re: We've moved to PE-CE routing! (SP-CCIE)
> >
> >
> > Guys
> >
> > Thanks for the information. I am obviously lacking some "basics" about
> > MPLS VPN.
> > ( I realized I have to think multi-dimensionally to figure out routing
> > behavior among VRFs via MP-BGP and MPLS tags)
> >
> > Anyway, using the static method explained by Scott, Andrew and Arun,
> > I came up with more details hoping I get it right.
> >
> >
> > 1) Static routes only
> > PE1 is RR and all three PEs are in full-mash.
> > There are two VRFs of up( from spoke to hub) and down( from hub to
> > spoke) configured in each PE.
> >
> >
> > CE1-----VRF=down-fe1-PE1-----Pe2-fe2----VRF=Up---CE2 (
> > 10.2.2.0/24)
> > |
> > |
> > PE3
> > fe3
> > |
> > VRF Up
> > |
> > |
> > CE3( 10.3.3.0/24)
> >
> > 1-1) for a traffic flow from spoke( CE2, CE3) to Hub ( CE1) ( VRF =
> > up) In PE1 config,
> > A) put a default static route to CE1 = "ip route vrf up 0.0.0.0 0.0.0.0
> fe1"
> > ( fe1 is the out-going interface to CE1)
> > B) Redistribute the static to bgp, route-export = 100 ( due to
> > full-mash Mp-ibgp, PE2 and PE3 learn this route), In PE2 and PE3
> > A) put the interface connecting CEs to VRF=up
> > B) Import routes w/ route target =100 from MP-BGP
> > C) CE2 and CE3 have a default route to PEs
> >
> > In this way, any traffic from CE2 and CE3 should come into PE1 via
> > MPLS and go out via the fe1 interface of PE1 to CE1 Can I use the next
> > hop address instead of interface for "ip route vrf up 0.0.0.0 0.0.0.0
> > fe1" command ?
> >
> >
> > 1-2) for a traffic flow Hub to Spoke ( VRF = down)
> >
> > In PE2 config,
> > A) put a static route to CE2 = "ip route vrf down 10.2.2.0
> > 255.255.255.0 fe2" ( fe2 is an out-going interface to CE2)
> > B) Redistribute the static to bgp, route-export = 200 ( due to
> > full-mash Mp-ibgp, PE1 and PE3 learn this route but only PE1 imports
> > it), In PE3 config,
> > A) put a static route to CE3 = "ip route vrf down 10.3.3.0
> > 255.255.255.0 fe3" ( fe3 is an out-going interface to CE3)
> > B) Redistribute the static to bgp, route-export = 200 ( due to
> > full-mash Mp-ibgp, PE1 and PE2 learn this route only PE1 imports it),
> > In PE1
> > A) put the interface connecting CE1 to VRF down
> > B) Import routes w/ route target =200 from MP-BGP advertised by PE2
> > and PE3
> > C) CE1 have static routes to PE1 for ip prefix destined to CE2 and CE3
> >
> > In this way, any traffic from CE1 to CE2 or CE2 will be sent to PE1,
> > which will forward it based on VRF down routing table.
> >
> > What am I missing?
> >
> >
> > Jongsoo
> >
> >
> >
> > On 11/4/05, Scott Morris <swm@emanon.com> wrote:
> > > This is definitely fun to keep the SP list alive, although I'm
> > > surprised
> > we
> > > haven't irritated the R&S guys yet!
> > >
> > > Anyway... If I were presented a situation (again, real life
> > > thinking)
> > where
> > > someone said they wanted to essentially set the "hub" site up as a
> > > route-reflector, my first inclination would be to do static routes
> > > between the PE and CE and let their CE routers peer with each other
> > > and not with
> > the
> > > PE at all. That would seem to be a simple way of the SP saying "not
> > > my problem" and save a few headaches.
> > >
> > > Like Andrew says, the goal here is to make the CE fairly ignorant of
> > > the VRF's existance (although with allowas-in, it kinda makes that
> moot).
> > >
> > > If this were a lab scenario, you'd certainly need to look at what
> > > things
> > you
> > > were or were not allowed to do, but I'd keep it as simple as possible!
> > >
> > > Scott
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > > Of Andrew Lissitz (alissitz)
> > > Sent: Friday, November 04, 2005 12:43 AM
> > > To: Jongsoo
> > > Cc: C&S GroupStudy; FORUM
> > > Subject: RE: "neighbor allowas-in" command ( SP CCIE)
> > >
> > > You are right Jongsoo ... I need to keep my head out of reality for
> > > the
> > CCIE
> > > prep ...
> > >
> > > As you know, for CCIE lab, so much will depend on wording of question.
> > > Thanks for the diagram, it helps.
> > >
> > > So if CE2 and CE3 must go through CE1, then these two sites must
> > > choose to route to the hub site first.
> > >
> > > Normal routing would work. Forgive me if this is boring anyone ... I
> > > am
> > just
> > > going to 'think out loud' in this email.
> > >
> > > The CE and the PE share routes. The PE keeps these routes in the
> > > VRF, the CE is (typically) ignorant of VRF and does not know what
> > > goes on within
> > the
> > > PE. Using iBGP all PEs will share this information so that any PE
> > > with
> > the
> > > same customer VRF will have a converged routing table.
> > >
> > > So depending on what you are or are not permitted to do you can
> > > focus on
> > CE
> > > or PE route manipulation. If this is done via the CE, then
> > > manipulate or filter your IGP so that the next hop is the hub. The
> > > PEs simply share
> > what
> > > they have learned, unless you have configured them otherwise.
> > >
> > > If you do this on the PEs, then filter routing information so the
> > > spoke
> > CEs
> > > think that the hub is the next hop for any where. This could be done
> > either
> > > iBGP, or if the PE and CE run a IGP between them, then filter the
> > > routing information via the PE IGP. The CE IGP will only learn what
> > > is administratively allowed.
> > >
> > > If you can redistribute a static default on the hub PE, cool. You
> > > can
> > allow
> > > only this default to the remotes and allow all | m the spokes to the
> hub.
> > >
> > > Suggestion to the group... Do you all think we should start a new
> > > email string to discuss these options? If we are done with this
> > > allowas-in discussion, then lets create another email string.
> > >
> > > Jongsoo, thanks man for keeping these emails going. You going for
> > > your SP CCIE helps us all!!!
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Jongsoo [mailto:bstrt2004@gmail.com]
> > > Sent: Thursday, November 03, 2005 8:08 PM
> > > To: Andrew Lissitz (alissitz)
> > > Cc: C&S GroupStudy; FORUM
> > > Subject: Re: "neighbor allowas-in" command ( SP CCIE)
> > >
> > > Andrew / All
> > >
> > > I totally agree about normal ISP environment. However, in CCIE lab
> > > is far beyond the normal.
> > >
> > > Let me give a scenario
> > >
> > > CE1------Pe1-----Pe2--CE2
> > > |
> > > |
> > > Pe3---CE3
> > >
> > > CE1 is HQ,
> > > CE2 and CE3 are small office.
> > > For whatever reason( perhaps for virus checking...), CE1 need to be
> > > a hub,
> > > CE2 and CE3 need to be spokes. So that a direct traffic between
> > > CE2 and CE3 is not allowed, it must go through CE1.
> > >
> > > I am looking for how many ways exist to design this topology.
> > >
> > >
> > > Thanks
> > >
> > > Jongsoo
> > >
> > >
> > > On 11/3/05, Andrew Lissitz (alissitz) <alissitz@cisco.com> wrote:
> > > > Hey Dude,
> > > >
> > > > ISPs run iBGP between PEs (more common to use RRs but same
> > > > concept), so the idea of a PE seeing it's own ASN in the path is not
> likely.
> > > > The PE may see different AS numbers repeated in the path, but what
> > > > does it care? As long as it does not see its own ASN and detect a
> > > > loop, all is well.
> > > >
> > > > Some ISPs give the customers one ASN for all the customer sites.
> > > > In this case, this problem will occur. The CE will see the routes
> > > > from the remotes sites and see it's ASN in the path. Refer to
> > > > that earlier
> > >
> > > > diagram.
> > > >
> > > > Other ISPs give the customers different ASN for each site... but
> > > > for obvious reasons this does not scale.
> > > >
> > > > So, in the case of hub and spoke (is this common, have you all
> > > > seen this in production?), each PE is running iBGP with each other
> > > > or the hub is a RR. Each PE will not see it's own ASN. Each PE
> > > > has learned BGP routes from it's CE and will pass these between
> > > > peers. Each peer will run the best path process and select the
> > > > best route. Only best routes are advertised ...
> > > >
> > > > If for some reason, your BGP speakers will see what appears to be
> > > > a loop, then allowas will work. You can also override the ASN as
> well.
> > > >
> > > > Andrew rule of thumb (does not mean much ... will not even get you
> > > > free
> > > > coffee): allowas-in would be configured on CEs because they are
> > > > receiving these routes, and as-override would be configured on
> > > > routers
> > >
> > > > advertising routes ... more than likely the PEs.
> > > >
> > > > Jongsoo, I do not feel as though I have fully answered your
> > > > question
> > > ...
> > > > Sorry about that.
> > > >
> > > > Andrew
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > > > Behalf Of Jongsoo
> > > > Sent: Thursday, November 03, 2005 5:06 PM
> > > > To: Andrew Lissitz (alissitz)
> > > > Cc: C&S GroupStudy; FORUM
> > > > Subject: Re: "neighbor allowas-in" command ( SP CCIE)
> > > >
> > > > When I wrote the below email, my stomach was a little empty :)
> > > >
> > > > Regarding my point 2) "advertize iBGP routes to iBGP peers (
> > > > normal behavior of iBGP is not to advertize iBGP routes to any
> > > > iBGP peers)",
> > > >
> > > > First, this thought is from CCO descprition "One Virtual Private
> > > > Network routing/forwarding instance (VRF) receives prefixes with
> > > > ASNs from all PE routers and then advertises them to neighboring
> > > > PE
> > > routers."
> > > >
> > > > I figured from the description that a PE receives a prefix with
> > > > its own ASN from PE router and advertize
> > > >
> > > > Let's say "neighbor allowas-in 1" in AS 100 in three PE's( pe1,
> > > > pe2, pe3).
> > > >
> > > > If via MP-BGP, PE1 and PE2 learn from PE3 a VPN route 10.0.0.0/24
> > > > with
> > >
> > > > as-path = null, I think PE1 will annouce back 10.0.0.0/24 with
> > > > as-path=100 to PE2 and PE3 as well as PE2 will do the same to PE1
> > > > and PE3, which is not normal iBGP behavior. But 10.0.0.0/24 with
> > > > AS-path 100 from PE1 and PE 2 can't beat 10.0.0.0/24 with as-path
> > > > null from
> > > PE3.
> > > >
> > > > But the interesting result is if PE2 is not importing 10.0.0.0/24
> > > > with
> > >
> > > > as-path=null from PE3, then PE2 will only have 10.0.0.0/24 with
> > > > as-path=100 from PE1.
> > > > This will achieve hub-and-spoke VPN topology ( PE1 = hub and PE2
> > > > and
> > > > PE3 = spokes)
> > > >
> > > > Please feel free to correct me if I am wrong.
> > > >
> > > > Jongsoo
> > > >
> > > > On 11/2/05, Andrew Lissitz (alissitz) <alissitz@cisco.com> wrote:
> > > > > Hey Buddy,
> > > > >
> > > > > Here is a live example, I have not done the hub and spoke labs
> > > > > like several others on this mail list have:
> > > > >
> > > > > CE ---bgp---PE ---(ISP Cloud)--- PE---bgp---CE
> > > > >
> > > > > Each CE runs AS 65000 and shares routes with the PE. The PEs
> > > > > share routes via iBGP. The remote PE shares routes with the
> > > > > remote CE, and the CE sees the routes from AS 65000.
> > > > >
> > > > > What is BGP to do? It sees its own AS number and realizes there
> > > > > is a problem.
> > > > >
> > > > > Solution: Either PE changes the AS number with as-override or
> > > > > the CE
> > >
> > > > > allows its own AS number to come in via the allowed-as command.
> > > > > The
> > >
> > > > > number @ the end is how many times the CE will allow it's own AS
> > > > > number to be present in the path string of the incoming route
> > > > information.
> > > > >
> > > > > Concerning your gut feelings (btw ... hope you are not writing
> > > > > on empty stomach), number one sounds good, but with number 2,
> > > > > you are essentially saying that this command will override bgp
> > > > > split
> > > horizon.
> > > >
> > > > > This is not what it will do, if a route is already coming in,
> > > > > and it
> > >
> > > > > contains the BGP's AS number in the path, then let this in. Not
> > > > > whether or not to advertise to other peers. I have not seen this
> > > > > command change BGP split horizon behavior ...
> > > > >
> > > > > BGP best path selection still occurs, it is just that the routes
> > > > > will not be rejected because of loop detection. I have not seen
> > > > > multiple routes being accepted as best paths... Can multiple
> > > > > routes exist without the BGP multipath command?
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com ] On
> > > > > Behalf
> > >
> > > > > Of Jongsoo
> > > > > Sent: Wednesday, November 02, 2005 7:33 PM
> > > > > To: C&S GroupStudy; FORUM
> > > > > Subject: "neighbor allowas-in" command ( SP CCIE)
> > > > >
> > > > > I am trying to understand this command will allow to receive
> > > > > MP-bgp vpn routes with the same ASN.
> > > > >
> > > > > If I see usage guide in CCO, it says
> > > > >
> > > > > ##################################
> > > > > Usage Guidelines
> > > > > In a hub and spoke configuration, a PE router readvertises all
> > > > > prefixes containing duplicate autonomous system numbers. Use the
> > > > > neighbor allowas-in command to configure two VRFs on each PE
> > > > > router to
> > > >
> > > > > receive and readvertise prefixes are as follows:
> > > > >
> > > > > One Virtual Private Network routing/forwarding instance (VRF)
> > > > > receives prefixes with ASNs from all PE routers and then
> > > > > advertises them to neighboring PE routers.
> > > > >
> > > > > The other VRF receives prefixes with ASNs from the customer
> > > > > edge
> > > > > (CE)
> > > >
> > > > > router and readvertises them to all PE routers in the hub and
> > > > > spoke configuration.
> > > > >
> > > > > You control the number of times an ASN is advertised by
> > > > > specifying a
> > >
> > > > > number from 1 to 10. "
> > > > > ################################################
> > > > >
> > > > > In my gut feeling, basically, this command seems allow two
> > > > > things,
> > > > > 1) receive BGP routes with its own ASN from PE or CE, ( normal
> > > > > behavior of BGP blocks BGP route with its own ASN in order to
> > > > > prevent loop) and
> > > > > 2) advertize iBGP routes to iBGP peers ( normal behavior of iBGP
> > > > > is not to advertize iBGP routes to any iBGP peers).
> > > > >
> > > > > What seems interesting is this feature will creates a lot of
> > > > > redundant
> > > >
> > > > > routes but the length of AS path will quickly determine the best
> > > > > routes so that there won't be any loop...
> > > > >
> > > > > This will be a perfect command to make hub and spoke topology to
> > > > work...
> > > > >
> > > > > The biggest question I have now is " am I right or wrong?".
> > > > > Someone please correct me if I am wrong.
> > > > >
> > > > > Thanks
> > > > >
> > > > >
> > > > > Jongsoo
> > > > >
> > > > >
> > ____________________________________________________________________
> > > > > __ _ Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> > ______________________________________________________________________
> > > > _ Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > ______________________________________________________________________
> > _
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:05 GMT-3