2011年12月23日 星期五

DOM Digital Optical Monitoring

 

The DOM is only applied on new SFP (SFP-GE-S/L) and not on old SFP(GLC-SX-MM/GLC-LH-SM). Below are the description of DOM found from wiki.

Digital diagnostics monitoring

Modern optical SFP transceivers support digital diagnostics monitoring (DDM) functions according to the industry-standard SFF-8472. This feature is also known as digital optical monitoring (DOM). This feature gives the end user the ability to monitor real-time parameters of the SFP, such as optical output power, optical input power, temperature, laser bias current, and transceiver supply voltage.

2011年8月24日 星期三

HSRPv2

 

Hot Standby Router Protocol Version 2


The Hot Standby Router Protocol (HSRP) Version 2 feature was introduced to prepare for further enhancements and to expand the capabilities beyond what is possible with HSRP version 1. HSRP version 2 has a different packet format than HSRP version 1.

 

Restrictions for HSRP Version 2

HSRP version 2 is not available for ATM interfaces running LAN emulation.

HSRP version 2 will not interoperate with HSRP version 1. An interface cannot operate both version 1 and version 2 because both versions are mutually exclusive. However, the different versions can be run on different physical interfaces of the same router. You cannot change from version 2 to version 1 if you have configured groups above the group number range allowed for version 1 (0 to 255).

 

HSRP Version 2 Feature Design

HSRP version 2 is designed to address the following issues relative to HSRP version 1:

Previously, millisecond timer values are not advertised or learned. HSRP version 2 advertises and learns millisecond timer values. This change ensures stability of the HSRP groups in all cases.

Group numbers are restricted to the range from 0 to 255. HSRP version 2 expands the group number range from 0 to 4095.

HSRP version 2 provides improved management and troubleshooting. With HSRP version 1, there is no method to identify from HSRP active hello messages which physical router sent the message because the source MAC address is the HSRP virtual MAC address. The HSRP version 2 packet format includes a 6-byte identifier field that is used to uniquely identify the sender of the message. Typically, this field is populated with the interface MAC address.

The multicast address 224.0.0.2 is used to send HSRP hello messages. This address can conflict with Cisco Group Management Protocol (CGMP) leave processing.

Version 1 is the default version of HSRP.

HSRP version 2 uses the new IP multicast address 224.0.0.102 to send hello packets instead of the multicast address of 224.0.0.2, which is used by version 1. This new multicast address allows CGMP leave processing to be enabled at the same time as HSRP.

HSRP version 2 permits an expanded group number range, 0 to 4095, and consequently uses a new MAC address range 0000.0C9F.F000 to 0000.0C9F.FFFF. The increased group number range does not imply that an interface can, or should, support that many HSRP groups. The expanded group number range was changed to allow the group number to match the VLAN number on subinterfaces.

When the HSRP version is changed, each group will reinitialize because it now has a new virtual MAC address.

HSRP version 2 has a different packet format than HSRP version 1. The packet format uses a type-length-value (TLV) format. HSRP version 2 packets received by an HSRP version 1 router will have the type field mapped to the version field by HSRP version 1 and subsequently ignored.

Generate RSA key pair

 

router1(config)#crypto key generate rsa modulus 1024

The above command generate 2 sets of key-pair by default

router1#sh crypto key mypubkey rsa
% Key pair was generated at: 00:33:47 UTC Mar 1 2002
Key name: router1.test.com ==> Key#1 general purpose key
Storage Device: not specified
Usage: General Purpose Key
Key is not exportable.
Key Data:
  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00BD2FEC
  2D84B376 4A3B40E1 23D093EF 787612E2 8056A542 AF940046 7B7CAF77 66F1602B
  B691F96A F77357E5 EEF0B390 FF7A5967 7A46ABFC 8209EF33 79928A75 60029D49
  D08AF484 86D3D46C 4DF98BE9 58F25EB4 9571B416 DD743A97 A9E70D3D 78A865A8
  5FC212A6 B05A56E6 735F7DE7 AF984687 FE76BB09 C879992D 73A02849 A7020301 0001
