[j-nsp] MPLS filter doesnt work

[Harry Reynolds]

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