It’s hard to visit an IT journal web site without stumbling upon an SDN fairy tale. Here’s another one:
The idea is to cut away the manual process of setting up new firewalls, load balancers and other network appliances, and instead open the door to provisioning a new network infrastructure within a few minutes.
And why exactly is it that you can’t do that today?
Read more ...This is a new one on me – obviously I’ve not been paying much attention since it has been around since 10.2!
On 12.1X45-D15.5 the counters for packets/bytes all show zero, but at least you can see that your tunnel is up and what the various parameters in use are… See below:
imtech@srx650-1-POD1> show security flow session tunnel extensive Session ID: 38046, Status: Normal Flag: 0x10000 Policy name: N/A Source NAT pool: Null Dynamic application: junos:UNKNOWN, Maximum timeout: N/A, Current timeout: N/A Session State: Valid Start time: 105905, Duration: 52592 In: 10.1.0.9/49698 --> 10.1.0.1/27622;esp, Interface: ge-2/0/13.0, Session token: 0xa, Flag: 0x100621 Route: 0x110010, Gateway: 10.1.0.2, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 0, Bytes: 0 Session ID: 38047, Status: Normal Flag: 0x10000 Policy name: N/A Source NAT pool: Null Dynamic application: junos:UNKNOWN, Maximum timeout: N/A, Current timeout: N/A Session State: Valid Start time: 105905, Duration: 52592 In: 10.1.0.9/0 --> 10.1.0.1/0;esp, Interface: ge-2/0/13.0, Session token: 0xa, Flag: 0x621 Route: 0x110010, Gateway: 10.1.0.2, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 0, Bytes: 0 Total sessions: 2
This is a new one on me – obviously I’ve not been paying much attention since it has been around since 10.2!
On 12.1X45-D15.5 the counters for packets/bytes all show zero, but at least you can see that your tunnel is up and what the various parameters in use are… See below:
imtech@srx650-1-POD1> show security flow session tunnel extensive Session ID: 38046, Status: Normal Flag: 0x10000 Policy name: N/A Source NAT pool: Null Dynamic application: junos:UNKNOWN, Maximum timeout: N/A, Current timeout: N/A Session State: Valid Start time: 105905, Duration: 52592 In: 10.1.0.9/49698 --> 10.1.0.1/27622;esp, Interface: ge-2/0/13.0, Session token: 0xa, Flag: 0x100621 Route: 0x110010, Gateway: 10.1.0.2, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 0, Bytes: 0 Session ID: 38047, Status: Normal Flag: 0x10000 Policy name: N/A Source NAT pool: Null Dynamic application: junos:UNKNOWN, Maximum timeout: N/A, Current timeout: N/A Session State: Valid Start time: 105905, Duration: 52592 In: 10.1.0.9/0 --> 10.1.0.1/0;esp, Interface: ge-2/0/13.0, Session token: 0xa, Flag: 0x621 Route: 0x110010, Gateway: 10.1.0.2, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 0, Bytes: 0 Total sessions: 2
Just came across a useful debugging guide for site-to-site IPSec VPNs on Juniper SRX. It is a bit confusing because in steps 2 and 3, where it says [LOCAL PEER IP] it should actually say [REMOTE PEER IP]. But otherwise, this is a very useful set of instructions.
It doesn’t mention that you should observe the lifetime of the IKE and IPSec security associations, and also keep an eye on the SA index or ID. If the index number keeps changing, it means your tunnel is going down and coming back up all the time. If the lifetime regularly starts again at the maximum value and does not count down to zero steadily, this indicates the same thing.
Particularly interesting is the way the author splits out the sections on troubleshooting the packet flow within the VPN, versus the packet flow of the VPN crypto itself. I’ve not used packet-filters in flow debug before, so will definitely be trying that out.
Link to SRX debug article at fir3net.com
Just came across a useful debugging guide for site-to-site IPSec VPNs on Juniper SRX. It is a bit confusing because in steps 2 and 3, where it says [LOCAL PEER IP] it should actually say [REMOTE PEER IP]. But otherwise, this is a very useful set of instructions.
It doesn’t mention that you should observe the lifetime of the IKE and IPSec security associations, and also keep an eye on the SA index or ID. If the index number keeps changing, it means your tunnel is going down and coming back up all the time. If the lifetime regularly starts again at the maximum value and does not count down to zero steadily, this indicates the same thing.
Particularly interesting is the way the author splits out the sections on troubleshooting the packet flow within the VPN, versus the packet flow of the VPN crypto itself. I’ve not used packet-filters in flow debug before, so will definitely be trying that out.
Link to SRX debug article at fir3net.com
Introduction
From my last post on PIM BiDir I got some great comments from my friend Peter Palúch. I still had some concepts that weren’t totally clear to me and I don’t like to leave unfinished business. There is also a lack of resources properly explaining the behavior of PIM BiDir. For that reason I would like to clarify some concepts and write some more about the potential gains of PIM BiDir is. First we must be clear on the terminology used in PIM BiDir.
Terminology
Rendezvous Point Address (RPA) – The RPA is an address that is used as the root of the distribution tree for a range of multicast groups. This address must be routable in the PIM domain but does not have to reside on a physical interface or device.
Rendezvous Point Link (RPL) – It is the physical link to which the RPA belongs. The RPL is the only link where DF election does not take place. The RFC also says “In BIDIR-PIM, all multicast traffic to groups mapping to a specific RPA is forwarded on the RPL of that RPA.” In some scenarios where the RPA is virtual, there may not be an RPL though.
Tom Waechter steps down from the newly minted company.
B2B email scams are all the rage.
Not sure why this command has to be so obscure, but I stumbled on this while writing a training course tonight – quite a nice way to see if packets are hitting your policies:
imtech@srx220-1-POD3> show security policies hit-count Logical system: root-logical-system Index From zone To zone Name Policy count 1 VR3a VR3b P1 0 2 VR3a untrust 3to1VPN 8320 3 VR3a untrust P1 3249 4 VR3b VR3a P1 0 5 VR3b untrust P1 0 6 untrust junos-host P1 8 7 untrust VR3a 1to3 5523 8 untrust VR3a P1 5 9 untrust VR3b permit-to-3b 0 10 untrust VR3b DEFAULT-DENY 16
Not sure why this command has to be so obscure, but I stumbled on this while writing a training course tonight – quite a nice way to see if packets are hitting your policies:
imtech@srx220-1-POD3> show security policies hit-count Logical system: root-logical-system Index From zone To zone Name Policy count 1 VR3a VR3b P1 0 2 VR3a untrust 3to1VPN 8320 3 VR3a untrust P1 3249 4 VR3b VR3a P1 0 5 VR3b untrust P1 0 6 untrust junos-host P1 8 7 untrust VR3a 1to3 5523 8 untrust VR3a P1 5 9 untrust VR3b permit-to-3b 0 10 untrust VR3b DEFAULT-DENY 16