leaking into a VRF from inet.0?

In the lab,  I've found that I can get  specific BGP routes
into inet. 
0 from a VRF using rib-groups and auto-export to create a
granular  
"leak policy". Works great.

Is it possible to do the converse - leak selected BGP routes
from  
inet.0 into a VRF?  I've had no luck so far.

-dd


_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi Dave,

 Just configure another rib-group on the opposite direction
(with
keeping in mind that you need 'direct' routes for next-hop
availability) and you should be fine.

 For example:

routing-options {
 rib-groups {
        Vrf_X-to-inet-default {
            import-rib [ Vrf_X.inet.0 inet.0 ];
            import-policy some-policy-here;
        }
        inet-default-to-Vrf_X {
            import-rib [ inet.0 Vrf_X.inet.0 ];
            import-policy some-other-policy;
}

 Cheers,
 Erdem

On 4/16/07, Dave Diller <davemaxgigapop.net> wrote:
> In the lab,  I've found that I can get  specific BGP
routes into inet.
> 0 from a VRF using rib-groups and auto-export to create
a granular
> "leak policy". Works great.
>
> Is it possible to do the converse - leak selected BGP
routes from
> inet.0 into a VRF?  I've had no luck so far.
>
> -dd
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsppuck.nether.net
> 
https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

Well, that was quick.  Nope, not supported:

[edit routing-instances TEST routing-options]
   'instance-import'
     instance-import not allowed on VPN instance
error: configuration check-out failed

Ah well, worth a shot.  Back to playing with rib-groups 

-dd


> In all honesty, I have only done this with
non-forwarding  
> instances, so you should probably test this thoroughly
with VRFs.
>
> Nick
> On Apr 16, 2007, at 7:32 PM, Dave Diller wrote:
>
>> Hmm, I can use that with VRF instances?  I skipped
that section of  
>> the doc as it was referring to nonforwarding
instances.  I'm not  
>> sure how those differ from a VRF, but hadn't played
with that  
>> particular type at all.
>>
>> I'll play with it tomorrow 
>>
>> -dd
>>
>>
>> On Apr 16, 2007, at 6:28 PM, Nick Slabakov wrote:
>>
>>> Dave,
>>>
>>> On the odd chance you don't like RIB-groups
 you
may want to  
>>> try another mechanism, which does not use them
- it is policy- 
>>> based export between routing instances:  http://tinyurl.com/35xtrk
>>>
>>> When you reference inet.0 you need to use the
keyword "master".   
>>> Using this method you can export routes between
the master  
>>> instance and a VRF, bi-directionally.
>>>
>>> Nick
>>> On Apr 16, 2007, at 1:53 PM, Dave Diller
wrote:
>>>
>>>> In the lab,  I've found that I can get 
specific BGP routes into  
>>>> inet.
>>>> 0 from a VRF using rib-groups and
auto-export to create a granular
>>>> "leak policy". Works great.
>>>>
>>>> Is it possible to do the converse - leak
selected BGP routes from
>>>> inet.0 into a VRF?  I've had no luck so
far.
>>>>
>>>> -dd
>>>>
>>>>
>>>>
_______________________________________________
>>>> juniper-nsp mailing list juniper-nsppuck.nether.net
>>>> 
https://puck.nether.net/mailman/listinfo/juniper-nsp
>>

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

Unfortunately the only way I have been able to make this
work is with rib groups....here is what I did to put all the
direct interfaces into my VRF.

}
routing-options {
    interface-routes {
        rib-group inet interface-routes;
    }
    rib-groups {
        interface-routes {
            import-rib [ inet.0 vrf.inet.0 ];
        }
    }


Andy  



-----Original Message-----
From: juniper-nsp-bouncespuck.nether.net on behalf
of Dave Diller
Sent: Tue 4/17/2007 7:37 AM
To: Nick Slabakov
Cc: juniper-nsppuck.nether.net
Subject: Re: [j-nsp] leaking into a VRF from inet.0?
 
Well, that was quick.  Nope, not supported:

[edit routing-instances TEST routing-options]
   'instance-import'
     instance-import not allowed on VPN instance
error: configuration check-out failed

Ah well, worth a shot.  Back to playing with rib-groups 

-dd


> In all honesty, I have only done this with
non-forwarding  
> instances, so you should probably test this thoroughly
with VRFs.
>
> Nick
> On Apr 16, 2007, at 7:32 PM, Dave Diller wrote:
>
>> Hmm, I can use that with VRF instances?  I skipped
that section of  
>> the doc as it was referring to nonforwarding
instances.  I'm not  
>> sure how those differ from a VRF, but hadn't played
with that  
>> particular type at all.
>>
>> I'll play with it tomorrow 
>>
>> -dd
>>
>>
>> On Apr 16, 2007, at 6:28 PM, Nick Slabakov wrote:
>>
>>> Dave,
>>>
>>> On the odd chance you don't like RIB-groups
 you
may want to  
>>> try another mechanism, which does not use them
- it is policy- 
>>> based export between routing instances:  http://tinyurl.com/35xtrk
>>>
>>> When you reference inet.0 you need to use the
keyword "master".   
>>> Using this method you can export routes between
the master  
>>> instance and a VRF, bi-directionally.
>>>
>>> Nick
>>> On Apr 16, 2007, at 1:53 PM, Dave Diller
wrote:
>>>
>>>> In the lab,  I've found that I can get 
specific BGP routes into  
>>>> inet.
>>>> 0 from a VRF using rib-groups and
auto-export to create a granular
>>>> "leak policy". Works great.
>>>>
>>>> Is it possible to do the converse - leak
selected BGP routes from
>>>> inet.0 into a VRF?  I've had no luck so
far.
>>>>
>>>> -dd
>>>>
>>>>
>>>>
_______________________________________________
>>>> juniper-nsp mailing list juniper-nsppuck.nether.net
>>>> 
https://puck.nether.net/mailman/listinfo/juniper-nsp
>>

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp


This communication is the property of Qwest and may contain
confidential or
privileged information. Unauthorized use of this
communication is strictly 
prohibited and may be unlawful.  If you have received this
communication 
in error, please immediately notify the sender by reply
e-mail and destroy 
all copies of the communication and any attachments.

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

> Unfortunately the only way I have been able to make
this work is  
> with rib groups....here is what I did to put all the
direct  
> interfaces into my VRF.
>
> }
> routing-options {
>     interface-routes {
>         rib-group inet interface-routes;
>     }
>     rib-groups {
>         interface-routes {
>             import-rib [ inet.0 vrf.inet.0 ];
>         }
>     }
>


Yeah, I've got it working for direct using the same
mechanism.   
That's not the issue... I'm trying to leak BGP routes from
inet.0.

I've got auto-export on the main routing-options,  but it
doesn't do  
anything. Could just be unsupported for inet.0 since not a
VPN, but  
it commits, for whatever that's worth.

daveRE1-lab-t640# show routing-options auto-export
family inet {
     unicast {
         rib-group LEAK-to-TEST2;
     }
}

daveRE1-lab-t640# show routing-options rib-groups
LEAK-to-TEST2
import-rib [ inet.0 TEST2.inet.0 ];

Doesn't work with just  "import-rib TEST2.inet.0"
in that rib-group  
either, which is less proper for rib groups in a classical
sense, but  
appropriate for auto-export, as documented here:
http://www.juniper.net/techpubs/software/junos/ju
nos82/feature- 
guide-82/html/fg-sirs7.html#1017692

"There is a significant difference in how routing table
groups are  
used in this case and how they are used more generally.
Typically,  
routing table groups require the exporting routing table to
be  
referenced as the primary import routing table in the
rib-group  
configuration. In this case, the restriction is lifted and
the  
routing table group functions as an additional list of
tables that  
export routes."

So I would think that applying it as above, to the main
routing- 
options, would allow for inet.0 to be exported to TEST2. No
dice yet.

-dd



_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

>
> Yeah, I've got it working for direct using the same
mechanism.
> That's not the issue... I'm trying to leak BGP routes
from inet.0.

Just got it.

before:

inet.0: 18128 destinations, 18128 routes (18128 active, 0
holddown, 0  
hidden)
                  BGP:  18109 routes,  18109 active

TEST2.inet.0: 3 destinations, 3 routes (0 active, 0
holddown, 3 hidden)
Restart Complete
                  BGP:      2 routes,      0 active


[edit protocols bgp]
+  family inet {
+      unicast {
+          rib-group LEAK-to-TEST2;
+      }
+  }

with
daveRE1-lab-t640# show routing-options rib-groups
LEAK-to-TEST2
import-rib [ inet.0 TEST2.inet.0 ];

post-commit:

inet.0: 18130 destinations, 18130 routes (18130 active, 0
holddown, 0  
hidden)
                  BGP:  18111 routes,  18111 active

TEST2.inet.0: 18114 destinations, 18114 routes (18111
active, 0  
holddown, 3 hidden)
Restart Complete
                  BGP:  18113 routes,  18111 active

-dd
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp