Configure FTP in Windows IIS

How to setup FTP in windows IIS

You can use Isolate Users Mode in IIS 6

In IIS 5, you can use NTFS permissions to archive above

Virtual Directory can be used to differentiate user's Home Directory (where alias reference to the username)

Very good IIS FTP article

NAT Virtual Interface

The NAT Virtual Interface (NVI) feature removes the requirement to configure an interface as either Network Address Translation (NAT) inside or NAT outside. An interface can be configured to use NAT or not use NAT.

NVI allows traffic between overlapped VPN routing/forwarding (VRFs) in the same Provider Edge (PE) router, and traffic from inside to inside between overlapping networks. 

In normal NAT scenario:
Packets on the NAT outside are first translated and then routed. On the inside interface routing decision kicks in first and only then translation rules get applied followed by forwarding.

(5.5.5.5) -R5- nat in -R2 -nat out - R1 -R3(3.3.3.3)

debug on R2:
*Mar  1 01:25:16.647: NAT: Allocated Port for 5.5.5.5 -> 10.12.0.2: wanted 21 got 21
*Mar  1 01:25:16.651: IP: tableid=0, s=5.5.5.5 (Ethernet0/0), d=3.3.3.3 (Ethernet0/1), routed via FIB
^^^ inside, route before NAT ^^^
*Mar  1 01:25:16.655: NAT: i: icmp (5.5.5.5, 21) -> (3.3.3.3, 21) [32]
*Mar  1 01:25:16.659: NAT: s=5.5.5.5->10.12.0.2, d=3.3.3.3 [32]
*Mar  1 01:25:16.659: IP: s=10.12.0.2 (Ethernet0/0), d=3.3.3.3 (Ethernet0/1), g=10.12.0.1, len 100, forward
*Mar  1 01:25:16.667:     ICMP type=8, code=0
*Mar  1 01:25:16.791: NAT: o: icmp (3.3.3.3, 21) -> (10.12.0.2, 21) [32]
*Mar  1 01:25:16.795: NAT: s=3.3.3.3, d=10.12.0.2->5.5.5.5 [32]
^^^ outside, NAT before route ^^^
*Mar  1 01:25:16.795: IP: tableid=0, s=3.3.3.3 (Ethernet0/1), d=5.5.5.5 (Ethernet0/0), routed via FIB
*Mar  1 01:25:16.799: IP: s=3.3.3.3 (Ethernet0/1), d=5.5.5.5 (Ethernet0/0), g=10.25.0.5, len 100, forward
*Mar  1 01:25:16.799:     ICMP type=0, code=0


NVI scenario:
So what’s the difference with NVI? First, we see that now NAT behaves symmetrically. Next, we see that NAT translation tables are used to take a “routing decision” to send packet to virtual interface. Packet is translated there and then another routing decision takes place, followed by packet forwarding. So the difference from the old model is that now routing decision is taken twice: before and after translation. This allows to get rid of any static routes needed by “legacy” NAT, since lookup is performed after translation.

To summarize: Domain-based NAT uses different orders of operations for inside and outside domain. NVI based NAT is symmetrical and performs routing lookup twice: first to send packet to NVI, second to route packet using the post-translated addresses.

Note: this setup only works for "one way" initialize the traffic, e.g. from R5 to R3; other way around is not working (as R3 do not know the route to 5.5.5.5)

--------
The new NAT virtual interface has no difference between interface outside or inside.
1. First it will check the packet to see if it needs to be NAT
2. If it needs to be NAT, it will be routed to the virtual interface then doing the NAT.
3. After the NATed, it will be routed again.
--------

The Inside and Outside of NAT
MPLS VPN: Using the NAT Virtual Interface for Internet Access
NAT Virtual Interface
NAT virtual interface  

Reflexive access lists

Bascially, very similar to Cisco Zone Based Firewall.

1. define an access-list Egress to allow matched outbound traffic, apply it on to interface, once the traffic is matched, it will create a timed reflexive access-list - Mirror

Router(config)# ip access-list extended Egress
Router(config-ext-nacl)# permit ip any any reflect Mirror
Router(config-ext-nacl)# interface f0/1
Router(config-if)# ip access-group out Egress

2. defind an access-list Ingress (which will reference the reflexive access-list - Mirror) to allow match inbound traffic

Router(config)# ip access-list extended Ingress
Router(config-ext-nacl)# evaluate Mirror
Router(config-ext-nacl)# interface f0/1
Router(config-if)# ip access-group in Ingress

Very good reference of Cisco reflexive access lists, way way better than Cisco's own reference!
http://packetlife.net/blog/2008/nov/25/reflexive-access-lists/
Configuring IP Session Filtering (Reflexive Access Lists)

Speed, bandwidth command under interface