% Key pair was generated at: 00:33:48 UTC Mar 1 2002
Key name: router1.test.com.server ==> Key#2 used for SSH server
Temporary key
Usage: Encryption Key
Key is not exportable.
Key Data:
  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00BA3B8F 741F507A
  65EE725A 11C10CA8 7C81AB2E 4916AE80 61DF5FB5 8E395926 AAC3C463 73CFEDB0
  52B744A8 A3FC83FE 7C4EC409 7888E99E AD8FF386 7A51EC89 EDD06228 0C7BE942
  FA73A850 4B1C4ACC FD746976 500F319A 3E6892C0 EE054BF5 BF020301 0001

2011年8月11日 星期四

Reviewing IPv6


Latest RFC for IP Version 6 Addressing Architecture, RFC4291
Unique Local IPv6 Unicast Addresses, RFC4193
Neighbor Discovery, RFC4861 Stateless Address Autoconfiguration, RFC4862
Some useful addressing info to know.


2.4.  Address Type Identification

The type of an IPv6 address is identified by the high-order bits of
the address, as follows:

Address type         Binary prefix        IPv6 notation   Section
------------         -------------        -------------   -------
Unspecified          00...0  (128 bits)   ::/128          2.5.2
Loopback             00...1  (128 bits)   ::1/128         2.5.3
Multicast            11111111             FF00::/8        2.7
Link-Local unicast   1111111010           FE80::/10       2.5.6
Global Unicast       (everything else)


2.5.4.  Global Unicast Addresses

The general format for IPv6 Global Unicast addresses is as follows:

|         n bits         |   m bits  |       128-n-m bits         |
+------------------------+-----------+----------------------------+
| global routing prefix  | subnet ID |       interface ID         |
+------------------------+-----------+----------------------------+


2.5.5.  IPv6 Addresses with Embedded IPv4 Addresses

Two types of IPv6 addresses are defined that carry an IPv4 address in
the low-order 32 bits of the address.  These are the "IPv4-Compatible
IPv6 address" and the "IPv4-mapped IPv6 address".


2.5.5.1.  IPv4-Compatible IPv6 Address(deprecated)

The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6
transition.  The format of the "IPv4-Compatible IPv6 address" is as
follows:

|                80 bits               | 16 |      32 bits        |
+--------------------------------------+--------------------------+
|0000..............................0000|0000|    IPv4 address     |
+--------------------------------------+----+---------------------+


2.5.5.2.  IPv4-Mapped IPv6 Address

A second type of IPv6 address that holds an embedded IPv4 address is
defined.  This address type is used to represent the addresses of
IPv4 nodes as IPv6 addresses.  The format of the "IPv4-mapped IPv6
address" is as follows:



|                80 bits               | 16 |      32 bits        |
+--------------------------------------+--------------------------+
|0000..............................0000|FFFF|    IPv4 address     |
+--------------------------------------+----+---------------------+


2.5.6.  Link-Local IPv6 Unicast Addresses

Link-Local addresses are for use on a single link.  Link-Local
addresses have the following format:

|   10     |
|  bits    |         54 bits         |          64 bits           |
+----------+-------------------------+----------------------------+
|1111111010|           0             |       interface ID         |
+----------+-------------------------+----------------------------+


2.5.7.  Site-Local IPv6 Unicast Addresses

Site-Local addresses were originally designed to be used for
addressing inside of a site without the need for a global prefix.
Site-local addresses are now deprecated as defined in [SLDEP].

Site-Local addresses have the following format:

|   10     |
|  bits    |         54 bits         |         64 bits            |
+----------+-------------------------+----------------------------+
|1111111011|        subnet ID        |       interface ID         |
+----------+-------------------------+----------------------------+


2.6.  Anycast Addresses

An IPv6 anycast address is an address that is assigned to more than
one interface (typically belonging to different nodes), with the
property that a packet sent to an anycast address is routed to the
"nearest" interface having that address, according to the routing
protocols' measure of distance.


2.7.  Multicast Addresses

An IPv6 multicast address is an identifier for a group of interfaces
(typically on different nodes).  An interface may belong to any
number of multicast groups.  Multicast addresses have the following
format:

|   8    |  4 |  4 |                  112 bits                   |
+------ -+----+----+---------------------------------------------+
|11111111|flgs|scop|                  group ID                   |
+--------+----+----+---------------------------------------------+

