[j-nsp] MPLS filter doesnt work
Shawn Shen
shawshen2000 at gmail.com
Wed Apr 15 11:37:55 EDT 2009
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
>
More information about the juniper-nsp
mailing list