dialer interface - interesting traffic

[Rik19972000]

if you have two different dialer interfaces

with each a dialer-list permit ip any.

Is the presence of ip traffic enough to activate an interface? or does it need to pass through the dialer interface.

For example:

ip route 0.0.0.0 0.0.0.0 Dialer1

ip route 0.0.0.0 0.0.0.0 Dialer2 50

Will dialer2 interface see the traffic passing via Dialer1 as interesting traffic?

if answers is no,

will ip route (tunnel_destination) Dialer2 create interesting traffic . By the tunnel interface trying to setup IKE phase 1

[Peter Paluch]

Hello,

The traffic needs to pass the Dialer interface - only then it will be tested if it is "interesting" for a dialer to make a call. A traffic that does not pass a dialer interface is not subject to any dialer list at all. In your configuration with the two dialers, only the Dialer1 will be in the routing table because of its lower administrative distance. The Dialer2 will not be in the routing table, meaning that no traffic will flow through it and thus nothing will trigger a call.

The sequence of steps is as follows:

1.) First, a lookup in the routing table is done, and the routing table says that the traffic should exit via a particular Dialer interface

2.) As the traffic is routed out the Dialer interface, its associated dialer list is consulted to see if this traffic is interesting

3.) If the traffic is interesting and there is not active call on the dialer, the router will look for a number to call and dial it. If the traffic is interesting but the call is already in progress, just reset the inactivity timer on the interface. If the traffic is not interesting, nothing will be done in this step.

4.) If the call is in progress, transmit the packet, otherwise, drop it.

Best regards,

Peter

[Rik19972000]

if you've a router without config

and

configure a dialer interface + apply a crypto map

+ ip route "set_peer_ip" via dialer

+ routing protocol which is multicasting hello's

can the hello mechanisms start a dial.

I suppose yes

Similar question

Thus if you've a lot of tunnel interfaces

source fas0/0

destination public IP y

tunnel interface doesn't use the concept of matching traffic. Everything that passes (is routed through) the tunnel interface is interesting traffic. Thus interesting traffic is defined by routing table.

If tunnel is up, (and other side also) will the multicasting hellos keep the tunnel up

what if a tunnel interface is up/down and it receives a multicast will it try to initiate a connection with its peer?

If you've 2 tunnel interfaces (1 each side)

How can they come up as initial they are not in the routing table, and can thus not be routed through the interface? Thus a tunnel who is up/down, iniate a tunnel setup with the other side. (totally different than a crypto map on an interface -> interesting traffic)???

[Peter Paluch]

Hello Rik,

Yes, the Hello packets or periodic updates of a routing protocol will cause the Dialer to make a call and keep the dialed connection still active. Of course it depends very much on the dialer list whether it considers the routing protocol traffic as an interesting traffic.

Regarding your second question about a tunnel, I do not fully understand what you want to ask. If speaking strictly about a tunnel interface, there is nothing such as interesting traffic - it does not make sense as the tunnel does not dial anywhere and so it does not need to separate the traffic into "interesting" and "uninteresting" categories. A tunnel interface does not go down or up according to the traffic flowing through it. A tunnel interface is up when the source interface is up/up and when destination is reachable. There is nothing such as traffic that keeps a tunnel up.

I am not sure if I answered your question here. If not please feel free to ask further.

Best regards,

Peter

[Rik19972000]

Great, I come closer to fully understanding

" A tunnel interface is up when the source interface is up/up and when destination is reachable. There is nothing such as traffic that keeps a tunnel up."

let's say

dialer-list 1 permit any

interface dialer1

dialer-group 1

<...ADSL>

int tunnelX

ip add 10.0.0.0.1

tunnel source dialer1

tunnel destination PEER_IP

tunnel mode ipsec ipv4

tunnel protection ipsec profile "something"

ip address PEER_IP dialer 1

this tunnel will try to reach PEER_IP

with source ip: and destination IP: PEER_IP. As there's a route via dialer interface it will trigger a dial, reach the other side and negotiate IPSEC paramaters.

But: source ip: has no IP address: to be negotiated with ISP (although it's a static IP, it's not configured on the dialer interface)

--> how does this work in this situation with static ip, but negotiated each time.

Will this work?

2)or should we place the IP address on the interface instead of negotiating the "static IP"

but if we place an IP on the dialer interface and know it's always up/up will it not try to form a tunnel over the backup interface?? So there 's a tunnel via backup interface as intended and a second tunnel (not wanted - unpredictable behavior??)

