Multicast for MPLS VPN

We need to transport multicast traffic across our enterprise MPLS core network for users to receive their favorite Channel News Asia and CNN live broadcasts on their workstations. I found this updated Cisco resource - Configuring Multicast VPN (MVPN) - for IOS 12.4, which is different from the older IOS versions. The newer version support MDT SAFI, which will be automatically created when the default MDT (Multicast Distribution Tree) exists. The default MDT defines the path used by PE routers to send multicast data and control messages to every other PE router in the multicast domain. The setting up of MDT involves the following steps:

1. Configuring a Default MDT Group for a VRF (required)


2. Configuring the MDT Address Family in BGP for Multicast VPN (required)


3. Configuring the Data Multicast Group (optional)

Data MDTs, which are dynamically created, are intended for high-bandwidth sources such as full-motion video inside the VPN to ensure optimal traffic forwarding in the MPLS VPN core. When the multicast transmission exceeds the defined threshold, the sending PE router creates the data MDT and sends a UDP message, which contains information about the data MDT to all routers on the default MDT. The threshold at which the data MDT is created can be configured on a per-router or a per-VRF basis. However, Data MDTs are created only for shared tree (S, G) multicast route entries within the VRF multicast routing table. They are not created for source tree (*, G) entries regardless of the value of the individual source data rate.

MPLS MTU for Enterprise MPLS VPN

We are in the midst of building a new 10GE MPLS VPN for our enterprise campus core network. After we setup our first MPLS VPN, we are able to connect up 2 different VRFs (a.k.a virtual networks) belonging to 2 different departments. Ping test shows that the RTT was close to 0 msec. However, Active Directory traffic was slowed to a claw.

We investigated and found no fault at the routing and mpls configuration. Later, I recalled an experience of slow access over GRE tunnel relating to MTU sizing. Further search on Cisco.com revealed this:

When configuring the network to use MPLS, set the core-facing interface MTU values greater than the edge-facing interface MTU values, using one of the following methods:

• Set the interface MTU values on the core-facing interfaces to a higher value than the interface MTU values on the customer-facing interfaces to accommodate any packet labels, such as MPLS labels, that an interface might encounter. Make sure that the interface MTUs on the remote end interfaces have the same interface MTU values. The interface MTU values on both ends of the link must match.
• Set the interface MTU values on the customer-facing interfaces to a lower value than the interface MTU on the core-facing interfaces to accommodate any packet labels, such as MPLS labels, than an interface might encounter. When you set the interface MTU on the edge interfaces, ensure that the interface MTUs on the remote end interfaces have the same values. The interface MTU values on both ends of the link must match.

We adopted the former approach and set MTU size of all core facing interfaces to 1520 bytes and leave all customer facing interfaces to default 1500 bytes.

Re-using old network connection name

Whenever you try to name a network connection name with the same name of once-existence old network adaptor, you would encounter this error



To use back the same name, execute the following command:

SET DEVMGR_SHOW_NONPRESENT_DEVICES=1
START DEVMGMT.MSC

On the Device Manager, click on View -> Show hidden device, uninstall the non-existence network device.

Setting up RADIUS authentication for Cisco devices

I know this is not new but would like to elaborate slightly further for my team. The "Network Policy Server" in Windows 2008 can serve as a central AAA mechanism for all Cisco logins. Furthermore, each network administrator can login using their individual credential (which is AD-integrated) instead of sharing a common set of local passwords, which is an administrative nightmare if these passwords are compromised.

This blog explained the initial setup. To continue adding more RADIUS client (i.e. Cisco devices), log on to the NPS server and fire up the Network Policy Server console.

1) Add RADIUS client
Right click on RADIUS client and click "New". Enter the name of device and the IP address. As a Cisco device may have multiple interfaces, I would prefer using the loopback address. Also, supply the pre-shared key between the server and the client.


Note: Both IP addresses and the key must match. If not, authentication would fail.

2) Cisco Configuration
Cautious: Make sure you have another running line or console before you do this.

aaa new-model
#use radius login 1st. when time-out, use local password
#you may want to define your own list. Make sure the list in red must match the login vty below
aaa authentication login RadiusList group radius local
#make sure it matches the client IP address in the NAP server earlier
ip radius source-interface Loopback0
#replace the below brackets with your values
radius-server host [server_IP] auth-port 1812 acct-port 1813 timeout 5 key [your_key]

#apply authentication method
line vty 0 4
access-class MGMT_ACL in
logging synchronous
login authentication RadiusList
transport input ssh

3) Verifying & Troubleshooting
Try ssh into the device. If unsuccessful, check network connectivity from the client using "ping [server_IP] source loopback0". Run "debug radius" command and go to the event viewer of the server. For easy viewing, open up the Server Manager console and click on the "Network Policy Manager" where the login events are filtered automatically for you.

4) Change the prompt (Optional)
How do you know which are the devices use RADIUS or local authentication? Simple, just change the login & password prompts.

aaa authentication banner ^CAccess to this device is protected by NAP^C
aaa authentication password-prompt "NAP password:"
aaa authentication username-prompt "Your NAP id:"

RemoteFX coming in next SP of Win7 and Win2K8 R2

RemoteFX is an enhancement to RDP's graphics remoting capabilities. With Microsoft RemoteFX, users will be able to work remotely in a Windows Aero desktop environment, watch full-motion video, enjoy Silverlight animations, and run 3D applications – all with the fidelity of a local-like performance when connecting over the LAN. RemoteFX does this via a technique known as host-based rendering, which means the entire final composited screen image is rendered on the remote host and then compressed and sent down to the client.

