Junos OS

last person joined: 11 hours ago 

Ask questions and share experiences about Junos OS.
Expand all | Collapse all

filter-based forwarding... struggling. ex4500.

  • 1.  filter-based forwarding... struggling. ex4500.

    Posted 02-14-2014 18:51

    hi. i posted this on juniper-nsp, but thought i'd try my luck here too.

     

    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


  • 2.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-15-2014 11:13

    I have not yet looked any further yet, but the first thing I would suggest, is to move the firewall filter

    [edit firewall ]

    heirarchy to:

    [edit firewall family inet filter FLEET-NAT]

     And to place this term as the first term:

    #insert term else-nat before term pass-1



  • 3.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-15-2014 13:27

    that'll cause it to get punted to the next hop for all intra-fleet traffic. i don't think the filter is the issue. it's hitting the firewall log appropriately.



  • 4.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-15-2014 20:54

    term else-nat {

                    from {
                        source-address {
                            10.1.12.2/32; <= This is a single address and you want this to be directed to the routing instance, so it should be the fist one. You want your most specific rule at the top.
     
    firewall {
            filter FLEET-NAT {
                term pass-1 {
                    from {
                        source-address {
                            <snip>; <= does this source address account for your single IP address?
                        }
                    }
                    then accept;
                }
                term pass-2 {
                    from {
                        destination-address {
                            10.0.0.0/8;<= This is  match for your single IP addres so it would never to the term else-nat.
                        }
                    }
                    then accept;


  • 5.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-15-2014 21:03

    i tend to disagree. i don't want it directed if dest = 10/8. keep in mind the dest/src directions of my rules.

     

    so, when inbound to this switch, it'll skip the second entry if it is destined to 10/8, skips the first because it isn't sourced from my public block, and should jump into the else-nat term, which it does, based on the firewall filter log.

     

    eg:

     

    23:55:10 pfe A xe-0/0/12.0 TCP 10.1.12.2 74.125.228.226
    23:55:00 pfe A xe-0/0/12.0 TCP 10.1.12.2 74.125.228.225



  • 6.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-16-2014 04:12

    Hello,

    Please either use RVI interfaces with "instance-type forwarding", or plain L3 subinterfaces with "instance-type virtual-router".

    The mixture of plain L3 interfaces with "instance-type-forwarding" is not supported on EX4200/4500 and results in below FIB entry as You have already discovered

     

     

    # 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

     

    The configuration example with plain L3 subinterfaces and virtual-routers can be found here

     

    http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/filter-based-forwarding-with-firewall-filter-ex-series.html

     

    HTH

    Thanks

    Alex



  • 7.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-16-2014 09:07

    thanks for the reply. can you elaborate, though? from the config shown it looks to me like i'm using RVI and "forwarding".



  • 8.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-16-2014 09:27

    i came across this kb article, which sort of sounds related, but not quite sure.

     

    http://kb.juniper.net/InfoCenter/index?page=content&id=KB23027&smlogin=true



  • 9.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-16-2014 11:12

    Hello there,

     


    @ryry wrote:

    thanks for the reply. can you elaborate, though? from the config shown it looks to me like i'm using RVI and "forwarding".


    Yes but You are pointing the static towards BGP protocol nexthop, not directly connected nexthop which is what FBF is all about.

    Please configure following:

     

    delete routing-instances nat-vrf routing-options static route 0/0
    set routing-instances nat-vrf routing-options static route 0/0 next-hop 10.1.5.11

     

    - then re-rest and report back.

    HTH

    Thanks

    Alex

     



  • 10.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-16-2014 11:17

    ahh i see your point. this i wasn't aware of.

     

    is there no way to use the BGP route as a next-hop? the BGP route acts as a VIP advertised by many servers for load-balancing.



  • 11.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-17-2014 11:43

    i tried setting next-hop to something that is in that vlan, and i see this in the NAT vrf forwarding-table.

     

    Destination Type RtRef Next hop Type Index NhRef Netif
    default user 0 0:25:90:19:93:ca ucst 1782 5 vlan.105

     

    traffic still doesn't arrive at the host with that mac address, unfortunately.



  • 12.  RE: filter-based forwarding... struggling. ex4500.
    Best Answer

    Posted 02-17-2014 14:40

    to circle back on this, i opened a case with JTAC. turns out my config was just fine. the PFE needed to be restarted.



  • 13.  RE: filter-based forwarding... struggling. ex4500.

    Posted 02-18-2014 10:13
    ryry, can you go ahead and mark your post as resolved with solution to restart the pfe 🙂