binary 11111111 at the start of the address identifies the address
as being a multicast address.

+-+-+-+-+
flgs is a set of 4 flags:     |0|R|P|T|
+-+-+-+-+

The high-order flag is reserved, and must be initialized to 0.

T = 0 indicates a permanently-assigned ("well-known") multicast
address, assigned by the Internet Assigned Numbers Authority
(IANA).

T = 1 indicates a non-permanently-assigned ("transient" or
"dynamically" assigned) multicast address.

The P flag's definition and usage can be found in [RFC3306].

The R flag's definition and usage can be found in [RFC3956].

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.  The values are as follows:

0  reserved
1  Interface-Local scope
2  Link-Local scope
3  reserved
4  Admin-Local scope
5  Site-Local scope
6  (unassigned)
7  (unassigned)
8  Organization-Local scope
9  (unassigned)
A  (unassigned)
B  (unassigned)
C  (unassigned)
D  (unassigned)
E  Global scope
F  reserved

Interface-Local scope spans only a single interface on a node
and is useful only for loopback transmission of multicast.

Link-Local multicast scope spans the same topological region as
the corresponding unicast scope.

Admin-Local scope is the smallest scope that must be
administratively configured, i.e., not automatically derived
from physical connectivity or other, non-multicast-related
configuration.

Site-Local scope is intended to span a single site.

Organization-Local scope is intended to span multiple sites
belonging to a single organization.

scopes labeled "(unassigned)" are available for administrators
to define additional multicast regions.

group ID identifies the multicast group, either permanent or
transient, within the given scope.  Additional definitions of the
multicast group ID field structure are provided in [RFC3306].


   The "meaning" of a permanently-assigned multicast address is
independent of the scope value.  For example, if the "NTP servers
group" is assigned a permanent multicast address with a group ID of
101 (hex), then

FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
(i.e., the same node) as the sender.

FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
sender.

FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
sender.

FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet.

Non-permanently-assigned multicast addresses are meaningful only
within a given scope.  For example, a group identified by the non-
permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
site bears no relationship to a group using the same address at a
different site, nor to a non-permanent group using the same group ID
with a different scope, nor to a permanent group with the same group
ID.

Multicast addresses must not be used as source addresses in IPv6
packets or appear in any Routing header.

Routers must not forward any multicast packets beyond of the scope
indicated by the scop field in the destination multicast address.

Nodes must not originate a packet to a multicast address whose scop
field contains the reserved value 0; if such a packet is received, it
must be silently dropped.  Nodes should not originate a packet to a
multicast address whose scop field contains the reserved value F; if
such a packet is sent or received, it must be treated the same as
packets destined to a global (scop E) multicast address.

2.7.1.  Pre-Defined Multicast Addresses

The following well-known multicast addresses are pre-defined.  The
group IDs defined in this section are defined for explicit scope
values.

Use of these group IDs for any other scope values, with the T flag
equal to 0, is not allowed.



Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0

The above multicast addresses are reserved and shall never be
assigned to any multicast group.

All Nodes Addresses:    FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1

The above multicast addresses identify the group of all IPv6 nodes,
within scope 1 (interface-local) or 2 (link-local).

All Routers Addresses:   FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
FF05:0:0:0:0:0:0:2

The above multicast addresses identify the group of all IPv6 routers,
within scope 1 (interface-local), 2 (link-local), or 5 (site-local).

Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX

Solicited-Node multicast address are computed as a function of a
node's unicast and anycast addresses.  A Solicited-Node multicast
address is formed by taking the low-order 24 bits of an address
(unicast or anycast) and appending those bits to the prefix
FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
range

FF02:0:0:0:0:1:FF00:0000

to

FF02:0:0:0:0:1:FFFF:FFFF



For example, the Solicited-Node multicast address corresponding to
the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
addresses that differ only in the high-order bits (e.g., due to
multiple high-order prefixes associated with different aggregations)
will map to the same Solicited-Node address, thereby reducing the
number of multicast addresses a node must join.

A node is required to compute and join (on the appropriate interface)
the associated Solicited-Node multicast addresses for all unicast and
anycast addresses that have been configured for the node's interfaces
(manually or automatically).