Speed command explanation is actual much more simplest than bandwidth. Some interface (hardware dependent) allow you to set the speed. Speed command is also important, as it has to be the same on both ends of the connection.
speed {10 | 100 | 1000 [negotiate] | auto [speed-list]}


Bandwidth command under interface may have following functions:
bandwidth kilobits

1. Higher-level protocols use bandwidth information to make operating decisions.
2. TCP adjusts initial retransmission parameters on the basis of the apparent bandwidth of the outgoing interface.
3. Load calculations is based upon the perceived bandwidth.
4. QoS calculations (e.g. bandwith percent in top level policy map) will be affected by this. 



http://www.gossamer-threads.com/lists/cisco/nsp/133406 
https://learningnetwork.cisco.com/thread/4572 
http://www.firstdigest.com/2010/08/cisco-speed-vs-bandwidth-interface-command/ 
http://www.cisco.com/en/US/docs/ios/12_2/interface/configuration/guide/icfgenrl.html#wp1102606 

Flex Links

Flex Links are a pair of a Layer 2 interfaces (switchports or port channels), where one interface is
configured to act as a backup to the other. Flex Links are typically configured in service-provider or
enterprise networks where customers do not want to run STP. Flex Links provide link-level redundancy
that is an alternative to Spanning Tree Protocol (STP). STP is automatically disabled on Flex Links
interfaces.
To configure the Flex Links feature, you configure one Layer 2 interface as the standby link for the link
that you want to be primary. With Flex Links configured for a pair of interfaces, only one of the
interfaces is in the linkup state and is forwarding traffic. If the primary link shuts down, the standby link
starts forwarding traffic. When the inactive link comes back up, it goes into standby mode.

Configuring Flex Links
Flex links

Configuring EtherChannel

Configuring EtherChannel

Configuring EtherChannel Between Catalyst Switches Running Cisco IOS System Software and a Cisco Router


EtherChannel Limitations on Cisco 2800 router
Cisco Gigabit Ethernet High-Speed WAN Interface Card

Tips of BGP Convergence

1. tweak BGP timers (Hello, Advert, Scan)

2. rely on IGP (fine tune IGP first)

bgp fast-external-fallover (default enable for eBGP)

bgp nexthop trigger delay delay-timer (seconds)

3. enable BFD
neighbor 1.1.1.1 fall-over bfd

4. allow multiple paths in BGP
a) using different RD (MP-BGP)
b) different RRs has different perference for a prefix
c) BGP The “Add Paths” capability

Very good reference:Understanding BGP Convergence
BGP Commands: 
BGP Support for Next-Hop Address Tracking

BFD - BGP Multihop Client Support and cBit (IPv4 and IPv6)

From BFD - BGP Multihop Client Support and cBit (IPv4 and IPv6)

BGP by default will purge the routes received from a specific peer when a BFD down event occurs and BFD informs BGP about it. The cBit in BFD determines whether BFD is dependent or independent of the Control Plane. Clients like BGP, whose peers are enabled with fast fall over feature with BFD support, can use this BFD cBit support to provide a more deterministic mechanism to do nonstop forwarding (NSF) when BGP graceful restart is enabled along with BFD fast-fallover support for BGP sessions.
When BGP is using BFD for fast fallover feature for remote connectivity detection, BFD can detect some of those failures. If BFD is independent of the control plane, a BFD session failure means that data cannot be forwarded anymore (due to link control failures) and so the BGP Graceful Restart procedures should be aborted to avoid traffic black holes. On the other hand, when BFD is dependent on the control plane, a BFD failure cannot be separated out from the other events taking place in the control plane. When the control plane crashes, a switchover happens and BFD restarts. It is best for the clients (like BGP) to avoid any aborts due to the graceful restart taking place.
The table below describes the handling of BFD down events by BGP.

Table 1

BGP handling of BFD Down Event

BFD Down Event	Failure - Control Plane Independent ?	BGP Action for NSF (when GR and BFD are enabled)
BGP control plane detection failure enabled	Yes	Purge Routes
BGP control plane detection failure enabled	No	Carry on NSF and keep stale routes in Routing Information Base (RIB)
BGP control plane detection failure disabled (the default behavior)	Yes	Purge Routes
BGP control plane detection failure disabled (the default behavior)	No	Purge Routes

BFD for Cisco 7600

BFD Scale Improvement on ES+ Line Card for 7600

