device manager needs to program public VRF on MX

Here's config snippets for the third option.

-Nischal

root@a5-mx80-1# show routing-instances nsheth-public
instance-type vrf;
vrf-target target:64512:7;
vrf-table-label;
routing-options {
    static {
        /* subnet for the public vn */
        route 192.168.7.0/24 discard;
        /* default route points to inet.0 */
        route 0.0.0.0/0 next-table inet.0;
    }
}

root@a5-mx80-1# show forwarding-options
family inet {
    filter {
        input redirect-to-public-vrf;
    }
}

root@a5-mx80-1# show firewall
filter redirect-to-public-vrf {
    term t1 {
        from {
            destination-address {
                192.168.7.0/24;
            }
        }
        then {
            routing-instance nsheth-public;
        }
    }
    term t2 {
        then accept;
    }
}

root@a5-mx80-1# show routing-instances nsheth-public | display set
set routing-instances nsheth-public instance-type vrf
set routing-instances nsheth-public vrf-target target:64512:7
set routing-instances nsheth-public vrf-table-label
set routing-instances nsheth-public routing-options static route 192.168.7.0/24 discard
set routing-instances nsheth-public routing-options static route 0.0.0.0/0 next-table inet.0

root@a5-mx80-1# show forwarding-options | display set
set forwarding-options family inet filter input redirect-to-public-vrf

[edit]
root@a5-mx80-1# show firewall | display set
set firewall filter redirect-to-public-vrf term t1 from destination-address 192.168.7.0/24
set firewall filter redirect-to-public-vrf term t1 then routing-instance nsheth-public
set firewall filter redirect-to-public-vrf term t2 then accept

[edit]
root@a5-mx80-1#

On Nov 20, 2014, at 11:56 AM, Nischal Sheth <email address hidden> wrote:

OK cool, let's use that then. I assume this property currently gets set via some
neutron APIs today. We can also allow user to set this via UI.

For the configuration to link public VRF to inet.0, we've used 2 options so far.

1) Create lt interfaces and static routes pointing to them. This brings down MX
forwarding performance.

2) Use static route with table next-hop from inet.0 to public.inet.0 and rib-group
to import inet.0 routes into public.inet.0. This will be tricky to configure unless
we also configure bgp/ospf/static to the outside world. The rib-group config has
to be applied to the specific protocol being used to talk to the outside.

A third option would be to use static route with table next-hop from public.inet.0
to inet.0 (default route) and a forwarding table filter from inet.0 to public.inet.0.
The filter would be applied to all packets being looked up in inet.0 and would
match destinations that are in the subnet(s) for the public VN. Action would be
to perform the lookup in public.inet.0. This will have some performance impact
on the PPS but not on BPS.

This option has no dependencies on other configuration, so it should be simpler
to implement.

Comments?

-Nischal

On Nov 19, 2014, at 9:55 PM, Sachin Bansal <email address hidden> wrote:

We already have router:external tag that kind of indicates public.
Sachin

On Wed, Nov 19, 2014 at 9:39 PM, Nischal Sheth <email address hidden> wrote:

We may need to add a property to VN to say that it's a/the public VN. Based on that, we can generate the public VRF config and the funky linkage to inet.0.

Other ideas?

-Nischal

Sent from my iPhone