Re: VRF TO GLOBAL PROBLEM

I got hooked with this thing. And I learned a couple of things about
EEM's new (3.0) routing event detector.

Even though VRF is not exposed, the event detector does detect changes
in VRF route tables! That can then be used to provide VRF to global
route leaking.

A small test app to get started:

event manager applet test
  event routing network 0.0.0.0/0 le 32
  action 1.0 puts "Route $_routing_network $_routing_protocol
$_routing_type $_routing_lastinterface"
  action 1.1 cli command "show ip int $_routing_lastinterface | e
Downstream"
  action 1.2 set vrf "global"
  action 1.3 regexp "VPN Routing/Forwarding "(.*)"" "$_cli_result"
result vrf
  action 1.4 puts "VRF $vrf"

and its output:

R2#
*Jan 11 11:28:23.963: %HA_EM-6-LOG: test: Route 10.0.0.6 routing OSPF
add Serial1/0.206
*Jan 11 11:28:24.111: %HA_EM-6-LOG: test: VRF blue
*Jan 11 11:28:47.431: %HA_EM-6-LOG: test: Route 10.0.0.5 routing OSPF
remove Serial1/0.205
*Jan 11 11:28:47.631: %HA_EM-6-LOG: test: VRF red
*Jan 11 11:30:04.027: %HA_EM-6-LOG: test: Route 192.168.0.4 routing BGP
remove Serial1/0.204
*Jan 11 11:30:04.195: %HA_EM-6-LOG: test: VRF global

-Carlos

