Junos OS [12.1X46-D15.3]

I'm taking the  plunge and upgrade a lab SRX to the latest build. I will look at some  improvement to various features.

The upgrade process  to  junos 12.1X46-D15.3 is simple. And after pushing new code to juniper SRX for testing , we will roll out  this release across the various SRXs that we have deployed.

You can find more about this release at the below URL

http://www.juniper.net/techpubs/en_US/junos12.1x46/information-products/topic-collections/release-notes/12.1x46/index.html

 

 

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

Protection from rouge RA advertisements cisco

Cisco  has a feature simply called ipv6 nd raguard.

RAguard allows for you to inspect and drop route-advertisements from  rouge devices.  This security feature protects SLACC enabled clients from picking up rogue gateways.

We will explore a very basic  configuration that I have used for  access-layer security,


1st

The topology

2nd


The Ipv6 router-configuration for the 6509 cisco ;

NOTE: I decreased the  rt-advertisement to speed up debug log messages for this blog RT-ADV interval  will be 4 seconds


3rd


The local switch RAguard policies for this blog ;

Let stop explain the RAguard policies that I've configured.

The policy named " ROUTER-RA" will be applied to a router-port , where as  " CLIENT-RA" will be applied to all other ports.

 ROUTER-RA has the inspection activities of what we want to expect.


CLIENT-RA has a single prefix-list with a deny any.

The device-role has been set to a " host ",  so the port should not expect any Route-Advertisement. I also applied a prefix-list matching clientports as a safeguard if one should  accidently change the device-role.


ROUTER-RA policy  has a prefix-list name test1 which matches the prefix of 2001:db8:98::/64 , & that we want our  clients in vlan 298 to receive

I created a 2nd prefix-list named  test2,  which we  will use to demonstrate the drop action upon receipt of a prefix that doesn't match the 2001:db8:97::/64.

On the access-switch we can monitor the RA guard in action via the following debug command;

debug ipv6 snooping raguard 
term mon
 

4th

Applying the  policy to ports  gi 1/0/1-48 ( clients ) ,  and our uplink ports gi 1/0/49-52 ( routers );

 

Okay now for the fun :)

With the match prefix-list test2 ( 2001:db8:97::/64 ) , we can clearly see that RAguard in action dropping the offender prefix of  2001:db8:98::/64

If we change the match prefix to the test1 ( 2001:db8:98::/64 ), we will find the  RAguard will now allow the prefix that we have defined. We can also see that a client has gathered a ipv6 address from that prefix in the route-advertisement.

NOT E: btw, if a client-access-port receives a Route-Advertisement and with the device-role of  "host", this is the message  you will see.

Ken Felix
Freelance Network/Security Engineer
kfelix -a-t  socpuppets-d-o-t- com

Juniper SRX neighbor-ship-protocol

In this post we will see how easy it's to enable ipv6  Route-advertisement  via NDP on a Juniper SRX.

1st 

The topology;

The ipv6  firewall has two ipv6  defined  /64 prefixes of  2001.db8:{98-99}::/64 and we will set these up for basic route  advertisement for SLACC ipv6  enable clients.


2nd


The interface has to be configured for address within  the prefix that we will advertise;

3rd


We now have to enable neighbor-ship protocol & define the prefixes for advertisement;

NOTE:  full config  see the arrow and blue oval

Lastly


We can validate that ipv6 SLACC clients can receive the prefixes as shown with my macbook;

NOTE: The arrows show our privacy and EOUI-64 ipv6  addresses

Ken Felix

Freelance Network / Security Engineer Consultant

kfelix  ----a---t---socpuppets ---d---o---t---com

         ^         ^

=(   <@> <@>   )=

              o

           /     \

ssh pub-key on cisco 15.x

Cisco has a feature for the importation of  ssh pub-keys within the 15.x codeset

This helps greatly if you have scripts that perform backups or  automatic tasks and you don't want to  be challenge for passwords.

What I found out by accident and just recently, you don't really need a local account define if your using ssh  pub-key and have defined the users within this pub-key configuration.

To implement ssh pub-keys access is quite simple.


1st 

You  must have a ssh pub-key created.

You have a host of tools from putty for  generating ssh keys. Most unixes have a means for generation of the keys also. I will demonstrate this via  Unix  and with the cli cmd  ssh-keygen

The ssh-keygen command generates  2 files;

The id_rsa ( the larger sized file ) is your private key. It stays private and you never share it out with anybody.

The id_rsa.pub  ( the smaller  of the key pair ) is your public-key

2nd 

Next with the key we can now add this to our  cisco configuration via the following command;

ip ssh pub-key
   username  kfelix 
      key-string 
          ( paste your key in here starting at the ssh-rsa to the end of the key as shown in your pub filename )
exit

3rd

The cisco will decode and hash the pub-key into a string for security purpose.

NOTE: the public-key is never stored in the raw

Now we can login with no challenges. This is great for backup scripts of scripts that are executed via cron jobs.


The disadvantage of using the pre-installed ssh pub-key approach ;

•      if your pub-key is compromised that person has access to all devices that has your pub key installed

•      if a machine has multiple users and multiple super-users, they can acquire access on your behalf using your ssh pubkey

•      if you need to change installed pub-keys, you have to touch X amount of devices which could be a hassle in a big enterprise network and multiple devices

•     I have not been successful with installing a  rsa pubkey and with a size greater than 1298 bits YMMV

•     you can't use “dsa” of  “ecdsa”  types

NOTE2: A single defined user can have upto 2 pub-key  installed. Great if you have redundant soc/noc operations centers.

e.g

Ken Felix
Freelance Network/Security Engineer
kfelix -a-t  socpuppets-d-o-t- com