What is the frequency that a tunnel will try to contact the destination?

As I understood: In a scenario with crypto map on the interface, dialer interface and crypto acl:

multicast traffic can trigger a dial (to keep it simple: ip permit all), but will normally not match a crypto acl and thus not trigger a phase 1 setup

further, with crypto maps like this, there is a static route required which must cover the interesting traffic (0.0.0.0/0 or more specific

Already many thanks> This gives me more insight in how it really works

[Peter Paluch]

Hello Rik,

First of all, I see you writing here about two tunnels. I do not quite understand what you have in mind. A dialer interface is not a tunnel. Only the interface Tunnel is considered to be a tunnel, and also, a crypto map assigned to an outside interface can be considered a tunnel - a tunnel without its own interface. I am slightly confused by your explanation about a tunnel and a backup interface... what is what in your description? Perhaps, if you are trying to configure a particular scenario you could describe it here.

Also, I am sure you are aware of it but I write it here to make sure: a traffic that is routed out a tunnel interface is processed by its configuration, but because the tunnel interface is not a real physical interface, it is not the final interface through which the traffic flows. After it has gone over a tunnel interface, an additional encapsulation has been added to, and it is being routed again to the tunnel destination as any other packet. So it will go out the dialer interface, or some other interface - that depends only on your routing table.

A dialer interface is always up/up, regardless whether there is actually a call in progress or not. This solves the basic chicken-and-egg problem where only a traffic going out a dialer interface can trigger a call, but no traffic can go out a dialer interface if it is not up/up. Therefore, the state of a properly configured dialer interface is always up/up so that it can be referred to in a routing table and traffic can be routed over it. Note the following output about a dialer interface using the "show interface" command:

Dialer1 is up, line protocol is up (spoofing)

Hardware is Unknown

Internet address is 10.255.255.11/32

The (spoofing) word says that regardless of the actual state of the call, the interface is artificially held in up/up state.

The tunnel interface is somewhat different in this aspect. For a tunnel to be up/up, the source interface must be up/up, it must have an IP address, and the destination must be reachable according to your own routing table. The tunnel state is event-driven: whenever a change on the source interface or in the routing table occurs, the IOS checks whether the conditions described earlier are still met. If not, the tunnel will put to up/down state, otherwise, the tunnel will be brought up. So for a tunnel, there is no frequency to contact the destination - rather, an event-driven process in the IOS controls the state of tunnel interfaces whenever a change to routing table or to the source interfaces occurs.

Often, the IP address of the dialer interface is automatically assigned by the ISP ("ip address negotiated"). This creates a problem if the tunnel uses the dialer as the source interface: a tunnel interface will not be up/up until the source interface has an IP address. It does not have to be manually set up - it can be assigned by an ISP automatically but now we have a chicken-and-egg problem here: if a tunnel interface can't come up, no traffic can flow through it. If no traffic can flow through it, the dialer interface won't make a call. If the dialer interface won't make a call, it won't be assigned an IP address. And if it can't be assigned an IP address, the tunnel interface can't go up.

This problem can be easily resolved by saying dialer persistent on the Dialer interface. This command causes the dialer interface to immediately place a call without any traffic, and to never end that call. It will immediately negotiate the IP address with the ISP and the tunnel can then come up.

I have a feeling that you are somehow mixing the dialer interfaces, crypto maps and tunnel interfaces together. Perhaps we should discuss these concepts individually, not combining them together - because they are independent and it is both more easy to explain their principles individually, and more easy to see their interaction later when they are combined.

Best regards,

Peter

[Rik19972000]

this is exactly what I mean:

e tunnel interface is somewhat different in this aspect. For a tunnel to be up/up, the source interface must be up/up, it must have an IP address, and the destination must be reachable according to your own routing table. The tunnel state is event-driven: whenever a change on the source interface or in the routing table occurs, the IOS checks whether the conditions described earlier are still met. If not, the tunnel will put to up/down state, otherwise, the tunnel will be brought up. So for a tunnel, there is no frequency to contact the destination - rather, an event-driven process in the IOS controls the state of tunnel interfaces whenever a change to routing table or to the source interfaces occurs.

Often, the IP address of the dialer interface is automatically assigned by the ISP ("ip address negotiated"). This creates a problem if the tunnel uses the dialer as the source interface: a tunnel interface will not be up/up until the source interface has an IP address. It does not have to be manually set up - it can be assigned by an ISP automatically but now we have a chicken-and-egg problem here: if a tunnel interface can't come up, no traffic can flow through it. If no traffic can flow through it, the dialer interface won't make a call. If the dialer interface won't make a call, it won't be assigned an IP address. And if it can't be assigned an IP address, the tunnel interface can't go up.

I'll explain more in detail what I want to accomplish

*an ADSL line with static IP (Dialer1)

tunnel to HQ over ADSL via virtual tunnel interface.

int tun 1

tunnel source Dialer1

tunel destination HQ_IP

tunnel protection ipsec TP

tunnel mode ipsec ipv4

*a second DDR interface (which serves as backup) needs to make a call to HQ (same peer IP). A crypto map is placed on this interface in order to setup a tunnel.

=>dynamic IP address

over the primary link EIGRP is done, from which it will receive a default route.

thus

°ip route 0.0.0.0.0 0.0.0.0.0 DDR_interface 150 (AD > 90, AD EIGRP route it receive from HQ)

°ip route HQ_IP dialer1

router eigrp 10

no passive-interface Dialer1

...

1) will the EIGRP traffic initiate a call?