Bidirectional Forwarding Detection (BFD) scale improvement feature provides the functionality to offload a BFD session to an ES+ line card. BFD is a forwarding path failure detection protocol and reduces the overall network convergence time by sending rapid failure detection packets (messages) to the routing protocols for recalculating the routing table. Before Release 15.1(2)S, a BFD session was run as a software component on the Route Processor (RP). Hence, the performance of BFD was restricted to the capabilities of CPU and IOS on the RP on the Cisco 7600 Router. Effective failure detection requires BFD to run at high frequencies (using aggressive timers as low as 50ms), which was not possible because of CPU and IOS restrictions. Effective with Cisco IOS Release 15.1(2) S, apart from running a BFD session on the RP, you can also offload a BFD session to the ES+ line card based on specific conditions listed in the "Restrictions for BFD Scale Improvement" section. 

Restrictions for BFD Scale Improvement

The following restrictionsapply for BFD scale improvement:

•A BFD session is supported on only RSP 720 and Supervisor 720 (SUP720), it is not supported on SUP32.

•Only BFD version 1 is supported.

•The BFD session can be offloaded only to an ES+ line card interface.

•Ensure that the ES+ Line Card interface configured with the BFD session is on global routing table. Effective from Cisco IOS Release 15.1(3)S and 15.1(2)S1, the interface with a BFD session can be on any Virtual Routing and Forwarding (VRF).

•Each network processor supports a total of 250 sessions distributed across its ports.

•BFD hardware offload is supported for IPv4 sessions with non-echo mode only.

•You can configure IPv4 and IPv6 sessions to co-exist on the router as well as the same interface.

•Only the single hop BFD hardware offload is supported for both the IPv4 and IPv6 sessions. BFD hardware offload supports either of these combinations for IPv4 and IPv6 sessions:

–1000 IPv6 BFD sessions and no IPv4 sessions.

–2000 IPv4 BFD sessions and no IPv6 sessions.

–500 IPv4 BFD sessions and 500 IPv6 sessions.

•BFD offload is supported only for the ethernet interface.

•Timer values for Tx and Rx should only be in multiples of 50 and should range between 50 and 950ms for both the local and remote BFD peer router.

•If the Failure in MPLS core does not converge before XC BFD timer expires, then the BFD session flaps.

•BFD Tx jitter defined in RFC 5880 is not supported.

•You cannot swap a BFD session between ES+ line card and IOS by changing the parameters when the BFD session is up and running. To swap a BFD session, you need to unconfigure and reconfigure the BFD session with the changed parameters.

•BFD offload is not supported on port-channel or SVI interfaces.

•In case of prolonged network instability and BFD session flaps, the session state may get stuck in the DOWN, INIT, or UP state. Unconfigure and reconfigure BFD to resolve this issue.

•During line card OIR, the show bfd neighbor detail command may show discrepancy in the statistics counter. The statistics counter provide information about Rx or Tx counts for a particular session.

•BFD supports 2000 sessions with OSPF as client on RSP. Example scenarios:

–All subinterfaces are configured as point to point.

–Four instances of OSPF are running with each instance supporting 500 BFD session.

•Configure the symmetric slow timers to less than or equal to five seconds on both the ends to bring up the HW offloaded BFD sessions.

•BFD supports a maximum of 10 IPv6 static route sessions on an interface. 

Configuring Layer 1 and Layer 2 Features 

L2VPN Interworking

xconnect Command Syntax  - Binds the attachment circuit to a pseudowire VC.

xconnect peer-ip-address vcid pw-class pseudowire-name

 
pseudowire-class pseudowire-name





 encapsulation mpls




 interworking ethernet

L2VPN Interworking Modes



L2VPN Interworking works in either Ethernet ("bridged") mode or IP ("routed") mode. You specify the mode by issuing the interworking {ethernet | ip} command in pseudowire-class configuration mode.



The interworking command causes the attachment circuits to be terminated locally. The two keywords perform the following functions:



•The ethernet keyword
 causes Ethernet frames to be extracted from the attachment circuit and 
sent over the pseudowire. Ethernet end-to-end transmission is assumed. 
Attachment circuit frames that are not Ethernet are dropped. In the case
 of VLAN, the VLAN tag is removed, leaving an untagged Ethernet frame.



•The ip keyword
 causes IP packets to be extracted from the attachment circuit and sent 
over the pseudowire. Attachment circuit frames that do not contain IPv4 
packets are dropped. 



 

Layer 2 Virtual Private Network Interworking 

L2VPN Interworking 

Cisco IOS Multiprotocol Label Switching Command Reference 

Configuring 802.1q tunnels over Vlan-based EoMPLS & MUX-UNI 

Site of Origin BGP Community Attribute

Site of Origin BGP Community Attribute

The site-of-origin (SoO) extended community is a BGP extended community attribute that is used to identify routes that have originated from a site so that the readvertisement of that prefix back to the source site can be prevented. The SoO extended community uniquely identifies the site from which a router has learned a route. BGP can use the SoO value associated with a route to prevent routing loops.

BGP per Neighbor Site of Origin Configuration

There are three ways to configure an SoO value for a BGP neighbor:

