Re: [j-nsp] mpls node-protection: LSP down
This is the topology: http://img52.imageshack.us/img52/5512/avpn.png Sorry On Fri, Aug 10, 2012 at 11:57 AM, Mihai Gabriel mihaigabr...@gmail.comwrote: Hello, I am trying to test the node-protection feature in a lab using an MX5 router with logical-systems and I can't find the reason why is not working.The topology I use is here: http://imageshack.us/photo/my-images/849/avpn.png/ All routers are configured for mls,rsvp,ospf,link-protection, but when I disable the interface between P1 and PE1, the LSP between PE1 and PE2 goes down and stay that way: Before disabling the interface: mumulox@mx5t show mpls lsp logical-system PE1 extensive Ingress LSP: 1 sessions 192.168.1.2 From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2 ActivePath: strict-path (primary) Node/Link protection desired LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Revert timer: 1 *Primary strict-path State: Up Priorities: 7 0 OptimizeTimer: 1 SmartOptimizeTimer: 2 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.5.1(flag=0x29) 172.22.210.2(flag=9 Label=301600) 192.168.5.2(flag=0x29) 172.22.201.2(flag=9 Label=301472) 192.168.5.3(flag=0x21) 172.22.206.2(flag=1 Label=301200) 192.168.1.2(flag=0x20) 172.22.212.1(Label=3) mumulox@mx5t show mpls path strict-path logical-system PE1 Path nameAddress strict/loose if-id strict-path 172.22.210.2strictempty mumulox@mx5t show rsvp session logical-system PE1 Ingress RSVP: 2 sessions To FromState Rt Style Labelin Labelout LSPname 192.168.1.2 192.168.1.1 Up 0 1 SE - 301600 pe1-to-pe2 192.168.5.2 192.168.1.1 Up 0 1 SE - 301296 Bypass-172.22.210.2-172.22.201.2 Total 2 displayed, Up 2, Down 0 mumulox@mx5t show route table inet.3 logical-system PE1 192.168.1.2 extensive inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 192.168.1.2/32 (1 entry, 1 announced) State: FlashAll *RSVP Preference: 7/1 Next hop type: Router, Next hop index: 1048577 Address: 0x2c74010 Next-hop reference count: 7 Next hop: 172.22.210.2 via ge-1/1/7.100 weight 0x1, selected Label-switched-path pe1-to-pe2 Label operation: Push 301600 Label TTL action: prop-ttl Next hop: 172.22.211.2 via ge-1/1/7.104 weight 0x8001 Label-switched-path Bypass-172.22.210.2-172.22.201.2 Label operation: Push 301472, Push 301296(top) Label TTL action: prop-ttl, prop-ttl(top) State: Active Int Local AS: 65512 Age: 4:33 Metric: 4 Task: RSVP Announcement bits (1): 1-Resolve tree 1 AS path: I After disabling the interface: mumulox@mx5t show mpls lsp extensive logical-system PE1 Ingress LSP: 1 sessions 192.168.1.2 From: 192.168.1.1, State: Dn, ActiveRoute: 0, LSPname: pe1-to-pe2 ActivePath: (none) Node/Link protection desired LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Revert timer: 1 Primary strict-path State: Dn Priorities: 7 0 OptimizeTimer: 1 SmartOptimizeTimer: 2 199 Aug 10 12:04:44.607 Deselected as active 198 Aug 10 12:04:44.607 172.22.205.1: Non-RSVP capable router detected 197 Aug 10 12:04:44.607 Link-protection Down 196 Aug 10 12:04:44.606 Session preempted 195 Aug 10 12:04:44.504 172.22.210.1: Tunnel local repaired 194 Aug 10 12:04:44.504 172.22.210.1: Down 198 Aug 10 12:04:44.607 172.22.205.1: Non-RSVP capable router detected seems to be very clear,but it is not, because all routers are rsvp enabled mumulox@mx5t show rsvp neighbor logical-system P2 RSVP neighbor: 3 learned AddressIdle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 172.22.201.1 0 13/12 23:491 84288/84248 2908 172.22.206.2 0 1/0 2d 20:02:201 92707/92707 4944 172.22.205.2 0 1/0 2d 18:30:331 92114/92114 6789 Any advice? Thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] mpls node-protection: LSP down
I've never tried to use node-protection in conjunction with a strict path - but I suspect the two features are incompatible since the protection path would disregard the strict path. Try changing the path from strict to loose. That allows some flexibility (though I believe every node in the path must be used, so it will fail if the node goes down). If you don't need to use that path, remove the primary statement on the lsp configuration. If you do need to use the strict path, configure an alternate strict path and add it as a secondary under the lsp. If you don't want it to fail back automatically then list both as secondary paths. :w On Fri, Aug 10, 2012 at 2:02 AM, Mihai Gabriel mihaigabr...@gmail.com wrote: This is the topology: http://img52.imageshack.us/img52/5512/avpn.png Sorry On Fri, Aug 10, 2012 at 11:57 AM, Mihai Gabriel mihaigabr...@gmail.comwrote: Hello, I am trying to test the node-protection feature in a lab using an MX5 router with logical-systems and I can't find the reason why is not working.The topology I use is here: http://imageshack.us/photo/my-images/849/avpn.png/ All routers are configured for mls,rsvp,ospf,link-protection, but when I disable the interface between P1 and PE1, the LSP between PE1 and PE2 goes down and stay that way: Before disabling the interface: mumulox@mx5t show mpls lsp logical-system PE1 extensive Ingress LSP: 1 sessions 192.168.1.2 From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2 ActivePath: strict-path (primary) Node/Link protection desired LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Revert timer: 1 *Primary strict-path State: Up Priorities: 7 0 OptimizeTimer: 1 SmartOptimizeTimer: 2 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.5.1(flag=0x29) 172.22.210.2(flag=9 Label=301600) 192.168.5.2(flag=0x29) 172.22.201.2(flag=9 Label=301472) 192.168.5.3(flag=0x21) 172.22.206.2(flag=1 Label=301200) 192.168.1.2(flag=0x20) 172.22.212.1(Label=3) mumulox@mx5t show mpls path strict-path logical-system PE1 Path nameAddress strict/loose if-id strict-path 172.22.210.2strictempty mumulox@mx5t show rsvp session logical-system PE1 Ingress RSVP: 2 sessions To FromState Rt Style Labelin Labelout LSPname 192.168.1.2 192.168.1.1 Up 0 1 SE - 301600 pe1-to-pe2 192.168.5.2 192.168.1.1 Up 0 1 SE - 301296 Bypass-172.22.210.2-172.22.201.2 Total 2 displayed, Up 2, Down 0 mumulox@mx5t show route table inet.3 logical-system PE1 192.168.1.2 extensive inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 192.168.1.2/32 (1 entry, 1 announced) State: FlashAll *RSVP Preference: 7/1 Next hop type: Router, Next hop index: 1048577 Address: 0x2c74010 Next-hop reference count: 7 Next hop: 172.22.210.2 via ge-1/1/7.100 weight 0x1, selected Label-switched-path pe1-to-pe2 Label operation: Push 301600 Label TTL action: prop-ttl Next hop: 172.22.211.2 via ge-1/1/7.104 weight 0x8001 Label-switched-path Bypass-172.22.210.2-172.22.201.2 Label operation: Push 301472, Push 301296(top) Label TTL action: prop-ttl, prop-ttl(top) State: Active Int Local AS: 65512 Age: 4:33 Metric: 4 Task: RSVP Announcement bits (1): 1-Resolve tree 1 AS path: I After disabling the interface: mumulox@mx5t show mpls lsp extensive logical-system PE1 Ingress LSP: 1 sessions 192.168.1.2 From: 192.168.1.1, State: Dn, ActiveRoute: 0, LSPname: pe1-to-pe2 ActivePath: (none) Node/Link protection desired LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Revert timer: 1 Primary strict-path State: Dn Priorities: 7 0 OptimizeTimer: 1 SmartOptimizeTimer: 2 199 Aug 10 12:04:44.607 Deselected as active 198 Aug 10 12:04:44.607 172.22.205.1: Non-RSVP capable router detected 197 Aug 10 12:04:44.607 Link-protection Down 196 Aug 10 12:04:44.606 Session preempted 195 Aug 10 12:04:44.504 172.22.210.1: Tunnel local repaired 194 Aug 10 12:04:44.504 172.22.210.1: Down 198 Aug 10 12:04:44.607 172.22.205.1: Non-RSVP capable router detected seems to be very clear,but it is not, because all routers are rsvp enabled mumulox@mx5t show rsvp neighbor logical-system P2 RSVP neighbor: 3 learned AddressIdle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 172.22.201.1 0 13/12 23:491 84288/84248 2908 172.22.206.2
[j-nsp] Static Route Names
People, Besides the use of groups feature on JUNOS, how can name a static route ? IOS has an option 'name' for static routes ... how can we do the same thing in junos ? Is it possible ? There is some kind of description ? Thanks a lot, Giuliano ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Static Route Names
It doesn't show up anywhere but the configuration, but what about annotate? edit routing-options static annotate route 10.0.0.0/8 insert comment here :w On Fri, Aug 10, 2012 at 8:44 AM, GIULIANO (WZTECH) giuli...@wztech.com.br wrote: People, Besides the use of groups feature on JUNOS, how can name a static route ? IOS has an option 'name' for static routes ... how can we do the same thing in junos ? Is it possible ? There is some kind of description ? Thanks a lot, Giuliano ___ 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] Selective packet mode local traffic
On 8/10/12 11:33 AM, Wayne Tucker wa...@tuckerlabs.com wrote:
You can probably achieve that using apply-path. This book has several
good examples:
http://www.juniper.net/us/en/community/junos/training-certification/day-on
e/fundamentals-series/securing-routing-engine/
:w
On Thu, Aug 9, 2012 at 7:37 AM, Mark Menzies m...@deimark.net wrote:
Yup, we can do selective packet mode using firewall filters.
Its normally applied in the input direction however, note, it needs to
be
on all interfaces where we will see packets that we dont want to send to
the flow module, ie the reply packets as well
As for a script, sadly dont have one, however if you do get one, I would
like to have a copy. :)
On 9 August 2012 15:13, Phil Mayers p.may...@imperial.ac.uk wrote:
All,
On the J-series and branch SRX, if you want to use selective packet
mode
(because you want to do IPSec at the same time as MPLS, for example)
then,
as I understand it, you need to exclude traffic *to* the box itself
from
packet mode.
Is this correct?
Does anyone have a handy op-script that will build a prefix list of all
local IPs, to help with automating this?
__**_
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.neth
er.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
Try this and see if it works/is acceptable:
+ policy-options {
+ prefix-list interfaces {
+ apply-path interfaces * unit * family inet address *;
+ }
+ }
Here's the output that you'll get (note that it will take the entire
subnet that the interface/unit is configured for):
chaynes@srx100-1# show | compare | display inheritance
[edit]
+ policy-options {
+ prefix-list interfaces {
##
## apply-path was expanded to:
## 172.16.1.0/24;
## 172.16.100.0/24;
## 10.0.0.0/24;
##
+ apply-path interfaces * unit * family inet address *;
+ }
+ }
- Clay
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Static Route Names
Annotate. It is your friend. Sent from my HTC on the Now Network from Sprint! - Reply message - From: GIULIANO (WZTECH) giuli...@wztech.com.br Date: Fri, Aug 10, 2012 11:44 am Subject: [j-nsp] Static Route Names To: juniper-nsp@puck.nether.net People, Besides the use of groups feature on JUNOS, how can name a static route ? IOS has an option 'name' for static routes ... how can we do the same thing in junos ? Is it possible ? There is some kind of description ? Thanks a lot, Giuliano ___ 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] BAJUG2
It's time for the Bay Area Juniper Users Group again. October 16th 5.30pm. Sign up for free at http://bajug.eventbrite.com Thanks, Doug ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BAJUG2
Should be a good turn out. For those of you interested and thinking about scheduling some other business in Sunnyvale so that you can attend, we had about 130 members for the first BAJUG meeting. Thanks, Doug On 8/10/12 11:11 AM, Stefan Fouant sfou...@shortestpathfirst.net wrote: On 8/10/2012 2:00 PM, Doug Hanks wrote: It's time for the Bay Area Juniper Users Group again. October 16th 5.30pm. Sign up for free at http://bajug.eventbrite.com Kudos Doug, really good stuff... maybe I'll have to schedule some training related travel to Sunnyvale so I can attend. Thanks for setting this up. -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Selective packet mode local traffic
Unless I'm missing a trick, apply-paths in a prefix list pulls the netmask in when applied to interface ips. This is ok for lo0 filters, but not those on transit interfaces. Wayne Tucker wa...@tuckerlabs.com wrote: You can probably achieve that using apply-path. This book has several good examples: http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/ -- Sent from my mobile device, please excuse brevity and typos. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Information for expected fragmentation behavior on IPsec tunnel
Greetings All, Could someone please point me in the direction of some good information for a current setup I have and would like to know what the expected behavior is. I have a site-to-site VPN setup between two SRX's. I'm in a development lab that has a static NAT out to the internet through the corporate network. (The other lab I'm connecting to is not local). Our connection to the corporate network is to an ASA that DOES NOT support jumbo frames. I have jumbo frames configured on the st0 interface and all interfaces all the way back to the hosts on my side of the network. Same goes for the lab on the other side of the tunnel. So I have 9000 bytes configured end-to-end, however the transport the tunnel is configured across only supports std 1500 bytes frames. The developers are sending 2000+ bytes sized packets that have the DF bit set (and it has to be as such for now). I am trying to determine the expected behavior. I've been told that the IPsec tunnel will fragment the traffic b/c it will not copy the DF bit from the original packet once it is encapsulated, however, I cannot ping through the tunnel with large packet sizes and the DF bit set. I've found a lot of information and have worked a lot with fragmentation, but can't find anything on this exact type of scenario. Thanks in advance for any input or information. Sincerely, Terry ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Information for expected fragmentation behavior on IPsec tunnel
It should be dependent on the df-bit setting on the VPN. I don't remember which behavior is default, but setting it to clear may do what you want. :w On Fri, Aug 10, 2012 at 12:36 PM, Terry Jones terry.jo...@war-eagle.me wrote: Greetings All, Could someone please point me in the direction of some good information for a current setup I have and would like to know what the expected behavior is. I have a site-to-site VPN setup between two SRX's. I'm in a development lab that has a static NAT out to the internet through the corporate network. (The other lab I'm connecting to is not local). Our connection to the corporate network is to an ASA that DOES NOT support jumbo frames. I have jumbo frames configured on the st0 interface and all interfaces all the way back to the hosts on my side of the network. Same goes for the lab on the other side of the tunnel. So I have 9000 bytes configured end-to-end, however the transport the tunnel is configured across only supports std 1500 bytes frames. The developers are sending 2000+ bytes sized packets that have the DF bit set (and it has to be as such for now). I am trying to determine the expected behavior. I've been told that the IPsec tunnel will fragment the traffic b/c it will not copy the DF bit from the original packet once it is encapsulated, however, I cannot ping through the tunnel with large packet sizes and the DF bit set. I've found a lot of information and have worked a lot with fragmentation, but can't find anything on this exact type of scenario. Thanks in advance for any input or information. Sincerely, Terry ___ 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] Information for expected fragmentation behavior on IPsec tunnel
The default is actually to clear the df-bit, which I have verified on the srx, however, if this is case, then the traffic should be fragmenting when I ping with large packets setting the df-bit. This setting should stay within the encapsulated packet and then the outer ipsec packet is set to clear and the packet should be fragmenting, which is it not. I've opened a JTAC case, so we'll see what they say. tjones@srx1-net04 show security ipsec security-associations index 131073 node0: -- ID: 131073 Virtual-system: root, VPN Name: Denver-CN Local Gateway: a.a.a.a, Remote Gateway: b.b.b.b Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) Version: IKEv1 DF-bit: clear Bind-interface: st0.3 Direction: inbound, SPI: 7075d78, AUX-SPI: 0 , VPN Monitoring: UP Hard lifetime: Expires in 3529 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2973 seconds Mode: Tunnel(10 10), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc Anti-replay service: counter-based enabled, Replay window size: 64 Direction: outbound, SPI: 2acb634b, AUX-SPI: 0 , VPN Monitoring: UP Hard lifetime: Expires in 3529 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2973 seconds Mode: Tunnel(10 10), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc Anti-replay service: counter-based enabled, Replay window size: 64 Thanks, Terry -Original Message- From: Wayne Tucker [mailto:wa...@tuckerlabs.com] Sent: Friday, August 10, 2012 1:59 PM To: Terry Jones Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Information for expected fragmentation behavior on IPsec tunnel It should be dependent on the df-bit setting on the VPN. I don't remember which behavior is default, but setting it to clear may do what you want. :w On Fri, Aug 10, 2012 at 12:36 PM, Terry Jones terry.jo...@war-eagle.me wrote: Greetings All, Could someone please point me in the direction of some good information for a current setup I have and would like to know what the expected behavior is. I have a site-to-site VPN setup between two SRX's. I'm in a development lab that has a static NAT out to the internet through the corporate network. (The other lab I'm connecting to is not local). Our connection to the corporate network is to an ASA that DOES NOT support jumbo frames. I have jumbo frames configured on the st0 interface and all interfaces all the way back to the hosts on my side of the network. Same goes for the lab on the other side of the tunnel. So I have 9000 bytes configured end-to-end, however the transport the tunnel is configured across only supports std 1500 bytes frames. The developers are sending 2000+ bytes sized packets that have the DF bit set (and it has to be as such for now). I am trying to determine the expected behavior. I've been told that the IPsec tunnel will fragment the traffic b/c it will not copy the DF bit from the original packet once it is encapsulated, however, I cannot ping through the tunnel with large packet sizes and the DF bit set. I've found a lot of information and have worked a lot with fragmentation, but can't find anything on this exact type of scenario. Thanks in advance for any input or information. Sincerely, Terry ___ 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