if yes - great, then the Dialer interface will come up

negotiate IP

setup tunnel

receive default route (which overrules the default route via DDR)

--> no ip route 0.0.0.0.0 0.0.0.0 Dialer1 required then

when ADSL looses connection, other default route is placed (via DDR) all traffic is interesting traffic for the dialer interface,... etc etc

When the ADSL is restored, the EIGRP will poke the Dialer interface etc etc...

As I've understood the tunnel comes up if the source interface is up and destination can be reached.

Thank you very much Peter.

If you've a dynamic IP at remote --> is Dynamic VTI better than dynamic crypto map on HQ. I don't want to have a IGP run over it

[Peter Paluch]

Hello Rik,

I will now answer directly to your questions and remarks.

Will the EIGRP traffic initiate a call? - I assume that the Dialer uses "ip address negotiated". In this case, the answer is no - again, not because of dialer list but because of another chicken-and-egg problem. Until the Dialer has actually made a call, it will not have an IP address. You cannot run EIGRP on an interface that does not have an IP address. You do not have any network on the Dialer interface to enter into EIGRP. I've noticed that you have suggested using the "no passive-interface Dialer1" but that alone does not accomplish anything. The dialer is not a passive interface by default so by entering that command, you actualy did nothing.

Note that you do not need the EIGRP to trigger a call for you. By using the command dialer persistent in the Dialer configuration, you will force it to make a call as soon as the router comes up, and the call will never end.

no ip route 0.0.0.0.0 0.0.0.0 Dialer1 required then - Well, it seems that you indeed do not to have it configured at all - assuming that all your traffic should be routed over a tunnel only. In the beginning, you only need to set up a static route to the other tunnel's end and when the tunnel comes up the default route will be delivered by EIGRP, as you say.

If you've a dynamic IP at remote --> is Dynamic VTI better than dynamic crypto map on HQ?. I believe it depends on your requirements. The Dynamic VTI allows you to configure a template from which the configuration for all IPsec remote accesses will be cloned. This greatly simplifies, for example, the NAT configuration when the branches need to access internet over the HQ. With crypto maps, you would not be able to solve with traditional NAT as the outside interface of the HQ where the crypto map is applied would need to be both inside and outside. But personally I think for simple deployments, there are no significant advantages.

That being said, if you like the idea of Dynamic VTI and you do not plan to run IGP over it, then why not? :-)

Now I am slightly confused. You are saying that you won't be running IGP over it, yet before, you spoke about EIGRP and default route advertised by it. Is it meant to be the same issue?

Best regards,

Peter

[davy.timmermans]

Hi Peter,

What are recommended values for dialer persistent? (initial delay, delay)

I could use this command also ;)

[Peter Paluch]

Hi Davy,

I have no special recommendations for that. The default delay and initial delay is 1 second which should be appropriate for most dial-up scenarios. It really depends on your requirements. If you just need the dialer to go up right after the router boots up and to reconnect in a reasonable time after a connection has been interrupted for whatever reason then I believe you will be satisfied with the current default values.

Just in case you need detailed information, visit this URL (it's a command reference manual and a configuration guide):

http://www.cisco.com/en/US/docs/ios/dial/command/reference/dia_d1.html#wp1014161

http://www.cisco.com/en/US/docs/ios/dial/configuration/guide/dia_dialer_persist_ps6350_TSD_Products_Configuration_Guide_Chapter.html

Best regards,

Peter