•BGP peer policy template—A peer policy template is created, and an SoO value is configured as part of the peer policy. Under address family IPv4 VRF, a neighbor is identified and is configured to inherit the peer policy that contains the SoO value.

•BGP neighbor command—Under address family IPv4 VRF, a neighbor is identified, and an SoO value is configured for the neighbor.

•BGP peer group—Under address family IPv4 VRF, a BGP peer group is configured, an SoO value is configured for the peer group, a neighbor is identified, and the neighbor is configured as a member of the peer group. 

BGP per Neighbor SoO Configuration 

Case Study 10: BGP Site of Origin 

http://www.shafagh.net/2009/10/ccie-sp-bgp-as-pe-ce.html 

PPS BPS calculator

pps = packet per second
bps = bit per second
byte = 8 * bit
pps * average packet size (byte) = bps

Here is a handy tool: Bits per second to packets per second converter

Often vendors such as our favorite Cisco specify device performance as packets per second, so we don't need to bother about packet size mentioning because pps is rather a characteristic of device's (processor, bus, ASICs) computing power. Packets per second more or less still the same with different packets size. But it is not very convinient to deal with pps in a real life because we have to know "real" device performance in our network. So we have to do two things:

1) Determine the average packet size which is specific for our network. For example traffic profile for our network could be 30% ftp-data (large packet at 1500 bytes) and 70% VoIP-data (a lot of small packets at 64 bytes) so our average packet size is about 800 bytes.

2) Calculate with simple formula how much there will be Megabits per second (Mbps) if our average packet size is 800 bytes and device performance is, lets say, 100 kpps (one hundred thousand of packets per second)

From: Bits per second to packets per second converter

How to upgrade Debian from Lenny to Squeeze

How to upgrade Debian from Lenny to Squeeze

How to upgrade Debian from Lenny to Squeeze 

http://en.wikipedia.org/wiki/Debian 

SSM needs IGMPv3

Source-specific multicast (SSM) is a method of delivering multicast packets in which the only packets that are delivered to a receiver are those originating from a specific source address requested by the receiver. By so limiting the source, SSM reduces demands on the network and improves security.
SSM requires that the receiver specify the source address and explicitly excludes the use of the (*,G) join for all multicast groups in RFC 3376, which is possible only in IPv4's IGMPv3 and IPv6's MLDv2.
Source-specific multicast is best understood in contrast to any-source multicast (ASM). In the ASM service model a receiver expresses interest in traffic to a multicast address. The multicast network must

1. discover all multicast sources sending to that address, and
2. route data from all sources to all interested receivers.

This behavior is particularly well suited to groupware applications where

1. all participants in the group want to be aware of all other participants, and
2. the list of participants is not known in advance.

The source discovery burden on the network can become significant when the number of sources is large.
In the SSM service model, in addition to the receiver expressing interest in traffic to a multicast address, the receiver expresses interest in receiving traffic from only one specific source sending to that multicast address. This relieves the network of discovering many multicast sources and reduces the amount of multicast routing information that the network must maintain.
SSM requires support in last-hop routers and in the receiver's operating system. SSM support is not required in other network components, including routers and even the sending host. Interest in multicast traffic from a specific source is conveyed from hosts to routers using IGMPv3 as specified in RFC 4607.
SSM destination addresses must be in the ranges 232.0.0.0/8 for IPv4 or FF3x::/96 for IPv6.


Source Specific Multicast (SSM) requires Internet Group Management Protocol Version 3 (IGMPv3) 

PIM-SSM is the routing protocol that supports the implementation of SSM and is derived from PIM sparse mode (PIM-SM). IGMP is the Internet Engineering Task Force (IETF) standards track protocol used for hosts to signal multicast group membership to routers. Version 3 of this protocol supports source filtering, which is required for SSM.

Ref: 
Source-specific multicast 
Source Specific Multicast with IGMPv3, IGMP v3lite, and URD 
Using IGMPv3 For Source-Specific Multicast 

Load Balancing in BGP Networks

Good reference: Load Balancing in BGP Networks

Below are the copy from the link:

Fact #1: Load-balancing is always unidirectional
Fact #2: Not all Load-Balancing Mechanisms are Equal

External BGP Load Balancing
The true BGP-only EBGP load balancing is configured with the maximum-paths router configuration command and allows a BGP router with multiple EBGP sessions to load balance the traffic toward destinations received in EBGP updates.


IBGP Load Balancing
Option #1: Use next-hop-self
Option #2: External OSPF routes

Route Reflectors killed Load Balancing
Each BGP router selects a single best route (even though it might use more than one for packet forwarding) and propagates it to its BGP neighbors. A route reflector might thus use multiple IBGP routes and load balance between them, but its clients would only receive a single route.