swap m @ 11/01/2011 05:29 -0300 dixit:
> using a cable loop is also a possible dirty hack for such Global/VRF
> leakage, one end of cable in VRF port and other end in Global ;)
>
> Swap
> #19804
>
> On Fri, Jan 7, 2011 at 6:08 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
>> Cool.
>> I've read about this hack, and it has its ups and downs.
>> On the up side, it's "standard" config, works, and you have an interface
>> (or two) where you can actualy set a policy (ACL, QoS, you name it).
>> On the down side, you have MTU issues, and sounds like a waste of
>> switching for a missing control feature.
>>
>> Has anybody tried to do the hack on the control plane ? It should be doable
>> with TCL, like a runner checking the vrf for a set (prefix list,
>> route map) of routes and setting statics, dynamically.
>>
>> Thoughts ?
>> -Carlos
>>
>> Joseph L. Brunner @ 07/01/2011 08:22 -0300 dixit:
>>> I get 80Mbps between those 2 with very low cpu overhead.
>>>
>>> -----Original Message-----
>>> From: Damian Higgins [mailto:linnewbye_at_gmail.com] Sent: Friday, January
>>> 07, 2011 4:01 AM
>>> To: Joseph L. Brunner
>>> Cc: Carlos G Mendioroz; Marko Milivojevic; Marcin Zgola; Cisco
>>> certification
>>> Subject: Re: VRF TO GLOBAL PROBLEM
>>>
>>> Hi Joseph,
>>>
>>> I've read about using tunnels to bridge between global and VRF before
>>> but I thought this is not a reliable solution for production because
>>> of the perfomance impact. How much traffic do you actually bridge
>>> between global and VRF and what routers do you use ? What about GRE
>>> overhead and MTU ? I know the 6500's have a fixed MTU of 1514 on
>>> loopbacks.
>>>
>>>
>>> On Thu, Jan 6, 2011 at 10:47 PM, Joseph L. Brunner
>>> <joe_at_affirmedsystems.com> wrote:
>>>> How about dynamic
>>>>> leaking from VRFs to global ( no static routes in global ), is it
>>>>> possible ?
>>>> Yes, for that we do
>>>>
>>>> I'm sure you can figure out how this works (from an real large ISP
>>>> backbone router, scales to hundreds of customers per router, ip's changed)
>>>>
>>>>
>>>> ip vrf abc
>>>> rd 9999:100
>>>> route-target export 9999:100
>>>> route-target import 9999:100
>>>>
>>>> interface Tunnel100
>>>> description VRF_ABC_BRIDGE_TO_GLOBAL_ROUTING_TABLE
>>>> bandwidth 50000
>>>> ip vrf forwarding abc
>>>> 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_ABC
>>>> bandwidth 50000
>>>> ip address 172.23.254.253 255.255.255.252
>>>> ip virtual-reassembly
>>>> load-interval 30
>>>> tunnel source Loopback100
>>>> tunnel destination 96.110.188.105
>>>>
>>>>
>>>> then...
>>>>
>>>> router ospf 100 vrf abc
>>>> router-id 172.24.254.254
>>>> log-adjacency-changes
>>>> redistribute static subnets route-map static-vrf-abc-redis-to-ospf-100
>>>> redistribute bgp 17303 subnets route-map redis-bgp-vrf-abc-to-ospf
>>>> network 96.110.188.153 0.0.0.0 area 1
>>>> network 96.110.188.185 0.0.0.0 area 1
>>>> network 96.110.188.245 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
>>>>
>>>>
>>>> router bgp 9999
>>>>
>>>> address-family ipv4 vrf abc
>>>> redistribute static route-map static-to-bgp-vrf-100
>>>> redistribute ospf 100 vrf abc route-map ospf-to-bgp-vrf-100
>>>> no synchronization
>>>> exit-address-family
>>>>
>>>> -----Original Message-----
>>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>>>> Carlos G Mendioroz
>>>> Sent: Thursday, January 06, 2011 2:37 PM
>>>> To: Damian Higgins
>>>> Cc: Marko Milivojevic; Marcin Zgola; Cisco certification
>>>> Subject: Re: VRF TO GLOBAL PROBLEM
>>>>
>>>> Does not seem to be doable for the time being.
>>>> There are some hacks using tunnels, but nothing clean.
>>>> This sure is the reason for your using all VRF and no global :)
>>>>
>>>> -Carlos
>>>>
>>>> Damian Higgins @ 06/01/2011 15:05 -0300 dixit:
>>>>> I didn't read the article carefully, I just did a lab ( using
>>>>> fastethernet interfaces ) and it does work :). How about dynamic
>>>>> leaking from VRFs to global ( no static routes in global ), is it
>>>>> possible ?
>>>>>
>>>>>
>>>>> On Thu, Jan 6, 2011 at 5:57 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
>>>>> wrote:
>>>>>> Damian,
>>>>>> I've just changed Marko's sample to leak R2-R4 (192.168.24.0/24,
>>>>>> global)
>>>>>> into vrf red and R2-R5 (10.0.25.0/24, vrf red) into global and it
>>>>>> works.
>>>>>>
>>>>>> @ R2, just:
>>>>>>
>>>>>> ip prefix-list R4-Loopback0 seq 20 permit 192.168.24.0/24
>>>>>>
>>>>>> (should have changed the list name :)
>>>>>> and red knows the R2-R4.
>>>>>>
>>>>>> ip route 10.0.25.0 255.255.255.0 Serial1/0.205
>>>>>>
>>>>>> and R2 knows R2-R5 at global.
>>>>>>
>>>>>> BTW, the sample uses point to point, so AFAIK there is no need to set
>>>>>> next
>>>>>> hops, no need for the global for vrf statics if used.
>>>>>>
>>>>>> I can ping from R5 to R2's serial w/o going through R4. That's what is
>>>>>> being
>>>>>> looked for, right ?
>>>>>>
>>>>>> Marcin,
>>>>>> would you post relevant config ?
>>>>>> -Carlos
>>>>>>
>>>>>> Damian Higgins @ 06/01/2011 07:22 -0300 dixit:
>>>>>>> Hi Marko,
>>>>>>>
>>>>>>> That's because in your example you needed reachability only between
>>>>>>> the router's loopbacks. Let's say that R2-R6 10.0.26.0/24 is in global
>>>>>>> and R2-R5 10.0.25.0/24 is into a VRF and you need to have reachability
>>>>>>> between these two subnets. Can you give an example routing between
>>>>>>> these two without having to use R4 ?
>>>>>>>
>>>>>>> Regards.
>>>>>>>
>>>>>>> On Thu, Jan 6, 2011 at 11:06 AM, Marko Milivojevic
>>>>>>> <markom_at_ipexpert.com>
>>>>>>> wrote:
>>>>>>>> Please, re-read the article :-). It shows the example of leaking
>>>>>>>> between global table and VRF using BGP - no next hops involved. I had
>>>>>>>> to build to that point though.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Marko Milivojevic - CCIE #18427
>>>>>>>> Senior Technical Instructor - IPexpert
>>>>>>>>
>>>>>>>> FREE CCIE training: http://bit.ly/vLecture
>>>>>>>>
>>>>>>>> Mailto: markom_at_ipexpert.com
>>>>>>>> Telephone: +1.810.326.1444
>>>>>>>> Web: http://www.ipexpert.com/
>>>>>>>>
>>>>>>>> On Thu, Jan 6, 2011 at 12:14, Damian Higgins <linnewbye_at_gmail.com>
>>>>>>>> wrote:
>>>>>>>>> I don't think your example will help Marcin, you used next-hops, so
>>>>>>>>> you depend on the upstream router to route between global and VRFs.
>>>>>>>>> You can have bidirectional route leaking without next-hops only
>>>>>>>>> between VRFs ( using MP-BGP ) on the same box, but not between
>>>>>>>>> global
>>>>>>>>> and a VRF. Although in global you can add directly connected routes
>>>>>>>>> (
>>>>>>>>> using exit interface instead of next-hop ) into a VRF, the other way
>>>>>>>>> around doesn't work since you need to specify a next-hop. This is a
>>>>>>>>> very annoying limitation :(.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @Marcin, to avoid this limitation I'm using only VRFs for routing on
>>>>>>>>> my 6500's, and I use the global table only for management in case
>>>>>>>>> something goes wrong in the VRFs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jan 6, 2011 at 7:59 AM, Marko Milivojevic
>>>>>>>>> <markom_at_ipexpert.com>
>>>>>>>>> wrote:
>>>>>>>>>> Marcin,
>>>>>>>>>>
>>>>>>>>>> I wrote the blog on the subject of the route leaking between VRF
>>>>>>>>>> and
>>>>>>>>>> the main table sometime ago. I think you will find the solution
>>>>>>>>>> there:
>>>>>>>>>>
>>>>>>>>>> http://blog.ipexpert.com/2010/12/01/vrf-route-leaking/
>>>>>>>>>>
>>>>>>>>>> Short answer to your last question: yes :-)
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Marko Milivojevic - CCIE #18427
>>>>>>>>>> Senior Technical Instructor - IPexpert
>>>>>>>>>>
>>>>>>>>>> FREE CCIE training: http://bit.ly/vLecture
>>>>>>>>>>
>>>>>>>>>> Mailto: markom_at_ipexpert.com
>>>>>>>>>> Telephone: +1.810.326.1444
>>>>>>>>>> Web: http://www.ipexpert.com/
>>>>>>>>>>
>>>>>>>>>> On Thu, Jan 6, 2011 at 06:03, Marcin Zgola <MZgola_at_netrixllc.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Problem, I want to be able to communicate between VRF and global
>>>>>>>>>>> on
>>>>>>>>>>> the same router.
>>>>>>>>>>>
>>>>>>>>>>> I can leak routes but I need to specify next hop to be another
>>>>>>>>>>> router.
>>>>>>>>>>>
>>>>>>>>>>> Basically packet hits the router on VRF interface, and then it
>>>>>>>>>>> sends
>>>>>>>>>>> it to upstream router, and upstream router sends it back.
>>>>>>>>>>>
>>>>>>>>>>> Can this be avoided?????
>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________________________________
>>>>>>> Subscription information may be found at:
>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>>>>
>>>> --
>>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>>
>>>>
>>>> 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
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>
>>
>> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net