This is a 1 hop lsp, right? VPN traffic should arrive with a vrf label, and I would assume be considered mpls. Regular inet will ingress as IP due to php.
Are you using vrf-table? If so, the vrf is popped at ingress, resulting in an Ip lookup. That may explain it. Regards -----Original Message----- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Shawn Shen Sent: Tuesday, April 14, 2009 4:51 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MPLS filter doesnt work 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 <ha...@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-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Shawn Shen > Sent: Tuesday, April 14, 2009 3:07 PM > To: juniper-nsp@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp