[j-nsp] EX series VLAN filter verification
I've been getting closer to implementing filters on a particular EX3200 I'm using, and I noticed that the verification capabilities in the CLI for filters (specifically, where they are applied) is pretty weak. For instance, I can't find a standard way to see a list of what ports, interfaces, or vlans a particular filter is applied on. The best I can come up with is- show configuration | display set | match filter | match vlan Is there way I'm missing that can give me the same (or somewhat similar) information? Thanks, Dan Farrell Director of Network Operations Applied Innovations Corp. da...@appliedi.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX series VLAN filter verification
Does show interfaces filters help? Regards -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Dan Farrell Sent: Tuesday, August 11, 2009 11:25 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX series VLAN filter verification I've been getting closer to implementing filters on a particular EX3200 I'm using, and I noticed that the verification capabilities in the CLI for filters (specifically, where they are applied) is pretty weak. For instance, I can't find a standard way to see a list of what ports, interfaces, or vlans a particular filter is applied on. The best I can come up with is- show configuration | display set | match filter | match vlan Is there way I'm missing that can give me the same (or somewhat similar) information? Thanks, Dan Farrell Director of Network Operations Applied Innovations Corp. da...@appliedi.net ___ 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
Re: [j-nsp] EX series VLAN filter verification
That seems to be applicable to interfaces, not to vlans themselves. It did not return information on the filter I've applied to a vlan itself. Maybe I'm confusing something. Dan -Original Message- From: Harry Reynolds [mailto:ha...@juniper.net] Sent: Tuesday, August 11, 2009 2:46 PM To: Dan Farrell; juniper-nsp@puck.nether.net Subject: RE: EX series VLAN filter verification Does show interfaces filters help? Regards -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Dan Farrell Sent: Tuesday, August 11, 2009 11:25 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX series VLAN filter verification I've been getting closer to implementing filters on a particular EX3200 I'm using, and I noticed that the verification capabilities in the CLI for filters (specifically, where they are applied) is pretty weak. For instance, I can't find a standard way to see a list of what ports, interfaces, or vlans a particular filter is applied on. The best I can come up with is- show configuration | display set | match filter | match vlan Is there way I'm missing that can give me the same (or somewhat similar) information? Thanks, Dan Farrell Director of Network Operations Applied Innovations Corp. da...@appliedi.net ___ 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
[j-nsp] MPLS VPN Load-balancing
NSP-ers, I have a Cisco---Juniper pair connected over a pair of T3 links. The Juniper acts as a PE and is pushing two labels for a specific route learned on the PE destined to a single remote PE well beyond the Cisco P. The traffic is destined to several IP addresses clustered in this subnet (sort of like 10, 11, 12, 13) and the forwarding table shows that there are two correctly installed next-hops - same VPN label, different LDP label (we have applied several different types of hashings and of course have our forwarding table export policy in place). Nevertheless, the Juniper is doing a very poor job load- balancing the traffic, and the Cisco is splitting it almost evenly. There is in fact a larger number of routes being shared across this link (about 20 or so VPN routes in different VRFs and thus different VPN labels – all sharing the same 2 LDP labels, but one particular subnet pair is exchanging quite a bit of traffic). All of the addresses are unique within our domain. Has anyone had issues with load-balancing a single subnet across an MPLS VPN link pair? Note again that this is a PE-P (J--C) problem and that the IP addresses are all arranged locally. I know Juniper are secretive about their hashing algorithm (can't lose any hero tests, can we?), but we are getting like 5:1 load share if we are lucky and are bumping up against the T3's capacity. The box is an M10i. As always, any help would be appreciated. Cheers, C show route forwarding-table destination 10.160.2.0/24 Routing table: foo.inet Internet: DestinationType RtRef Next hop Type Index NhRef Netif 10.160.2.0/24 user 0indr 262175 2 ulst 262196 2 Push 74 600 1 t3-0/0/0.1000 Push 74 632 1 t3-0/0/1.1000 PE-P next-hop count (all showing load-balancing in effect) show route next-hop 172.16.255.11 terse | match | count Count: 106 lines monitor interface traffic InterfaceLink Input bytes(bps) Output bytes(bps) t3-0/0/0 Up541252651233 (25667208) 691166913860 (35611752) t3-0/0/1 Up279149587856(8737568) 24893605598 (20112) Note that the Cisco is doing 25/9 Mbps and the Juniper 35/.02. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX series VLAN filter verification
Correct. It seemed you were asking about interfaces (logical units) and vlans. Not aware of a cli that displays what vlans have filters. Perhaps an er is there. Regards -Original Message- From: Dan Farrell [mailto:da...@appliedi.net] Sent: Tuesday, August 11, 2009 11:56 AM To: Harry Reynolds; juniper-nsp@puck.nether.net Subject: RE: EX series VLAN filter verification That seems to be applicable to interfaces, not to vlans themselves. It did not return information on the filter I've applied to a vlan itself. Maybe I'm confusing something. Dan -Original Message- From: Harry Reynolds [mailto:ha...@juniper.net] Sent: Tuesday, August 11, 2009 2:46 PM To: Dan Farrell; juniper-nsp@puck.nether.net Subject: RE: EX series VLAN filter verification Does show interfaces filters help? Regards -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Dan Farrell Sent: Tuesday, August 11, 2009 11:25 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX series VLAN filter verification I've been getting closer to implementing filters on a particular EX3200 I'm using, and I noticed that the verification capabilities in the CLI for filters (specifically, where they are applied) is pretty weak. For instance, I can't find a standard way to see a list of what ports, interfaces, or vlans a particular filter is applied on. The best I can come up with is- show configuration | display set | match filter | match vlan Is there way I'm missing that can give me the same (or somewhat similar) information? Thanks, Dan Farrell Director of Network Operations Applied Innovations Corp. da...@appliedi.net ___ 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
Re: [j-nsp] MPLS VPN Load-balancing
Steven, Thanks for the response. I was unaware of this limitation in the ABC- chip, but I am still curious as to why the incoming traffic to the PE, which should be hashed at IP only, is not properly balanced across the outbound (MPLS) links. The lookup is done on the IP header only, which should have enough entropy to create a reasonably balanced modulus. Unless the outbound FIB entries play a role somehow? I could see if this were a P and MPLS was coming in and out, but it is IP---push--push---forward... Also note that the outer label is of course different on the two links (learned via LDP). Cheers, Chris On Aug 11, 2009, at 4:08 PM, Steven Brenchley wrote: Hi Christian, The problem your hitting is a limitation of the M10i chip set. It can only look at the top two labels and since both top labels are the same for all this traffic it's going to look like the same flow and send it all across the same link. The only way I've been able to get a simulance of load balancing is by creating multiple LSP's between the same end points and manually push different traffic across the different LSP's. It's really clunky but there are no switches that will work around this limitation on the current M10i CFEB. If you where using a T-series, M320,M120, or MX router you don't have this limitation. They can all go deeper into the packet to determine load balance. On the a semi brighter side, on the horizon there are some new Ichip based CFEB's which will not have this limitation. I don't recall when those will be available but you could probably get a hold of your SE and get a time table from them. Steven Brenchley === On Tue, Aug 11, 2009 at 3:16 PM, Christian Martin christian.mar...@teliris.com wrote: NSP-ers, I have a Cisco---Juniper pair connected over a pair of T3 links. The Juniper acts as a PE and is pushing two labels for a specific route learned on the PE destined to a single remote PE well beyond the Cisco P. The traffic is destined to several IP addresses clustered in this subnet (sort of like 10, 11, 12, 13) and the forwarding table shows that there are two correctly installed next- hops - same VPN label, different LDP label (we have applied several different types of hashings and of course have our forwarding table export policy in place). Nevertheless, the Juniper is doing a very poor job load-balancing the traffic, and the Cisco is splitting it almost evenly. There is in fact a larger number of routes being shared across this link (about 20 or so VPN routes in different VRFs and thus different VPN labels – all sharing the same 2 LDP labels, but one particular subnet pair is exchanging quite a bit of traffic). All of the addresses are unique within our domain. Has anyone had issues with load-balancing a single subnet across an MPLS VPN link pair? Note again that this is a PE-P (J--C) problem and that the IP addresses are all arranged locally. I know Juniper are secretive about their hashing algorithm (can't lose any hero tests, can we?), but we are getting like 5:1 load share if we are lucky and are bumping up against the T3's capacity. The box is an M10i. As always, any help would be appreciated. Cheers, C show route forwarding-table destination 10.160.2.0/24 Routing table: foo.inet Internet: DestinationType RtRef Next hop Type Index NhRef Netif 10.160.2.0/24 user 0indr 262175 2 ulst 262196 2 Push 74 600 1 t3-0/0/0.1000 Push 74 632 1 t3-0/0/1.1000 PE-P next-hop count (all showing load-balancing in effect) show route next-hop 172.16.255.11 terse | match | count Count: 106 lines monitor interface traffic InterfaceLink Input bytes(bps) Output bytes(bps) t3-0/0/0 Up541252651233 (25667208) 691166913860 (35611752) t3-0/0/1 Up279149587856(8737568) 24893605598 (20112) Note that the Cisco is doing 25/9 Mbps and the Juniper 35/.02. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Steven Brenchley - There are 10 types of people in the world those who understand binary and those who don't. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS VPN Load-balancing
but one particular subnet pair is exchanging quite a bit of traffic). All of the addresses are unique within our domain Can you clarify the nature of you test traffic to the busy subnet in question? 1. Number of vrf ingress interfaces? 2. Number of source-Ips 3. Number of destination ips w/in that subnet Basically, how many flows do you have heading to that busy subnet? IIRC, as an ingress node we would do an IP hash, and this should use the incoming interface and IP S/D addresses by default. On some platforms when you start adding additional hashes, such as a L4 port, you may start eating into the number of IP address bits that are actually hashed. Meaning, you gain port entropy but loose some granularity at the IP address level. Hence these knobs have a bit of variance for each person that test them, as their flow specifics may or may not benefit from some combination. As always, the more variance and the larger the number of streams the better the expected results. If there is a single pair of busy speakers on that subnet that would explain things. If you had 10 (or more) more or less equally active streams, and still had the results below, then that would seem broken IMO. I may be wrong, but if you only have 3 such streams, then each stream is independently hashed, and there is a 12 % chance (.50 x .50 x.50) you will get unlucky and find all three on the same link. HTHs. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Christian Martin Sent: Tuesday, August 11, 2009 1:58 PM To: Steven Brenchley Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MPLS VPN Load-balancing Steven, Thanks for the response. I was unaware of this limitation in the ABC- chip, but I am still curious as to why the incoming traffic to the PE, which should be hashed at IP only, is not properly balanced across the outbound (MPLS) links. The lookup is done on the IP header only, which should have enough entropy to create a reasonably balanced modulus. Unless the outbound FIB entries play a role somehow? I could see if this were a P and MPLS was coming in and out, but it is IP---push--push---forward... Also note that the outer label is of course different on the two links (learned via LDP). Cheers, Chris On Aug 11, 2009, at 4:08 PM, Steven Brenchley wrote: Hi Christian, The problem your hitting is a limitation of the M10i chip set. It can only look at the top two labels and since both top labels are the same for all this traffic it's going to look like the same flow and send it all across the same link. The only way I've been able to get a simulance of load balancing is by creating multiple LSP's between the same end points and manually push different traffic across the different LSP's. It's really clunky but there are no switches that will work around this limitation on the current M10i CFEB. If you where using a T-series, M320,M120, or MX router you don't have this limitation. They can all go deeper into the packet to determine load balance. On the a semi brighter side, on the horizon there are some new Ichip based CFEB's which will not have this limitation. I don't recall when those will be available but you could probably get a hold of your SE and get a time table from them. Steven Brenchley === On Tue, Aug 11, 2009 at 3:16 PM, Christian Martin christian.mar...@teliris.com wrote: NSP-ers, I have a Cisco---Juniper pair connected over a pair of T3 links. The Juniper acts as a PE and is pushing two labels for a specific route learned on the PE destined to a single remote PE well beyond the Cisco P. The traffic is destined to several IP addresses clustered in this subnet (sort of like 10, 11, 12, 13) and the forwarding table shows that there are two correctly installed next- hops - same VPN label, different LDP label (we have applied several different types of hashings and of course have our forwarding table export policy in place). Nevertheless, the Juniper is doing a very poor job load-balancing the traffic, and the Cisco is splitting it almost evenly. There is in fact a larger number of routes being shared across this link (about 20 or so VPN routes in different VRFs and thus different VPN labels - all sharing the same 2 LDP labels, but one particular subnet pair is exchanging quite a bit of traffic). All of the addresses are unique within our domain. Has anyone had issues with load-balancing a single subnet across an MPLS VPN link pair? Note again that this is a PE-P (J--C) problem and that the IP addresses are all arranged locally. I know Juniper are secretive about their hashing algorithm (can't lose any hero tests, can we?), but we are getting like 5:1 load share if we are lucky and are bumping up against the T3's capacity. The box is an M10i. As always,
[j-nsp] 6 VPE in Juno
Hi, I am trying to establish 6VPE (V6 over V4 vpn) with Juniper M320, but I could see there is some problem in installing V6 routes sent by Redback Smart Edge to Juno. Where as the V6 routes sent by Juno are successfully installed in SE routing table. I am seeing the following problem in Juno routing table i.e the next hop is shown as v6 address rather than V4 address. Should it covert V6 next-hop address back to V4 ? Any ideas ? Juno routing table: t...@systest-m320# run show route receive-protocol bgp 1.1.1.2 logical-system jana hidden inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) inet.3: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) vpn1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) vpn1.inet6.0: 7 destinations, 7 routes (5 active, 0 holddown, 2 hidden) Prefix Nexthop MED LclprefAS path 220::/*64:::1.1.1.2* 0 100? 3ffe::/*64 :::1.1.1.2* 0 100? bgp.l3vpn-inet6.0: 2 destinations, 2 routes (0 active, 0 holddown, 2 hidden) Prefix Nexthop MED LclprefAS path 1.1.1.1:6500:220::/64 :::1.1.1.2 0 100? 1.1.1.1:6500:3ffe::/64 :::1.1.1.2 0 100? [edit groups MPBN logical-systems jana] t...@systest-m320# SE routing table: [local]JST-PE2#sh bgp route ipv6 vpn neighbor 1.1.1.4 rec | begin 6500 VPN RD: 1.1.1.4:6500 NetworkNext HopMetric LocPrf Weight Path i 120::/64 1.1.1.4 0 100 100 1000 ? i 200::/64 1.1.1.4 0 100 100 i [local]JST-PE2# Thanks, Jana Any ideas ? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6 VPE in Juno
With ip6-tunneling command (assuming you have that configured), JUNOS will convert the v4 LSP route in inet.3 to a 6to4 v6 format in inet6.3. This route is just used to resolve the vpn-v6 prefixes received from remote PE and not for actual traffic forwarding. Traffic forwarding should still happen with v4 LSP. Assuming 1.1.1.2 is remote v4/v6 PE router, do you have a working v4 LSP to 1.1.1.2 in inet.3 table? Do you have any active vpn-v4 routes using this LSP and in active state. Also, all v6 prefixes coming in with 1.1.1.2 as protocol nexthop? (they seem to be be but just want to be clear). Also, if you can send the extensive output for received v6 prefixes in the hidden state, it would help. Thanks, Nilesh. janardhan madabattula wrote: Hi, I am trying to establish 6VPE (V6 over V4 vpn) with Juniper M320, but I could see there is some problem in installing V6 routes sent by Redback Smart Edge to Juno. Where as the V6 routes sent by Juno are successfully installed in SE routing table. I am seeing the following problem in Juno routing table i.e the next hop is shown as v6 address rather than V4 address. Should it covert V6 next-hop address back to V4 ? Any ideas ? Juno routing table: t...@systest-m320# run show route receive-protocol bgp 1.1.1.2 logical-system jana hidden inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) inet.3: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) vpn1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) vpn1.inet6.0: 7 destinations, 7 routes (5 active, 0 holddown, 2 hidden) Prefix Nexthop MED LclprefAS path 220::/*64:::1.1.1.2* 0 100? 3ffe::/*64 :::1.1.1.2* 0 100? bgp.l3vpn-inet6.0: 2 destinations, 2 routes (0 active, 0 holddown, 2 hidden) Prefix Nexthop MED LclprefAS path 1.1.1.1:6500:220::/64 :::1.1.1.2 0 100? 1.1.1.1:6500:3ffe::/64 :::1.1.1.2 0 100? [edit groups MPBN logical-systems jana] t...@systest-m320# SE routing table: [local]JST-PE2#sh bgp route ipv6 vpn neighbor 1.1.1.4 rec | begin 6500 VPN RD: 1.1.1.4:6500 NetworkNext HopMetric LocPrf Weight Path i 120::/64 1.1.1.4 0 100 100 1000 ? i 200::/64 1.1.1.4 0 100 100 i [local]JST-PE2# Thanks, Jana Any ideas ? ___ 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
