From: Jongsoo (bstrt2004@gmail.com)
Date: Wed Nov 09 2005 - 16:26:57 GMT-3
Andrew
Can you configure like any of below?
Int e1/0
Ip vrf forward up
ip route vrf down 192.2.2.2 255.255.255.255 e1/0 192.168.5.21
ip route vrf down 192.2.2.2 255.255.255.255 e1/0 192.168.5.21
Thanks
Jongsoo
On 11/9/05, Andrew Lissitz (alissitz) <alissitz@cisco.com> wrote:
> Ok wonderful group. Results of labbie ...
>
> PE2 (HUB) - VRF up sent default route to remote spoke PE3. These routes
> show up in the VRF UP routing table as the should.
>
> PE3 (Spoke) - static route does not show up in local VRF down routing
> table, and of course, is not sent to remote peers. This is because I
> was trying to route vrf down to a interface that was configured for VRF
> UP forwarding.
>
> On PE3 (Spoke):
>
> Int e1/0
> Ip vrf forward up
>
> ip route vrf down 192.2.2.2 255.255.255.255 192.168.5.21 (CE off of the
> int e1/0 interface)
>
> The router basically says .. "you want me to route what? I can not
> route that ... The destination next hop address is not local and does
> not exist in the down VRF" The PE does not accept this route and so it
> is never imported into BGP via the scanner process.
>
> Each interface can only belong to one VRF. So, how will we get the
> routes from VRF down to be sent to the hub router? We can import and
> export locally via route-targets ... there are more options left for us
> to keep playing with this, however it is east coast time and I am tired
> ...
>
> Jongsoo, let me know what you think and find.
>
> To all; have a great night,
>
> Andrew
>
>
>
> -----Original Message-----
> From: Andrew Lissitz (alissitz)
> Sent: Tuesday, November 08, 2005 10:19 PM
> To: Andrew Lissitz (alissitz); Jongsoo
> Cc: swm@emanon.com; C&S GroupStudy; FORUM
> Subject: RE: We've moved to PE-CE routing! (SP-CCIE)
>
>
> I have not labbed this yet ... Just a couple of thoughts. I also had to
> look some of these comments up, so thanks for your post and homework for
> me ;-)
>
> Jongsoo, you are configuring two VRFs so that you can control route
> updates right? You are using the down VRFs to pass routing information
> between PEs?
>
> I think my confusion comes because you can do everything you want with
> only one VRF on each PE. You can always filter bgp route updates or use
> import maps on the VRFs... import maps are something you should
> practice.
>
> Each RD value for each VRF has to be unique for the entire vpn network.
> Each VRF instance needs to have a unique RD.
>
> Route targets are extended bgp communities, and must be the same on PE
> VRFS in order for routes to be imported into a VRF. The RD does not
> decide which routes come in, it is the route target. It is not the name
> of the VRF, it is the route-target.
>
> A gotcha - if a PE does not have any route-targets set for import in any
> VRF, then this PE will drop the BGP vpnv4 updates that contain this
> route-target. The PE says "why should I accept these routes, I do not
> have any VRFs that need these routes".
>
> This filtering is automatic, but can be disabled. RRs automatically
> disable this filtering since they typically do not have any VRFs defined
> on them, yet RRs need to accept all routes.
>
> So Jongsoo, in your config below, in order for the hub or spoke PEs to
> accept these routes, the VRFs used by the PEs must be importing or
> exporting these route-targets to the VRF with the same route-target. Of
> course once you labbed this up, you would have seen that there was a
> problem with the routing. This is no biggie, although a good problem to
> run into
>
> I will play around with something similar to what you have written below
> ... will provide more info later tonight. Kindest regards all, and
> thanks Jongsoo for posting such interesting questions / scenarios
>
> Andrew
>
>
>
>
>
> -----Original Message-----
> From: Jongsoo [mailto:bstrt2004@gmail.com]
> Sent: Tuesday, November 08, 2005 9:05 PM
> To: Andrew Lissitz (alissitz)
> Cc: swm@emanon.com; C&S GroupStudy; FORUM
> Subject: Re: We've moved to PE-CE routing! (SP-CCIE)
>
> Andrew
>
> I was wondering if in yoru lab, you could config inter-VRF static route
> between VRF's ( not global).
>
> Here is the config that I have in mind but is not labbed yet.
> (This will require an inter-VRF static routing, which I am not 100% sure
> of .)
>
> ##### pre-condition ######
>
> Hub
>
> CE1 .2-- 10.1.1.0--.1 f1 PE1
> CE2 .2-- 10.2.2.0--.1 f2 PE2
> CE3 .3-- 10.3.3.0--.1 f3 PE3
>
> CE2 has 2.0.0.0/8 network
> CE3 has 3.0.0.0/8 network
>
> CE1 has a static route for 2.0.0.0/8 and 3.0.0.0/8 to PE1
> CE2 and CE3 has a default route to PE2 and PE3 respectively
>
> Baiscally, each PE has two uni-direction VRFs but only one VRF has the
> interface between PE and CE and the other VRF has just static route(
> Inter VRF)
>
> ######## PE1 Hub ###########
> ip vrf up
> rd 100:1
> route-target export 100:1
>
> ip vrf down
> rd 100:2
> route-target import 100:1
>
> int f1
> ip address 10.1.1.1 255.255.255.0
> ip vrf forwarding down
>
> ip route vrf up 0.0.0.0 0.0.0.0 f1 10.1.1.2 ( defaut inter vrf route
> from vrf up to vrf down toward CE1)
>
> router bgp 100
> neighbor PE2, PE3 remote-as 100
> neighbor PE2, PE3 route-reflector-client
>
> address-family vpnv4
> neighbor PE2, PE3 activate
> neighbor PE2, PE3 send-community extended neighbor PE2, PE3
> route-reflector-client
>
> address-family ipv4 vrf up
> redistribute static
>
> address-family ipv4 vrf down
>
>
> ######## PE2 spoke ###########
>
> ip vrf up
> rd 100:1
> route-target import 100:2
>
> ip vrf down
> rd 100:2
> route-target export 100:2
>
> int f2
> ip address 10.2.2.1 255.255.255.0
> ip vrf forwarding up
>
> ip route vrf down 2.0.0.0 255.0.0.0 f2 10.2.2.2 ( static inter vrf route
> from vrf down to vrf up toward CE2 for 2.0.0.0/8)
>
> router bgp 100
> neighbor PE1 remote-as 100
>
>
> address-family vpnv4
> neighbor PE1 activate
> neighbor PE1 send-community extended
>
> address-family ipv4 vrf down
> redistribute static
>
> address-family ipv4 vrf up
>
>
> ######## PE3 spoke ###########
> ip vrf up
> rd 100:1
> route-target import 100:2
>
> ip vrf down
> rd 100:2
> route-target export 100:2
>
> int f3
> ip address 10.3.3.1 255.255.255.0
> ip vrf forwarding up
>
> ip route vrf down 3.0.0.0 255.0.0.0 f3 10.3.3.2 ( static inter vrf route
> from vrf down to vrf up toward CE3 for 3.0.0.0/8)
>
> router bgp 100
> neighbor PE1 remote-as 100
>
> address-family vpnv4
> neighbor PE1 activate
> neighbor PE1 send-community extended
>
> address-family ipv4 vrf down
> redistribute static
>
> address-family ipv4 vrf up
>
> -------------end of config----------------
>
> Jongsoo
>
>
>
>
> On 11/8/05, Andrew Lissitz (alissitz) <alissitz@cisco.com> wrote:
> > 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
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:06 GMT-3