From: Andrew Lissitz \(alissitz\) (alissitz@cisco.com)
Date: Tue Nov 08 2005 - 02:26:59 GMT-3
No pretty, although it works. I only used two routers in my lab (lab
not yet complete), here is what I got:
Spoke CE3:192.3.3.3 (static default to PE3) -- Spoke PE3 (static vrf
route to get to CE2)
Hub PE2 (static route to VRF interface) --- Hub CE 2:192.2.2.2 (Static
default to PE2)
Challenges:
When you remove a route-target import statement on a PE (for
uni-directional VRF), the default behavior of BGP is to not allow any
routes for that VRF's route-target inbound. This is what we want, since
we removed the import statement on the spoke PE. Now how should this
spoke PE, route VRF traffic now? The answer is statically, since we do
not have any dynamic protocols inbound.
On the CE3:192.3.3.3 router:
ip route 0.0.0.0 0.0.0.0 x.x.x.x (PE3) --> spoke CE device defaults to
spoke PE
On the PE3 router:-
Ip route vrf xyz 192.2.2.2 255.255.255.255 x.x.x.x global (x.x.x.x =
PE2 ibgp next hop)
--> need to tell PE3 to reference the global table to find this next
hop. The reason I had to put a global next hop address for PE2, is
because the local VRF does not import any routes from the remote PE...
normally you would see a iBGP route with the iBGP next hop of PE2 for
VRF routes found on PE2.
Without this iBGP route for the remote PE, how then will this PE3 know
to reach the far side PE2 router for this destination VRF? The answer
is to configure it statically since we are not importing any dynamic
routes into this VRF.
From PE3's perspective, the only known next hop for PE2 is a global one
(nothing in VRF route table). This is how we will send traffic to the
far side PE router.
ON CE2:192.2.2.2 router:
ip route 0.0.0.0 0.0.0.0 x.x.x.x (PE2)
On the PE2 router:
Since previously we had configured static routing on the hub PE router,
there is nothing more to do within the VRF. The PE2 router is importing
route information for the remote PEs still, and knows how to route back
to them. This means there is nothing to do for return traffic.
However, this traffic from the remote spoke PEs is coming in to a global
destination (PE2 iBGP address) and needs to routed to a VRF interface.
On PE2:
ip route 192.2.2.2 255.255.255.255 eth 2/0 --> ethe 2/0 is the vrf
interface that leads to CE2
This is probably the most tricky aspect of this solution. If anyone
configured this in a different manner, please share. This was how I got
this to work.
***** end of lab *****
An easier method would be to use iBGP as usual, and continue to import
routes to remote spoke PEs. Create static default @ hub, redist into
PE2 iBGP vrf configs, and share routes normally. The remotes will get
this default pointing to hub router.
I labbed this up as well, it works ... And with a lot less concern.
-----Original Message-----
From: Jongsoo [mailto:bstrt2004@gmail.com]
Sent: Monday, November 07, 2005 7:48 PM
To: swm@emanon.com
Cc: Andrew Lissitz (alissitz); C&S GroupStudy; FORUM
Subject: Re: We've moved to PE-CE routing! (SP-CCIE)
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