Enabling Jumbo Frames on a Cisco Nexus 3548

In this blog we will demostrate a basic network-qos policy type  for enabling support of jumbo frames in a nexus switch.


1st, The switch model and software

system:    version 6.0(2)A1(1b)
cisco Nexus 3548 Chassis ("48x10GE Supervisor")


To enable jumbo frames you first need to build a policy. The name of the policy can be anything that you want it to be.

policy-map type network-qos jumboframes
  class type network-qos class-default
    mtu 9216


After you have defined the policy-map you can now activate it via the following ;


system qos
  service-policy type network-qos jumboframes

To monitor the changes we issues the following commands ;


HETYSW2# show queuing interface ether 1/12 | grep MTU
    HW MTU: 9216 (9216 configured)
HETYSW2#

We can also look at the interface counters, but  I believe the switch  doesn't report packets bigger than 1548 bytes;


e.g


show int eth 1/12  counters  detailed
Ethernet1/12
  Rx Packets:                                    99810475
  Rx Unicast Packets:                            99567164
  Rx Multicast Packets:                            244586
  Rx Broadcast Packets:                               108
  Rx Bytes:                                   10238006362
  Rx Packets from 0 to 64 bytes:                  1111204
  Rx Packets from 65 to 127 bytes:               75378834
  Rx Packets from 128 to 255 bytes:              14313107
  Rx Packets from 256 to 511 bytes:               2618278
  Rx Packets from 512 to 1023 bytes:              2467560
  Rx Packets from 1024 to 1518 bytes:             2493491
  Rx Packets from 1519 to 1548 bytes:             1429384   <------HERE

   Tx Packets:                                   116271700
  Tx Unicast Packets:                           115850055
  Tx Multicast Packets:                            421292
  Tx Broadcast Packets:                               353
  Tx Bytes:                                   16564798171
  Tx Packets from 0 to 64 bytes:                 16577055
  Tx Packets from 65 to 127 bytes:               68013570
  Tx Packets from 128 to 255 bytes:              21122812
  Tx Packets from 256 to 511 bytes:               3376787
  Tx Packets from 512 to 1023 bytes:              3864588
  Tx Packets from 1024 to 1518 bytes:             3295462
  Tx Packets from 1519 to 1548 bytes:               21426   <------HERE

and


show int eth 1/12  counters   errors

--------------------------------------------------------------------------------
Port          Align-Err    FCS-Err   Xmit-Err    Rcv-Err  UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth1/12                0          0          0          0          0           0

--------------------------------------------------------------------------------
Port         Single-Col  Multi-Col   Late-Col  Exces-Col  Carri-Sen       Runts
--------------------------------------------------------------------------------
Eth1/12                0          0          0          0          0           0

--------------------------------------------------------------------------------
Port          Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err
--------------------------------------------------------------------------------
Eth1/12             0          --           0           0           0          0


Alternatively  you can review the  network-qos policy-map to confirm  mtu sizes the default and current size are shown ;


show policy-map  type network-qos


  Type network-qos policy-maps
  ===============================

  policy-map type network-qos jumboframes
    class type network-qos class-default

      mtu 9216
  policy-map type network-qos default-nq-policy
    class type network-qos class-default

      mtu 1500 

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(   ^   ^  )=

          o

       /     \

Juniper SRX interfaces types

Juniper has specific  interfaces name types for the SRX firewall.

Interfaces can be seen as virtual or real. Virtual will include anything from a vlan to loopback , and real are real-interfaces from usb modems to ethernet interfaces.

here's a table and brief summary of just some of the interfaces types you will find in a SRX;

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(   ^   ^  )=

          o

       /     \

A quick review of some common transceiver types

Cisco has support numerous transceivers over the course of 15 plus years. Starting with the now obsolete GBIC ( gigabit interface connector )  & other vendor specific interfaces, to the more common SFP, which  also known incorrect as mini-GBIC.  Due to this, a lot of confusion has developed over the various types. We will look at the modern common type & what you will find from something as simple as campus/data switch or a backbone/border router.


The following  photo  from left to right,  shows the following transceiver styles;

Xenpak2, XFP and a mix of  optic SFP/SFP+  interfaces adapters

NOTE: The Xenpak2 ( aka X2 )  are  the 2nd generation of the Xenpak. A Xenpak was support by a few linecard in the CRS , 6500/7600,  and then Xenpak2 (aka X2 ) within the  4500/4900//6500/7600 series of cisco devices and is much shorter than than a Xenpak physically. Don't confuse the two. Both take a SC fiber connector, the SFP+ is used   where the requirement exists for   >4gbps  interfaces.

NOTE: SFP+ is a enhancement to the SFP and offer data rates up to 11 gbps ( 10gbps optics actually runs closer to 11gbps due to line encoding ). A SFP and SFP+ are physically the same size but not all devices supports a SFP+ and 10gig line rate. Both takes a LC type of fiber connector.

Copper SFP various types

Their also few other  interface such as CFP & CXP,  which is primarily used for 40/100Gbps interfaces. It's much wider in size and only the top carrier grade equipment offers  interfaces for CFP or CXP. You will not see too much of these types.

Most of these  optics and transceivers are made overseas & with finisar being the most  common manufacture. You can find more about finisar at http://www.finisar.com/

BTW, if you interested in buying the domains 40/100/1000 gige.net/com, I have this domains available for sale.

Both the 40/100 gige-based interfaces are becoming more and more available,  and is what the future holds. Contact me for more information, or to make an offer for these domains.

Ken Felix

Freelance Network / Security Engineer Consultant

kfelix  ----a---t---socpuppets ---d---o---t---com

         ^         ^

=(   <@> <@>   )=

              o

           /     \