Look like Microsoft is beefing up its RDP-based virtualizaton offering - namely Remote Desktop Services (RDS). The goal of RemoteFX is to deliver the full modern Windows desktop experience to the remote thin clients while their desktops are actually hosted in the data center as part of a virtual desktop infrastructure (VDI). And these virtual desktops must be hosted in Hyper-V.

We have been using Microsoft RDS to allow our network administrators to access their desktops and network management & troubleshooting tools from our standard locked down corporate PCs. And certainly, I'm looking forward to the next SP release, which promises the incorporation of RemoteFX. Probably, I should try out the beta release.

Hyper-V live migration failed after configuration change

If you change the virtual host configuration (for example, add another virtual NIC) using Hyper-V MMC after the virtual host is "HAed", live migration would fail. To resolve this, remove the VM from the cluster and add it in again.


After some research on the Internet, I realised that you must not use Hyper-V MMC, use the "Setting" button in the Failover Clustering Manager instead. (Click below to enlarge)

Part 2: How DNSSec works

This is the 2nd part of DNSSec. The 1st part introduce the prologue to DNSSec.

Overview

At the most basic level, DNSSEC provides the assurance for DNS servers and resolvers (a.k.a DNS clients) to trust DNS responses by using digital signatures for validation. Specifically, it provides origin authority, data integrity, and authenticated denial of existence of validated DNS responses.

When a DNS client issues a query for a name, the accompanying digital signature is returned in the response. Successful validation would show that the DNS response has not been modified or tampered with. Any subsequent modifications to the DNS zone (e.g. adding and deleting of records) would require the entire zone file to be re-signed.

Trust Anchor & PKI Concept

Before you can perform any digital signature validations, all involved parties must trust a common "authority" in higher level, in order to create a trust path beforehand. This "authority" is known as Trust Anchor, which is similar to the Certificate Authority (CA) in the PKI concept. Just like the PKI CA, it is also able to sign next-level child zones down under, such as child.abc.com if the trust anchor is on abc.com. Because everyone trust this common Anchor Point, the clients would also trust other "child zones" vouched by this "authority".

Do note that zone signing is only required for authoritative DNS servers. Remember that the DNS cache poisoning attacks are mostly targeted at the local DNS server caches of your ISPs. These recursive resolvers do not need to be signed by the root zone, as they are mostly non-authoritative (i.e. contain no zones on their owns) and simply perform recursive lookup on your behalf. The DNS resolvers belonging to the ISPs just need to be pre-configured to trust the public keys of the trust anchors - much like the Web browsers on your desktops that are pre-configured to trust the public certs of Verisign & Thawte.

New DNS Extension

To facilitate DNSSEC validations, four new resource records (DNSKEY, RRSIG, NSEC and DS) are introduced to existing DNS structure. DNSKEY (DNS public key) contains the zone public key. RRSIG (Resource Record Signature) contains the digital signature of the DNS response. NSEC (Next Secure) can inform about the denial-of-existence records. For example, if the zone only contains record A and D but you ask for B, it would return "A NSEC D" indicating the non-existence of records B and C. Lastly, DS (Delegation Signer) is used to validate between the parent and child zones, which are both DNSSec enabled.

IPSec

In most situations, the clients would simply ask the local DNS servers to perform DNSSec validation on their behalf. For maximum protection, you may also want to setup IPSec communications between the clients and the local servers. In corporate environments, these computers may use their domain certs for such domain IPSec setup. Note that IPSec is optional for DNSSec.

Name Resolution Policy Table (NRPT)

What if you wish to reject DNS response from non-DNSSec enabled DNS servers or making IPSec connection compulsory? You can influence such behaviours by the means of Name Resolution Policy Table (NRPT). Before issuing any queries, the DNS client will consult the NRPT to determine if any additional flags must be set in the query. Upon receiving the response, the client will again consult the NRPT to determine any special processing or policy requirements. In Windows Server 2008 R2 implementation, the following NRPT properties may be set using Group Policy:

1) Namespace: Used to indicate the namespace to which the policy applies. When a query is issued, the DNS client will compare the name in the query to all of the namespaces in this column to find a match.

2) DNSSEC: Used to indicate whether the DNS client should check for DNSSEC validation in the response. Selecting this option will not force the DNS server to perform DNSSEC validation. That validation is triggered by the presence of a trust anchor for the zone the DNS server is querying. Setting this value to true prompts the DNS client to check for the presence of the Authenticated Data bit in the response from the DNS server if the response has been validated, If not, the DNS client will ignore the response.

3) DNS Over IPsec: Used to indicate whether IPsec must be used to protect DNS traffic for queries belonging to the namespace. Setting this value to true will cause the DNS client to set up an IPsec connection to the DNS server before issuing the DNS query.

4) IPsec Encryption Level: Used to indicate whether DNS connections over IPsec will use encryption. If DNSOverIPsec is off, this value is ignored.

5) IPsec CA: Refers to the CA (or list of CAs) that issued the DNS server certificates for DNSSec over IPsec connections. The DNS client checks for the server authorization based on the server certificates issued by this CA. If left un-configured, all root CAs in the client computer’s stores are checked. If DNSOverIPsec is off, this value is ignored.