2.8.  A Node's Required Addresses

A host is required to recognize the following addresses as
identifying itself:

o Its required Link-Local address for each interface.

o Any additional Unicast and Anycast addresses that have been
configured for the node's interfaces (manually or
automatically).

o The loopback address.

o The All-Nodes multicast addresses defined in Section 2.7.1.

o The Solicited-Node multicast address for each of its unicast and
anycast addresses.

o Multicast addresses of all other groups to which the node
belongs.

A router is required to recognize all addresses that a host is
required to recognize, plus the following addresses as identifying
itself:

o The Subnet-Router Anycast addresses for all interfaces for which
it is configured to act as a router.

o All other Anycast addresses with which the router has been
configured.

o The All-Routers multicast addresses defined in Section 2.7.1.

2011年8月10日 星期三

Juniper Network Connect upgraded from 6.x to 7.x

 

Notice my SSLVPN client is upgraded today, but seems the newer version has some issue with it.

It will not be loaded completely and stuck in a page with error status, added the VPN link into trusted sites list under IE setting and it fixed the problem.

Internet Option –> Security –> Trusted sites –> Sites –> Add –> Close. Then reload the page and it fly.

2011年8月8日 星期一

VitalQIP DHCP configuration convention

 


Address types




  1. Static


  2. Dynamic (used for dynamic assignment pool)


  3. Reserved



Object Classes




  1. Router (i.e.. default-gw or standby ip of HSRP. There should be only one per subnet, otherwise you will see multiple networks available from windows network configuration)


  2. Switch (i.e.. Vlan IP of MDF, IDF switches)


  3. WAP (wireless AP)


  4. PC/Workstation (general nodes of dhcp client)


  5. Other (IP Phones)


  6. Server





Status



Status depends on the Address types you choose when defining the scope.




  1. Unused (scope to be defined)


  2. Static (fixed config of IP address)


  3. Dynamic



    1. Manual-BOOTP


    2. Automatic-BOOTP


    3. Manual-DHCP (IP+MAC binding)


    4. Automatic-DHCP (Permanent lease)


    5. Dynamic-DHCP (Limited lease)




 



RFC2131 - DHCP allocation types



DHCP supports three mechanisms for IP address allocation.  In "automatic allocation", DHCP assigns a permanent IP address to a client.  


In "dynamic allocation", DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address).  


In "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client.  A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.

2011年2月19日 星期六

WCCP on ASA

Guidelines and Limitations

Supported WCCP Features

The following WCCPv2 features are supported with the adaptive security appliance:

Redirection of multiple TCP/UDP port-destined traffic.

Authentication for cache engines in a service group.

Unsupported WCCP Features

The following WCCPv2 features are not supported with the adaptive security appliance:

Multiple routers in a service group is not supported. Multiple Cache Engines in a service group is still supported.

Multicast WCCP is not supported.

The Layer 2 redirect method is not supported; only GRE encapsulation is supported.

WCCP source address spoofing is not supported.

WAAS devices are not supported.

WCCP Interaction With Other Features

In the adaptive security appliance implementation of WCCP, the following applies as to how the protocol interacts with other configurable features:

Cut-through proxy will not work in combination with WCCP.

An ingress access list entry always takes higher priority over WCCP. For example, if an access list does not permit a client to communicate with a server then traffic will not be redirected to a cache engine. Both ingress interface access lists and egress interface access lists will be applied.

TCP intercept, authorization, URL filtering, inspect engines, and IPS features are not applied to a redirected flow of traffic.

When a cache engine cannot service a request and packet is returned, or when a cache miss happens on a cache engine and it requests data from a web server, then the contents of the traffic flow will be subject to all the other configured features of the adaptive security appliance.

In failover, WCCP redirect tables are not replicated to standby units. After a failover, packets will not be redirected until the tables are rebuilt. Sessions redirected prior to failover will likely be reset by the web server.

If you have two WCCP services and they use two different redirection ACLs that overlap and match the same packets (with a deny or a permit action), the packets behave according to the first service-group found and installed rules. The packets are not passed thorugh all service-groups.

 

Reference: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_wccp.html