From: Joseph Brunner (joe@affirmedsystems.com)
Date: Tue Nov 11 2008 - 20:25:48 ARST
Im trying to understand the use of the tunnels, please correct me if
IM wrong in what I understood with the above configuration.
1. As for the Ip addressing assigned to the two tunnels, the tunnel is
established between the global table as one endpoint and the vrf table
as another endpoint?
JB>That is correct...
2. The tunnel interfaces are used to route traffic? or used only to
leak the routes?
JB>The tunnel is used to both route traffic and leak the routes; the router
Actually becomes an ospf neighbor with itself, but the two ospf processes
are in different vrf's. I made this config myself for the first time a few
weeks ago to solve the issue of global routing table and vrf sharing routes,
interfaces for an isp that is migrating its "edge routers" to PE's. they
have some interfaces on the PE's in their management and monitoring vlans.
I have heard people use a cable between two interfaces on the same router
for this purpose, or link two vlan sub-interfaces, but I thought a tunnel
would be cleaner, as it has no external dependencies to work.
You can use static routes in the global routing table out interfaces which
are in the vrf's;
Ip route 192.168.7.0 255.255.255.0 serial1/0 192.168.1.2
You will most likely also have this configured as well in the vrf routing
table
Ip route vrf chd 192.168.7.0 255.255.255.0 192.168.1.2 (note the interface
is not needed here)
Just keep in mind the tunnel does have some overhead in the fast switch
path; the tunnel to tunnel config for bridging the global and vrf routing
tables is not an ultra high bandwidth solution.
I really hesitated for a while making the global routing table and
associated interfaces a "backbone" vrf, as integration between the two is
implied with simple route-targets configured under the vrf's. but alas, this
tunnel method worked too well to deal with that complexiting
Thanks in advance, and men!! y forgot to tell you and the the group I
conquered my number last august!
JB>Well belated congratulations!!! Well done... I thought I missed that
email when I saw the number ;)
2008/11/11 Joseph Brunner <joe@affirmedsystems.com>:
> Sure here is how I have been doing it;
>
> Two tunnels, same router, same subnet, sourced from different loopbacks.
>
> One tunnel interface in the vrf, one in the global routing table
>
> ip vrf chd
> rd 8818:100
> route-target export 17303:100
> route-target import 17303:100
>
> interface Tunnel100
> description VRF_CHD_BRIDGE_TO_GLOBAL_ROUTING_TABLE
> bandwidth 50000
> ip vrf forwarding chd
> ip address 172.23.254.254 255.255.255.252
> load-interval 30
> tunnel source Loopback0
> tunnel destination 172.24.1.1
> !
> interface Tunnel200
> description GLOBAL_ROUTING_TABLE_BRIDGE_TO_VRF_CHD
> bandwidth 50000
> ip address 172.23.254.253 255.255.255.252
> ip virtual-reassembly
> load-interval 30
> tunnel source Loopback100
> tunnel destination 71.21.188.105
>
>
> router ospf 100 vrf chd
> router-id 172.24.254.254
> log-adjacency-changes
> area 1 filter-list prefix filter-from-backbone-ospf in
> redistribute static subnets route-map static-vrf-chd-redis-to-ospf-100
> redistribute bgp 8818 subnets route-map redis-bgp-vrf-chd-to-ospf
> network 71.21.188.153 0.0.0.0 area 1
> network 71.21.188.185 0.0.0.0 area 1
> network 172.23.254.254 0.0.0.0 area 0
> network 192.168.40.1 0.0.0.0 area 1
> network 192.168.100.105 0.0.0.0 area 1
> default-information originate always
> !
> router ospf 1
> router-id 172.24.1.1
> log-adjacency-changes
> passive-interface default
> no passive-interface Serial1/0
> no passive-interface Tunnel32
> no passive-interface Tunnel40
> no passive-interface Tunnel50
> no passive-interface Tunnel51
> no passive-interface Tunnel200
> network 71.21.26.58 0.0.0.0 area 0
> network 71.21.188.105 0.0.0.0 area 0
> network 172.23.1.1 0.0.0.0 area 0
> network 172.23.1.9 0.0.0.0 area 0
> network 172.23.1.13 0.0.0.0 area 0
> network 172.23.254.253 0.0.0.0 area 0
> network 172.24.1.1 0.0.0.0 area 0
> network 192.168.30.1 0.0.0.0 area 0
> network 67.80..173.75 0.0.0.0 area 0
>
> router bgp 8818
> bgp router-id 71.21.188.105
> bgp log-neighbor-changes
> neighbor 71.21.26.57 remote-as 4323
> neighbor 172.24.1.2 remote-as 8818
> neighbor 172.24.1.2 update-source Loopback100
> neighbor 67.80..173.73 remote-as 29838
> !
> address-family ipv4
> neighbor 71.21.26.57 activate
> neighbor 71.21.26.57 weight 300
> neighbor 71.21.26.57 route-map to-twtc out
> neighbor 172.24.1.2 activate
> neighbor 172.24.1.2 route-map localasonly out
> neighbor 67.80.173.73 activate
> neighbor 67.80.173.73 weight 200
> neighbor 67.80.173.73 route-map to-atantic-metro-ny out
> no auto-summary
> no synchronization
> network 71.21.188.0 mask 255.255.255.0
> network 172.24.1.1 mask 255.255.255.255
> exit-address-family
> !
> address-family vpnv4
> neighbor 172.24.1.2 activate
> neighbor 172.24.1.2 send-community both
> exit-address-family
> !
> address-family ipv4 vrf chd
> redistribute ospf 100 vrf chd route-map ospf-to-bgp-vrf-100
> no synchronization
> exit-address-family
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Carlos Trujillo
> Sent: Tuesday, November 11, 2008 2:05 PM
> To: ccielab@groupstudy.com
> Subject: route leaking from global to vrf when there is no VRF interfaces.
>
> HI group.
>
> Im having a simple MPLS VPN scenario between PE4s:
>
>
> [CE]-----[PE1]----[P]-----[PE(BORDER)]------[ISP1]
>
>
> I give a brief description about the topology shown:
>
> There is an MP-IBGP peering between PE1 and PE(BORDER).
> PE1 has its CE interface associated to CLIENT VRF, and PE(BORDER) has
> all of its interfaces associated to the global routing table.
> PE(BORDER) also has the VRF created but none interface attached to the
> vrf, so It can see the routes sourced from CE.
>
> What I want is to give CE routing connectivity to ISP1 (internet), so
> the data path a packet takes when it leaves CE router it
> follows PE1, then it travels in the MPLS VPN to PE(BORDER) and then I
> leak that route from the VPN to the global table using static
> routes, and then the packet succesfully enters the ISP router, so at
> this point its working OK.
>
> For the return packet I cant make the packet who comes from an
> interface of the global table to enter the VRF TABLE (vpn) and travels
> via the VPN to PE1.
>
>
> I saw two examples found in cisco.com showing how to leak from VRF TO
> global and from global to VRF, and in both cases it uses static routes
> pointing
> to an outbound interface and a next hop, but my scenario is different
> to them in that PE(BORDER) router has all of its interfaces attached
> to the global
> routing table, and If I create a static route, to what outbound
> interface do I point to? if all of its interfaces belong to the global
> routing table.
>
>
> Please If any have an idea how to let it work?
>
>
> Thanks.
> # 21813 R&S
>
>
> 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
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:30 ARST