As of 5th May 2010 All 13 DNS ROOT Server will consist of a signed digital signature with every replied query. This has been ruled out to tackle any man-in-middle attack similar to Dan Kaminsky’s exploit.
Is it going to break the internet?
It is only going to affect if the firewalls & FWSMs are not configured correctly to allow DNSSec signed packets.
The answer being, as we already know DNS uses UDP packets for query replies; and most firewalls are going to drop any packets larger than 512bytes.
Having been said, the DNSSec signed replies are going to have an extra layer of encryption, thus increasing the packet size up to 4KB (4096) and the firewalls & FWSMs needs to be configured to allow such larger packets through.
What needs to be configured on the Firewall?
The firewall needs to have the following settings to allow larger UDP packets through…
message-length maximum 4096
We can either hard-code the maximum-length or use other methods to tackle this issue.
Take a look at the following post for a detailed explanation at http://etherealmind.com/dnssec-and-why-the-internet-probably-wont-break-today/ and more info about DNSSec can be found on http://www.root-dnssec.org or simply typing the word on Google.
I have come across an odd scenario on pre-share key based IPSec tunnels…
The question being, when an IPSec tunnel is active (Phase 1 and 2 are UP) and the pre-share key is changed, does this tear down the tunnel?
The tunnel configuration on R4 follows…
!
crypto isakmp policy 1
encr aes 256
hash md5
authentication pre-share
group 2
crypto isakmp key fnode address 192.168.1.5
!
!
crypto ipsec transform-set FNODE1 esp-3des esp-sha-hmac
!
crypto map FNODE1 1 ipsec-isakmp
set peer 192.168.1.5
set transform-set FNODE1
match address 120
!
!
interface Ethernet0/0
ip address 192.168.1.4 255.255.255.0
full-duplex
crypto map FNODE1
!
access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255
!
The tunnel configuration on R5 follows…
[click to continue…]
OSPF Loopback interfaces are treated as a stub host and will only have a 32 bit host route on the other devices no matter how the subnet mask is entered under the OSPF network statement.
We will explore how we can disable this default behaviour using a few methods.
As you can see, R4 is configured with IP address 192.168.1.4 and R5 with 192.168.1.5.
We have loopback interfaces added with /24 subnet masks on R4 and R5
R4#sh run int loop0
Building configuration...
Current configuration : 61 bytes
!
interface Loopback0
ip address 4.4.4.4 255.255.255.0
end
R4#
R5#sh run int loop 0
Building configuration...
Current configuration : 61 bytes
!
interface Loopback0
ip address 5.5.5.5 255.255.255.0
end
R5#
We are running basic OSPF Configs as follows…
[click to continue…]
I was going through 6to4 tunnel configs and thought I’d post some info on converting IPv4 address into IPv6 Address. This is pretty straight forward and its obviously involves HEX conversion.
Here, I will convert the address 192.168.25.234
First we divide each octet by 16 and write down the remainder, primary school maths! 
192 ÷ 16 = 12 remainder 0
168 ÷ 16 = 10 remainder 8
25 ÷ 16 = 1 remainder 9
234 ÷ 16 = 14 remainder 10
We also know that HEX has the following Values
A = 10
B = 11
C = 12
D = 13
E = 14
F = 15
So we can write 192.168.25.234 into HEX like so… C0A8:19EA
Now we will change the HEX Address C0A8:19EA into regular IPv4
C0 = (12 x 16) + 0 = 192
A8 = (10 x 16) + 8 = 168
19 = (1 x 16) + 9 = 25
EA = (14 x 16) + 10 = 234
QED
I was going through some TCP windowing over a high speed WAN link, and thought it might be worth to post some info regarding this.
We do face a typical problem of having slow speed file transfer even if the dedicated pipe is capable of supporting it.
There are three factors which affects this…
- TCP Window Size.
- Round trip latency of the circuit.
- Bandwidth of the circuit.
Maximum throughput you can get from a line with 10ms latency and a TCP window of 32KB can be calculated with…
32KB –> 32 x 1024 x 8 = 262144 Bits
262144 ÷ 0.01 = 26214400 bps = 26.2144 Mbps
Let’s say we have an OC-3 line, which is at 155 Mbps and a round trip latency of 10ms, and we need to calculate the TCP window size to maximize the throughput…
155.52 x 106 = 155520000 bps
TCP_WINDOW = 155520000 x 0.01 = 1555200 Bits = 194400 Bytes = 189.84375 KB
Hope I got the calculation right
Multilink is a way of bundling more than one PPP WAN links and bundle them together into one logical interface. This is one of the method you can implement when you have a primary and secondary links in place and create a logical conduit where both links are present.
This method can be used to load balance data across the links and at the same time it will support redundancy when one one link fails.
I have tested this configuration on 2 of my 2500 Routers and I haven’t tested these on more recent IOS so some commands may vary. I will be checking them on a pair of 3845s/2691s on a later date and will add my findings to this post.
As you can see the Diagram, I am using R4 and R5 which are connected via Serial 0 and Serial 1 respectivly.
R4 Configuration
Multilink Interface
interface Multilink1
ip address 172.16.1.1 255.255.255.252
ppp multilink
ppp multilink links maximum 2
ppp multilink links minimum 1
ppp multilink group 1
Serial 0
interface Serial0
no ip address
encapsulation ppp
clock rate 64000
ppp multilink
ppp multilink group 1
Serial 1
interface Serial1
no ip address
encapsulation ppp
clock rate 64000
ppp multilink
ppp multilink group 1
As you can see, since this is a lab scenario, I have set the clock rate on the link. If you are setting this up on a WAN link, you don’t need to do this as the circuit provider would be setting this up for you.
[click to continue…]
