All_about_network

As I promised there goes some stuff I was having fun with lately. Followingscenario is from real life and includes some interesting combinations of features.

The problem is stated as follows:

1. AR 19-X is a CPE that is connected to ADSL (SHDSL) line of ISP
2. You need to use GRE tunnel for transporting L3 multicast (especially for OSPF) and IPSec for ensuring your data integrity
3. Some basic QoS shaping should be enabled on the traffic before entering the IPSec tunnel

So step one is creating the ADSL interface and related tasks.

#
interface Atm1/0
pvc 8/50
map bridge Virtual-Ethernet 0
#

The command map bridge Virtual Ethernet 0 is to bind this ATM interface do an virtual interface where you can allocate IP behavior. This is necessary as th ATM has noway of working with IP addressing directly.

Next step is obviously configuring how the Virtual Ethernet will behave.

for direct addressing you can use

#
interface Virtual-Ethernet0
ip address A.B.C.D

or if you want to use pppoe protocol (which is more common) :

#
interface Virtual-Ethernet0
pppoe-client dial-bundle-number 1

So if we need four our device usage of pppoe in this config (as CPE) it has to be pppoe client. The next config relates to this.

#
dialer-rule 1 ip permit
(permits IP traffic to pass in pppoe session)

#
local-user test
password simple password
service-type ppp
(this creates a local user for authentication over pap or chap)

#
interface Dialer1
link-protocol ppp
ppp pap local-user userpassword simple password
ip address ppp-negotiate
dialer user user
dialer-group 1
dialer bundle 1
(this is a virtual dialed connection interface for any ppp type connection from huawei routers)
(in this case is used pap but for chap there is only a minor change in line ppp chap local-user)

So if you have this configured your atm interface should be up so as you virtual Ethernet and dialer interfaces. In this phase the most common problem is mismatch of passwords. Be aware that the VRP 5.20 has password cyphered as default which won’t work in most scenarios against other devices than Huawei/H3C/3Com.

Problems in pap/chap are seen as frequently flapping interfaces (ATM,Virtual Ethernet and dialer subsequently).

So if this is set and ready there is a next step – configuring a GRE and ipsec tunnels.

Configuring GRE is kind of easy because it is a default tunnel encapsulation. As for IPSec I think I covered that topic in my previous posts more or less completely. Te only thing I would like to  pinpoint is the necessity of creation of a virtual interface for the tunnel and very important – correct routing.

#
interface Tunnel0
ip address 10.0.0.2 255.255.255.252 (IP address of the tunnel endpoint)
source S.R.C.IP (CPE’s wan IP address)
destination D.S.T.IP (remote end IP add)
(these three steps are enough for GRE tunnel creation)

#
ike proposal 1
encryption-algorithm aes-cbc 128
dh group2
#
ike peer 1
pre-shared-key simple IPSecPass
remote-address D.S.T.IP
#
ipsec proposal 1
esp authentication-algorithm sha1
esp encryption-algorithm aes 128
#
ipsec policy 1 10 isakmp
security acl 3100
ike-peer 1
proposal 1

(only one note which I did not explain in previous posts – the IKE proposal is not bonded anyhow because the number means only a priority so when establishing a tunnel all the IKEs are tried until the matching is found – so  it is a good practise to have the most used IKE on the top of the heap)

acl number 3100 name ipsec
rule 5 permit gre source S.R.C.IP 0 destination D.S.T.IP 0
#

If you look at the ACL you will see the first (and the last) difference in the IPsec construction. Instead of protocol IP there is used a protocol of GRE which is because we want to encrypt the traffic already encapsulated into the GRE. The other thing is that we are matching exactly the endpoints ot that tunnel. This is a good thing if you think ahead because you can have multiple tunnels with multiple separated endpoints and have it (or not have it) under one ACL. So this is highly flexible construction.

After this there are only two tasks left to have the functional config.

1. Tell what and where to encrypt
2. Set the correct routing

Applying the IPSec tunnel is according to the same logic as in the before mentioned cases – it should be on outbound interface. As this scenario is little bit tricky this time it should be the dialer interface (as it is the equivalent of interface Ethernet in the previous posts).

#
interface Dialer1
ipsec policy 1
#

So with this the IPSec config is done and should work. More importantly you need to setup the routing. I put it on tha last step but actually if you want to see the progress of your work you will definitely need it much earlier. But as routing is not a topic of this article and I give it here just for completing the setup to the working stage I think the last position is justified.

There are actually only two routes (in case you use more than one pppoe session the config will change accordingly)

#
ip route-static 0.0.0.0 0.0.0.0 Dialer1
(setting everything to go over the ADSL line)
ip route-static DST.INT.LAN.IP M.A.S.K Tunnel0
(to route LAN traffic to the remote LAN into the tunneling mechanism)(to route LAN traffic to the remote LAN into the tunneling mechanism)

Now it should work. In the follow up article I will continue with the QoS. Hope this will be of some use to anyone ;)