[j-nsp] MPLS filter doesnt work
Harry Reynolds
harry at juniper.net
Tue Apr 14 21:52:08 EDT 2009
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-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Shawn Shen
Sent: Tuesday, April 14, 2009 4:51 PM
To: juniper-nsp at 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 <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
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list