[j-nsp] filter-based forwarding... struggling

Olivier Benghozi olivier.benghozi at wifirst.fr
Sat Feb 15 22:29:23 EST 2014


Damn, next-ip is MX only :/
And "accept" is implicit anyway in the term for matched packets.

But, shouldn't you have a "resolve" for your 0.0.0.0/0 static route in your forwarding instance?


Le 16 févr. 2014 à 04:01, ryanL <ryan.landry at gmail.com> a écrit :

> hi olivier.
> 
> it doesn't appear that next-ip is available on the EX platform; i'm running 12.3R3.4 and that doesn't show up.
> 
> also, setting "term else-nat then accept" ends up removing "term else-nat then routing-instance nat-vrf". i don't believe you can have both.
> 
> thx
> 
> ryan
> 
> 
> 
> On Sat, Feb 15, 2014 at 6:30 PM, Olivier Benghozi <olivier.benghozi at wifirst.fr> wrote:
> You have to add:
> set firewall filter FLEET-NAT term else-nat then accept
> 
> 
> By the way in 12.2R2 and later you can as well drop all this rib-group+forwarding instance stuff, and just replace "then routing-instance nat-vrf" by "then next-ip 10.1.0.51" in your firewall filter, as in a PBR Cisco like config.
> 
> 
> regards,
> Olivier
> 
> Le 15 févr. 2014 à 01:41, ryanL <ryan.landry at gmail.com> a écrit :
> 
> > hi. this should be dead simple, but it isn't and my google-fu is sucking.
> >
> > all i want to do on my ex4500 is punt traffic to a next hop. simple
> > policy-based routing in cisco-speak. apparently you need a routing-instance
> > to do so. fine. we'll try it.
> >
> > so here we go. i'm basically saying if the destination isn't other fleet
> > machines in 10/8, or the source isn't any of my public ip, throw it at my
> > proxy/nat box that lives at 10.1.0.51, which is learned via bgp (exabgp).
> > for now, i'm testing this only on one machine - 10.1.12.2, as referenced in
> > the firewall filter.
> >
> > // config //
> >
> > routing-instances {
> >    nat-vrf {
> >        instance-type forwarding;
> >        routing-options {
> >            static {
> >                route 0.0.0.0/0 next-hop 10.1.0.51;
> >            }
> >        }
> >    }
> > }
> > routing-options {
> >    interface-routes {
> >        rib-group inet fbf-group;
> >    }
> >    rib-groups {
> >        fbf-group {
> >            import-rib [ inet.0 nat-vrf.inet.0 ];
> >        }
> >    }
> > }
> > protocols {
> >    bgp {
> >        group NAT-VIP {
> >            family inet {
> >                unicast {
> >                    rib-group fbf-group;
> >                }
> >            }
> >        }
> >    }
> > }
> >
> > interfaces {
> >    vlan {
> >        unit 112 {
> >            family inet {
> >                filter {
> >                    input FLEET-NAT;
> >                }
> >            }
> >        }
> >    }
> > }
> >
> > firewall {
> >        filter FLEET-NAT {
> >            term pass-1 {
> >                from {
> >                    source-address {
> >                        <snip>;
> >                    }
> >                }
> >                then accept;
> >            }
> >            term pass-2 {
> >                from {
> >                    destination-address {
> >                        10.0.0.0/8;
> >                    }
> >                }
> >                then accept;
> >            }
> >            term else-nat {
> >                from {
> >                    source-address {
> >                        10.1.12.2/32;
> >                    }
> >                }
> >                then {
> >                    log;
> >                    routing-instance nat-vrf;
> >                }
> >            }
> >        }
> >    }
> > }
> > // end //
> >
> > the routing instance nat-vrf sees the route to 10.1.0.51:
> >
> > # show route table nat-vrf 10.1.0.51
> >
> > nat-vrf.inet.0: 61 destinations, 62 routes (61 active, 0 holddown, 0 hidden)
> > + = Active Route, - = Last Active, * = Both
> >
> > 10.1.0.51/32       *[BGP/170] 00:36:53, localpref 500
> >                      AS path: I, validation-state: unverified
> >> to 10.1.5.11 via vlan.105
> >
> > and we have a recursed route to the 10.1.5.11 next hop.
> >
> > # show route table nat-vrf 10.1.5.11
> >
> > nat-vrf.inet.0: 61 destinations, 62 routes (61 active, 0 holddown, 0 hidden)
> > + = Active Route, - = Last Active, * = Both
> >
> > 10.1.5.0/24        *[Direct/0] 00:41:46
> >> via vlan.105
> >
> > forwarding table looks ok, i think:
> >
> > # show route forwarding-table table nat-vrf destination 10.1.0.51
> > Routing table: nat-vrf.inet
> > Internet:
> > Destination        Type RtRef Next hop           Type Index NhRef Netif
> > 10.1.0.51/32       user     0                    indr 131083     5
> >                              10.1.5.11          ucst  1639     4 vlan.105
> >
> > # show route forwarding-table table nat-vrf destination 10.1.5.11
> > Routing table: nat-vrf.inet
> > Internet:
> > Destination        Type RtRef Next hop           Type Index NhRef Netif
> > 10.1.5.0/24        user     0                    rtbl     1    29
> >
> > i think the thing missing here is that nat-vrf doesn't have a mac address
> > next-hop for 10.1.5.11/32, much like inet.0 does:
> >
> > # show route forwarding-table destination 10.1.5.11
> > Routing table: default.inet
> > Internet:
> > Destination        Type RtRef Next hop           Type Index NhRef Netif
> > 10.1.5.11/32       dest     1 0:25:90:19:93:ca   ucst  1639     4 vlan.105
> >
> > so, when tcpdumping on 10.1.5.11, i see no packets come in from a fleet
> > machine as i'd expect.
> >
> > the firewall log shows my curl attempts to google, so i know i'm making it
> > into the else-nat term properly.
> >
> > # show firewall log
> > Log :
> > Time      Filter    Action Interface     Protocol        Src Addr
> >              Dest Addr
> > 23:55:55  pfe       A      xe-0/0/12.0   TCP             10.1.12.2
> >               74.125.228.230
> > 23:55:54  pfe       A      xe-0/0/12.0   TCP             10.1.12.2
> >               74.125.228.230
> >
> > i'm a bit stumped from this point forward. i entirely admit that i don't
> > necessarily understand some of the knobs to turn with this setup. i did at
> > least try changing the routing-instance from "forwarding" to
> > "virtual-router".
> >
> > not quite sure how to get nat-vrf to actually do the f part. do i have to
> > share arp across instances somehow as well?
> >
> > appreciate any pointers!
> >
> > ryan
> 



More information about the juniper-nsp mailing list