Saturday, April 22, 2006


Compression over a PPP link. (Question #59)

Consider two routers connected back-to-back over their serial links with the following configuration


interface Serial2
ip address
encapsulation ppp
no keepalive
compress predictor


interface Serial2
ip address
encapsulation ppp
no keepalive
compress stac

Note that the compression algorithms configured on each end do not match. If a ping is attempted from one router to the other, will the pings succeed? Would your answer change if the encapsulation on both serial interfaces was changed to HDLC instead?


Some Thoughts on Crypto ISAKMP Policy Configuration.

Consider the following ISAKMP policy configuration -

crypto isakmp policy 10
authentication pre-share
group 2
lifetime 65535
crypto isakmp key foobar address

When I first saw something like this, I noticed that the policy indicated that the authentication method used would be pre-shared but the actual pre-shared key was itself defined outside the isakpmp-policy configuration mode as is clear from the way the key configuration statement is indented above. That didn't seem to make sense to me. I thought that it would have been more intuitive to say something like

authentication pre-share key foobar address

inside the ISAKMP policy configuration mode itself. After all, why put just the key configuration outside?

Well, it just occurred to me that the way Cisco has done it makes sense after all. Consider the case where you have a single router with (say) 100 IPSec peers. In that case, the naive method I was thinking of as the straightforward way of doing this would need a policy configuration block for each peer since the key and certainly the address would be different for each of the 100 peers. The way Cisco has done it, one could have one (or a few different) ISAKMP policy configuration blocks while using the separate key/address config statements for each peer to connect to the 100 peers. The Cisco way reuses the (well) reusable parts of the ISAKMP config statements for each peer and only needs the parts that are different (the key and peer address pair) for each IPSec peer.

Yet another case where after thinking a bit something that seemed superficially strange makes sense eventually!

This page is powered by Blogger. Isn't yours?