[j-nsp] MPLS filter doesnt work

Harry Reynolds harry at juniper.net
Wed Apr 15 20:06:05 EDT 2009


You did not answer:

> Are you using vrf-table-label? If so, the vrf label is popped at
ingress to the egress node, 
> resulting in an Ip lookup.
>

If you have this option enabled, then even the vrf label is popped at
ingress, so that an IP lookup is performed (which in turn allows egress
IP FW functions over the vrf interface). If enabled I believe that l3vpn
traffic is seen to ingress as IP, even for a L3vpn/vrf.  


{master}[edit]
regress at volcano# set routing-instances test vrf-table?         
Possible completions:
> vrf-table-label      Advertise a single VPN label for all routes in
the VRF

I did not doubt you had a vrf/l3 instance. To clarify, its possible to
have the same lsp used for both L3vpn, l2vpn, and, if desired, internal
traffic that is able to use the LSP, say via the install active or
traffic-engineering bgp-igp options. In such a case I believe it would
be possible to see different ingress behavior for VPN traffic, which
would arrive labeled and been seen as MPLS (barring above), vs internal
traffic, which due to PHP would arrive unlabeled and be seen as IP,
despite both using the same lsp. It was not clear if the test traffic
you based the FW counter on originated from a VRF or was perhaps being
generated from the PE's main instance.



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: Wednesday, April 15, 2009 8:38 AM
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] MPLS filter doesnt work

Yes we using instance-type vrf, otherwise, I dont know what else we
could use for L3VPN, and two PE are direct connected.  So summary is, on
the PE1 egress side, mpls filter doesnt match probably because egress
filter happens before label imposition. and on PE2 ingress side,
vrf-type causes label pop at ingress, even before the ip lookup and mpls
filter works? Am i understanding correctly? Correct me if not.

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

> 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
>
_______________________________________________
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