[j-nsp] Dynamic route leaking between global routing table and vrf routing table

Mark Meijerink mark.meijerink at sara.nl
Fri Sep 10 01:47:00 EDT 2010


David,

We dit and have it running in production for over 1 year now. The most important is the use of rib-groups to get certain
prefixes in the correct routing tabbles.

rib-import-VRF-routes-to-inet0-v4:
RIB-group to get routes learned in the VRF into the global routing table inet.0. Define the use of this rib-group under
the BGP configuration in the VRF. In the policy you can do dynamic filtering of routes. We use the import policy to only
put routes with certain communities in the global routing table.

rib-import-inet0-routes-to-VRF-v4:
RIB-group to get routes learned via IBGP into the VRF routing table VRF.inet.0. Define the use of this rib-group under
the global BGP configuration. In the policy you can do dynamic filtering of routes. We use the import policy to only put
routes with certain communities in the VRF routing table.

Below the scrubbed configuration so you can see how we solved it. If you would like to have more information about the
setup please let me know.


rib-groups {
    rib-interface-routes-v4 {
        import-rib [ inet.0 VRF.inet.0 ];
    }
    rib-import-VRF-routes-to-inet0-v4 {
        export-rib VRF.inet.0;
        import-rib [ VRF.inet.0 inet.0 ];
        import-policy rib-import-VRF-routes-to-inet0-v4;
    }
    rib-import-inet0-routes-to-VRF-v4 {
        export-rib inet.0;
        import-rib [ inet.0 VRF.inet.0 ];
        import-policy rib-import-inet0-routes-to-VRF-v4;
    }
}

routing-options {
    interface-routes {
        rib-group {
            inet rib-interface-routes-v4;
            inet6 rib-interface-routes-v6;
        }
    }
}

protocols {
    bgp {
        group iBGP-peers {
            type internal;
            family inet {
                unicast {
                    rib-group rib-import-inet0-routes-to-VRF-v4;
                }
            }
	}
    }
}

routing-instances {
    VRF {
        routing-options {
            interface-routes {
                rib-group {
                    inet rib-interface-routes-v4;
                    inet6 rib-interface-routes-v6;
                }
            }
        }
        protocols {
            bgp {
                group peersin-VRF {
                    family inet {
                        unicast {
                            rib-group rib-import-VRF-routes-to-inet0-v4;
                        }
                    }
                }
            }
	}
    }
}


Regards,
 Mark

On 9/9/2010 9:49 PM, David Ball wrote:
>   Hi mark.  I know this thread goes back to last year, but I was wondering if you found any solution to your issue with
> leaking routes between inet.0 and a VRF ?  I'm in the process of trying the exact same thing, and am tripping over all
> kinds of issues, including some of the ones you uncovered, like not being able to use instance-import inside a VRF, etc.
>   I only have 1 route in inet.0 that I want to leak to a VRF, and similarly, I have 1 route in that VRF that I want to
> leak into inet.0.  Any insight you can provide regarding how you solved it would be appreciated!
>  
> David
> 
> 
> On 6 April 2009 12:45, Mark Meijerink <mark.meijerink at sara.nl <mailto:mark.meijerink at sara.nl>> wrote:
> 
>     Sean,
> 
>     I tried using instance-import but when I tried to commit the configuration it failed because I could not import from
>     the VRF instance. The instance
>     type we use is VRF. This might have something to do with it. Do you have a configuration example for me so I can
>     give it a try?
> 
>     Regards,
>      Mark
> 
>     Sean Clarke wrote:
>     > You might find using "instance-import" and "instance-export" much easier
>     > to use than RIB-groups.
>     >
>     > With a simple policy you can import/export routes from and to the inet.0
>     > table, and use the same command within the routing instances to pull
>     > routes from inet.0 into the VRF.
>     >
>     > This works fine with community.
>     >
>     > cheers
>     > Sean
>     >
>     >
>     >
>     > On 4/3/09 2:47 PM, Mark Meijerink wrote:
>     >> Hi there,
>     >>
>     >> I have been working on dynamic leaking of routes between the global routing table and the vrf routing table based
>     on communities. But I have failed to
>     >> make it work. I have already seen multiple examples but those did not work for me. I will give s short
>     description of what we are trying to achieve
>     >> and I hope you can point me in the right direction.
>     >>
>     >> In the global routing table we have our peerings with AMS-IX peers and iBGP peerings with two core routers. The
>     AMS-IX routes are given a certain
>     >> community. We want to create a vrf with customers which only have AMS-IX connectivity. So we want to dynamically
>     leak routes into the vrf based on the
>     >> community. In the vrf we have BGP sessions with the customers and the routes we learn from them are tagged with a
>     certain community as well. These
>     >> routes must be dynamically leaked into the global routing table. We are looking for a way to dynamically leak
>     routes in two directions.
>     >>
>     >> I have tried using rib-groups and tried to make it work using the vrf-import and vrf-export policies. Could you
>     please let me know how I can make the
>     >> setup as explained above work. The difficulty we are introducing is that we want to leak dynamically and not
>     static. Thanks in advance for your reply
>     >> and advice.
>     >>
>     >> Regards,
>     >>  Mark Meijerink
>     >>  SARA
>     >>
>     >>
>     >> ------------------------------------------------------------------------
>     >>
>     >> _______________________________________________
>     >> juniper-nsp mailing list juniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>
>     >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>     >
> 
> 
>     _______________________________________________
>     juniper-nsp mailing list juniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>
>     https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100910/cc7c38cd/attachment.bin>


More information about the juniper-nsp mailing list