[j-nsp] MPLS filter doesnt work

[Shawn Shen]

I tried the same mpls filter on the PE2 ingress direction, which is
ge-1/3/0, traffic is from CE1 to CE2, still no mpls counters change. any
comment?

On Tue, Apr 14, 2009 at 6:19 PM, Harry Reynolds <harry at juniper.net> wrote:

> I've seen this behavior and believe its expected.
>
> At ingress the packet is handled as an Ip packet. The route is looked
> up, which would then possibly link to an egress firewall of family inet.
> After executing any inet filter code the route lookup is performed,
> assuming the filter accepts the packet, and here the result is a mpls
> forwarding next hop. By the time the packet hits the L2 rewrite state,
> where it becomes an MPLS frame, its already gone through the IP/R chip,
> so no more firewall action are performed.
>
> The next node will see this ingress as family mpls, so an ingress or
> egress mpls filter would work there, even if it's the penultimate hop
> and therefore actually output IP, and not MPLS due to PHP.
>
> The summary is the egress firewall family is a function of input family,
> and at least we are consistent at both ingress and penultimate nodes in
> this behavior.
>
> HTHs
>
>
>
>
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Shawn Shen
> Sent: Tuesday, April 14, 2009 3:07 PM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] MPLS filter doesnt work
>
> Hi all,
>
> I've just got a MPLS filter problem which I couldnt find reason. I'm
> quite new to Junos so it might be something I miss hope someone could
> shed a light.
> a typical Layer 3 vpn setup:
> CE1-----PE1(ge-1/3/0)-------------(ge-1/3/0)PE2----CE2
> CE1 lo0:1.1.1.1/32
> CE2 lo0:2.2.2.2/32
> vpn name: vpn-a
> PE1 lo0:3.3.3.3/32
> PE2 lo0:4.4.4.4/32
> L3 VPN is working fine as we can ping from CE1 lo0 to CE2 lo0,
> PE1 routing table shows PE2 lo0 is reachable via directed link between
> PE1/PE2
>
> {master}
> PE1-re0> show route 4.4.4.4
> inet.0: 1748 destinations, 1749 routes (1747 active, 0 holddown, 1
> hidden)
> + = Active Route, - = Last Active, * = Both
> 4.4.4.4/32   *[IS-IS/18] 00:00:38, metric 10000
>                    > to 11.11.11.1 via ge-1/3/0.0 Since PE1 directly
> connected to PE2, for L3 VPN traffic, due to PHB, only one label(VPN)
> will be imposed. we could verify this by checking PE1's l3vpn table
> which shows destination
> 2.2.2.2/32 is via ge-1/3/0 by pushing label 23,
> PE1-re0> show route table bgp.l3vpn.0 2.2.2.2/32 detail
> bgp.l3vpn.0: 1030 destinations, 1030 routes (1030 active, 0 holddown, 0
> hidden)
> 65400:300:2.2.2.2/32 (1 entry, 0 announced)
>        *BGP    Preference: 170/-81
>                Route Distinguisher: 65400:300
>                Next hop type: Indirect
>                Next-hop reference count: 10
>                Next hop type: Router, Next hop index: 651
>                Next hop: 11.11.11.1 via ge-1/3/0.0, selected
>                Label operation: Push 23
>                Protocol next hop: 4.4.4.4
>                Push 23
>                Indirect next hop: 8cb71d4 262160
>                State: <Active Int Ext>
>                Local AS: 65400 Peer AS: 65400
>                Age: 8:24:46    Metric2: 10000
>                AS path: 65021 I (Originator)
>                AS path:  Originator ID: 4.4.4.4
>                AS path:
>                AS path: Recorded
>                Communities: target:65400:300
>                Accepted
>                VPN Label: 23
>                Localpref: 80
>
> To my understanding, CE1's IP packet entering into PE1, gets imposed
> label 23, and label switched to PE2 via ge-1/3/0, to verify this, I put
> a mpls filter on PE1 ge-1/3/0 egress side:
>
> filter test {
>            term match-exp0 {
>  from {
>   exp 0
>  }
>                then {
>                    count count-exp0;
>                    sample;
>                    accept;
>                }
>            }
>            term match-exp1 {
>  from {
>   exp 1
>  }
>                then {
>                    count count-exp1;
>                    sample;
>                    accept;
>                }
>            }
>            term all-other {
>                then {
>                    count count-other;
>                    sample;
>                    accept;
>                }
>            }
>        }
>
> PE1-re0> show configuration interfaces ge-1/3/0
> mtu 1534;
> unit 0 {
>    family inet {
>        address 11.11.11.2/30;
>    }
>    family iso;
>    family mpls {
>        filter {
>            output test;
>        }
>    }
> }
>
> Now ping from CE1 to CE2, I'm expect to see these counters increase
> because the traffic between PE1 and PE2 are MPLS packets. But turns out
> every count is just 0.
> PE1-re0> show firewall filter test
> Filter: test
> Counters:
> Name                        Bytes              Packets
> count-other                   0                    0
> count-exp1                    0                    0
> count-exp0                    0                    0
>
> However, if I put a ipv4 filter under the same interface, address family
> inet, counters do increase with transit packets.
>
> PE1-re0> show configuration interfaces ge-1/3/0
> mtu 1534;
> unit 0 {
>    family inet {
>        filter {
>            output test1;
>        }
>        address 11.11.11.2/30;
>    }
>    family iso;
>    family mpls;
>    }
> }
> PE1-re0> show configuration firewall family inet filter test1
> interface-specific;
> term t1 {
>    then {
>        count pe-egress-count;
>        sample;
>        accept;
>    }
> }
> PE1-re0> show firewall filter test1
> Filter: test1
> Counters:
> Name                                  Bytes              Packets
> pe-egress-count                     43287               186
>
> Can somebody explain to me why mpls filter not get hit while there's
> mpls transit packets? Thanks in Advance!
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>