From: Jongsoo (bstrt2004@gmail.com)
Date: Wed Nov 09 2005 - 23:20:08 GMT-3
I finally managed to borrow a router from my co-worker but didn't
support MPLS !!! :(
But I was able to confiure VRF and do some validation test. :)
It seems I can do "inter-vrf static route" between two non-global-VRFs
If you see below routing table of two VRF, you will see "down" has
connected and "up" has static route. And this static route is between
VRF up and down.
interface Ethernet0/0
ip vrf forwarding down
ip address 10.1.1.1 255.255.255.0
"ip route vrf up 0.0.0.0 0.0.0.0 Ethernet0/0 10.1.1.2 "
HUB_PE#show ip route vrf up
Routing Table: up
Gateway of last resort is not set
S 0.0.0.0/8 [1/0] via 10.1.1.2, Ethernet0/0
HUB_PE#show ip route vrf down
Routing Table: down
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Ethernet0/0
If I do ping vrf up 2.2.2.2, the packet obviously went out via E0/0.
But interesting tings is as the route doesn't have any interface under
VRF up, it uses 10.1.1.1, which is interface under VRF down.
Mar 1 01:44:07.823: IP: tableid=2, s=0.0.0.0 (local), d=2.2.2.2 (Ethernet0/0),
routed via RIB
*Mar 1 01:44:07.823: IP: s=10.1.1.1 (local), d=2.2.2.2 (Ethernet0/0), len 100,
sending
*Mar 1 01:44:07.823: IP: s=10.1.1.1 (local), d=2.2.2.2 (Ethernet0/0), len 100,
encapsulation failed.
If I configure a loopback interface under VRF up, it becomes the source address.
!
interface Loopback0
ip vrf forwarding up
ip address 3.3.3.3 255.0.0.0
HUB_PE#show ip vrf up
Name Default RD Interfaces
up 200:1 Loopback0
HUB_PE#show ip route vrf up
Routing Table: up
C 3.0.0.0/8 is directly connected, Loopback0
S* 0.0.0.0/0 [1/0] via 10.1.1.2, Ethernet0/0
HUB_PE#ping vrf up 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
*Mar 1 01:51:07.563: IP: tableid=2, s=3.3.3.3 (local), d=2.2.2.2 (Ethernet0/0),
routed via RIB
*Mar 1 01:51:07.563: IP: s=3.3.3.3 (local), d=2.2.2.2 (Ethernet0/0), len 100, s
ending
*Mar 1 01:51:07.567: IP: s=3.3.3.3 (local), d=2.2.2.2 (Ethernet0/0), len 100, e
ncapsulation failed.
I don't know why encapsulation failed???
Here is config without loopback 0 interface.
###########################
hostname HUB_PE
!
ip vrf down
rd 100:1
route-target export 100:1
route-target import 100:1
ip vrf up
rd 200:1
route-target export 200:1
route-target import 200:1
!
ip cef
!
interface Ethernet0/0
ip vrf forwarding down
ip address 10.1.1.1 255.255.255.0
half-duplex
no clns route-cache
ip route vrf up 0.0.0.0 0.0.0.0 Ethernet0/0 10.1.1.2
!
end
HUB_PE#show ip vrf
Name Default RD Interfaces
down 100:1 Ethernet0/0
up 200:1
HUB_PE#show ip route vrf up
Routing Table: up
Gateway of last resort is not set
S 0.0.0.0/8 [1/0] via 10.1.1.2, Ethernet0/0
HUB_PE#show ip route vrf down
Routing Table: down
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Ethernet0/0
HUB_PE#ping vrf up 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
*Mar 1 01:44:07.823: IP: tableid=2, s=0.0.0.0 (local), d=2.2.2.2 (Ethernet0/0),
routed via RIB
*Mar 1 01:44:07.823: IP: s=10.1.1.1 (local), d=2.2.2.2 (Ethernet0/0), len 100,
sending
*Mar 1 01:44:07.823: IP: s=10.1.1.1 (local), d=2.2.2.2 (Ethernet0/0), len 100,
encapsulation failed.
*Mar 1 01:44:09.819: IP: tableid=2, s=0.0.0.0 (local), d=2.2.2.2 (Ethernet0/0),
routed via RIB
*Mar 1 01:44:09.819: IP: s=10.1.1.1 (local), d=2.2.2.2 (Ethernet0/0), len 100,
sending
*Mar 1 01:44:09.819: IP: s=10.1.1.1 (local), d=2.2.2.2 (Ethernet0/0), len 100,
encapsulation failed.
*Mar 1 01:44:11.819: IP: tableid=2, s=0.0.0.0 (local), d=2.2.2.2 (Ethernet0/0),
routed via RIB
*Mar 1 01:44:11.819: IP: s=10.1.1.1 (local), d=2.2.2.2 (Ethernet0/0), len 100,
sending
*Mar 1 01:44:11.819: IP: s=10.1.1.1 (local), d=2.2.2.2 (Ethernet0/0), len 100,
encapsulation failed.
On 11/9/05, Jongsoo <bstrt2004@gmail.com> wrote:
> 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