Hỏi Về Cấu Hình Megawan VTN Sử Dụng Router 878 G.GHDSL

[TMQ]

Xin chào.
Cho em hỏi về cấu hình router 878 chạy megawan của VTN.
Em chạy 3 văn phòng kết nối với nhau.
Các anh chị hướng dẫn giúp em với.
Mong tin các anh chị.
Em cám ơn.

[tana]

who are you ?

[goldarrow]

Theo mình biết khi xài megawan VTN thì bạn sẽ kết nối theo kiểu hình sao (hình sao này nằm trong nội bộ của VTN).
Khi đó thì VTN sẽ route cho bạn các lớp mạng riêng tại mỗi văn phòng để chúng thấy nhau.
Bạn cũng phải cấu hình tại con 878 cho các lớp mạng của mình.
Có một điều con 878 này chạy qua port Rj11 và sử dụng cáp đồng nên tốc độ tối đa là 2Mb thôi.

"Không có việc gì khó chỉ sợ tiền không nhiều"
goldarrow

[TMQ]

Theo mình biết khi xài megawan VTN thì bạn sẽ kết nối theo kiểu hình sao (hình sao này nằm trong nội bộ của VTN).
Khi đó thì VTN sẽ route cho bạn các lớp mạng riêng tại mỗi văn phòng để chúng thấy nhau.
Bạn cũng phải cấu hình tại con 878 cho các lớp mạng của mình.
Có một điều con 878 này chạy qua port Rj11 và sử dụng cáp đồng nên tốc độ tối đa là 2Mb thôi.

"Không có việc gì khó chỉ sợ tiền không nhiều"
goldarrow

dạ, VTN họ route các lớp mạng riêng tại mỗi văn phòng cái này VTN họ gọi là "Route LAN", ngoài ra còn 1 hình thức khác nữa là "Tunnel".
Route LAN dở ở chổ khi mở rộng thêm mạng phải khai báo với VTN không chủ động được, Tunnel thì tốt hơn có thể tự chủ động.
Route LAN cấu hình chỉ là đẩy ra gateway thôi.
Tunnel thì em chưa biết cấu hình trên Router 878 như thế nào, mong các anhc hỉ bảo thằng em nhỏ, Em xin cám ơn.

[thanhnam0707]

Bạn xem cấu hình mầu này nhé:
!
controller DSL 0/0/0
mode atm
line-term cpe
line-mode 2-wire line-zero
dsl-mode shdsl symmetric annex B
line-rate auto
!
interface ATM0/0/0
description MANG WAN
ip address 1.1.1.2 255.255.255.252
no atm ilmi-keepalive
crypto map SIDES
pvc 8/35
cbr 1024
encapsulation aal5snap
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key cisco address 1.1.1.6 // ip destination của router đầu xa
!
crypto ipsec transform-set myset esp-3des esp-md5-hmac
!
crypto map SIDES 1 ipsec-isakmp
set peer 1.1.1.6 // ip destination của router đầu xa
set transform-set myset
match address 100
!
interface Tunnel0
description Connect to Router đầu xa
ip address 2.2.2.1 255.255.255.252
tunnel source ATM0/0/0
tunnel destination 1.1.1.6 // ip destination của router đầu xa
crypto map SIDES
!
ip route 192.168.6.0 255.255.255.0 Tunnel0 //Route về Lan phía router đầu xa
!
access-list 100 permit gre host 1.1.1.2 host 1.1.1.6
!
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

[TMQ]

Em cám ơn.
Em chưa có thiết bị đang đợi hàng về mới test được nhưng em đã ghi vào tập rồi.

Cho em hỏi là em cấu hình cho 3 site thấy nhau thì củng làm tương tự chứ ạ.
Và đây là cấu hình VPN Site to Site ạ?
Thanks.

[phamminhtuan]

GRE-Multipoint

Chào bạn,

Nếu làm 3 site thì cũng dùng giống như thanhnam0707 nhưng cấu hình có khác chút.
Ví dụ như bên dưới

Từ khóa: GRE- Multipoint



HUB:

Table5: multipoint GRE parameters on HUB

Tunnelling parameters

Any multipoint tunnel peer

Tunnel interface Tunnel 1 Tunnel ip address &mask 192.168.123.1/24 Tunnel source interface s0/0.102 Tunnel destination interface ??????????????????????
HUB:

HUB(config-if)#int tunnel 2
HUB(config-if)#ip address 192.168.123.1 255.255.255.0

HUB(config-if)#tunnel mode gre multipoint

HUB(config-if)#tunnel source s0/0.102

HUB(config-if)#

*Mar 1 01:00:07.707: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

SpokeB:

Table6: multipoint GRE parameters on SpokeB

Tunnelling parameters

Any multipoint tunnel peer

Tunnel interface Tunnel 1 Tunnel ip address &mask 192.168.123.2/24 Tunnel source interface s0/0 Tunnel destination interface ??????????????????????
SpekeB:

SpokeB(config-if)#int tunnel 1
SpokeB(config-if)#ip address 192.168.123.2 255.255.255.0

SpokeB(config-if)#tunnel mode gre multipoint

SpokeB(config-if)#tunnel source s0/0

SpokeB(config-if)#

*Mar 1 01:00:27.419: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

SpokeC:

Table7: multipoint GRE parameters on SpokeC

Tunnelling parameters

Any multipoint tunnel peer

Tunnel interface Tunnel 1 Tunnel ip address &mask 192.168.123.3/24 Tunnel source interface s0/0.300 Tunnel destination interface ??????????????????????
SpokeC :

SpokeC(config-subif)#int tunnel 1
SpokeC(config-if)#ip address 192.168.123.3 255.255.255.0

SpokeC(config-if)#tunnel mode gre multipoint

SpokeC(config-if)#tunnel source s0/0.300

SpokeC(config-if)#

*Mar 1 01:02:13.995: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

HUB:

HUB(config-if)#do sh int tunnel 2
Tunnel2 is up, line protocol is up

Hardware is Tunnel

Internet address is 192.168.123.1/24

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 172.16.0.33 (Serial0/0.102), destination UNKNOWN

Tunnel protocol/transport multi-GRE/IP

Key disabled, sequencing disabled

Checksumming of packets disabled

Fast tunneling enabled

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

…

HUB(config-if)#

At this point you cannot miss the fact that it is not possible to set in advance the tunnel destination interface (GRE destination address) for multipoint GRE, here resides the concept of mGRE: one interface that ends multiple tunnels; hence the need for a mechanism that will identify the remote peer’s tunnel end point ip address in advance, NHRP (Next Hop Resolution Protocol).

Each spoke has been configured with a static map of the HUB tunnel IP address (192.168.123.1) and its NBMA address (172.16.0.33)

ip nhrp map 192.168.123.1 172.16.0.33
So each spoke NHRP starts registering itself by forming a tunnel with the HUB, the destination interface is taken from the previously configured static map.

Finally the concept is very similar to the mapping in Frame Relay where a destination NBMA IP (layer3) is mapped to a DLCI ( PVC, layer 2) either statically or dynamically through inverse ARP.

With mGRE a tunnel (logical source and destination IP’s) is necessary delimited by NBMA addresses, the destination one being unknown can be resolved statically through NHRP map or dynamically by requesting the NHRP server, the HUB. (figure3)

Figure3: FR mapping and mGRE mapping



Once resolved each Spoke forms a tunnel with the HUB, here comes the routing protocol, OSPF is announced on tunnel interfaces, so adjacency relationships will be formed with the HUB, it is important to tell routers that broadcast and multicast will be sent to the HUB, so they could exchange routing information.

ip nhrp map multicast 172.16.0.33
The command is very similar to FR:

frame-relay map ip <nbma-dest-ip-next-hop> <local-dlci> broadcast
Though the routing information between spokes is exchanged through the router, routing information populated in routing tables points to logical addresses (tunnel IP’s) and the NBMA addresses still unknown.

mGRE needs to resolve the NBMA destination address; spokes ask the HUB (NHS) what NBMA address correspond to a particular tunnel (logical) IP, the HUB respond from its NHRP records, the spoke use the obtained NBMA address as a destination and communicate directly with the destination spoke.

The following command instruct spokes where to forward the NHRP requests, if not specified the spoke will take the next-hop from the routing table.

ip nhrp nhs 192.168.123.1
Figure4 depicts the data flow between spokes and HUB:

Figure4: Data flow



TableX: NHRP commands

ip nhrp network-id <number> Logical NBMA cloud to which the interface belongs. ip nhrp interest <ACL> Tells the router when to send NHRP requests. ip nhrp used <number> Send NHRP requests when there are certain number of packets for a destination. ip nhrp map <x.x.x.x> <data-link> Statically configure a router interface with NHRP data link layer (not needed with PVC) ip nhrp map multicast <remote_NBMA_desti_IP> Broadcast/multicast will be sent to a particular end- point of the tunnel. ip nhrp nhs <x.x.x.x> network <network> Statically configure NHS, otherwise NHRP will follow routing information that will point to a HUB. ip nhrp authentication <string> Configure authentication for NHRP peering ip nhrp max-send <packets> every <time- interval> Control the maximum rate of NHRP messages sent, by default 5 packets every 10 seconds. ip nhrp responder <inttype X/X> Set the source address of NHRP server replies. ip nhrp holdtime <sec> <sec> Lifetime of NHRP information, default 7200sec (2 hours) for negative and positive responses.
Here is how all configuration commands look like:

HUB:

interface Tunnel2
ip address 192.168.123.1 255.255.255.0

ip nhrp authentication cisco

ip nhrp map multicast dynamic

ip nhrp network-id 123

ip ospf network broadcast

ip ospf priority 10

tunnel source Serial0/0.102

tunnel mode gre multipoint

tunnel key 123 !! ===> If you have set a tunnel key, it should be the same on all

!! routers that participate to the tunnel

!

interface Serial0/0

no ip address

encapsulation frame-relay

no frame-relay inverse-arp

!

interface Serial0/0.101 point-to-point

ip address 172.16.0.17 255.255.255.240

frame-relay interface-dlci 101

!

interface Serial0/0.102 multipoint

ip address 172.16.0.33 255.255.255.240

ip ospf network broadcast

ip ospf priority 10

frame-relay map ip 172.16.0.34 102 broadcast

frame-relay map ip 172.16.0.35 103 broadcast

SpokeB:

interface Tunnel1
ip address 192.168.123.2 255.255.255.0

ip nhrp authentication cisco

ip nhrp map multicast 172.16.0.33

ip nhrp map 192.168.123.1 172.16.0.33

ip nhrp network-id 123

ip nhrp nhs 192.168.123.1

ip ospf network broadcast

ip ospf priority 0

tunnel source Serial0/0

tunnel mode gre multipoint

tunnel key 123

!

interface Serial0/0

ip address 172.16.0.34 255.255.255.240

encapsulation frame-relay

frame-relay map ip 172.16.0.33 201 broadcast

frame-relay map ip 172.16.0.35 203 broadcast

no frame-relay inverse-arp

SpokeC:

interface Tunnel1
ip address 192.168.123.3 255.255.255.0

ip nhrp authentication cisco

ip nhrp map multicast 172.16.0.33

ip nhrp map 192.168.123.1 172.16.0.33

ip nhrp network-id 123

ip nhrp nhs 192.168.123.1

ip ospf network broadcast

ip ospf priority 0

tunnel source Serial0/0.300

tunnel mode gre multipoint

tunnel key 123

!

interface Loopback0

ip address 10.30.0.1 255.255.0.0

!

interface Serial0/0

no ip address

encapsulation frame-relay

no frame-relay inverse-arp

!

interface Serial0/0.300 multipoint

ip address 172.16.0.35 255.255.255.240

frame-relay map ip 172.16.0.33 301 broadcast

frame-relay map ip 172.16.0.34 302 broadcast

Make sure that tunnel key match with all routers participating in the same mGRE.

Monitoring:

HUB:

HUB#sh ip nhrp
192.168.123.2/32 via 192.168.123.2, Tunnel2 created 00:55:29, expire 01:43:40

Type: dynamic, Flags: authoritative unique registered

NBMA address: 172.16.0.34

192.168.123.3/32 via 192.168.123.3, Tunnel2 created 00:55:52, expire 01:44:07

Type: dynamic, Flags: authoritative unique registered

NBMA address: 172.16.0.35

HUB#

Note from the following tunnel debugging that though tunnel destination is not pre-configured, as a result of NHRP, the router resolved the detination source interface of the tunnel according to the logical destination it wanted to reach:

HUB#ping 10.30.0.1
!!==>We want to reach SpokeC private network
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.30.0.1, timeout is 2 seconds:

!!!!!

*Mar 1 01:00:30.171: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:00:30.179: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:00:30.183: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

*Mar 1 01:00:30.311: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:00:30.315: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:00:30.319: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/126/216 ms

HUB#

*Mar 1 01:00:30.451: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:00:30.459: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:00:30.459: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

*Mar 1 01:00:30.531: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:00:30.539: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:00:30.543: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

*Mar 1 01:00:30.595: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:00:30.599: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:00:30.603: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

*Mar 1 01:00:32.415: Tunnel1: GRE/IP encapsulated 172.16.0.17->172.16.0.18 (linktype=7, len=104)

HUB#

HUB#

HUB#ping 10.20.0.1
!!==> Now we want to reach SpokeB private network

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.20.0.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 76/121/164 ms

HUB#

*Mar 1 01:01:55.943: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:01:55.947: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:01:55.951: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)

*Mar 1 01:01:56.111: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:01:56.115: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:01:56.119: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)

*Mar 1 01:01:56.239: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:01:56.243: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:01:56.247: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)

*Mar 1 01:01:56.315: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:01:56.319: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:01:56.323: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)

*Mar 1 01:01:56.395: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

*Mar 1 01:01:56.403: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

*Mar 1 01:01:56.407: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)un all

*Mar 1 01:01:58.083: Tunnel1: GRE/IP to classify 172.16.0.18->172.16.0.17 (len=104 type=0×800 ttl=254 tos=0xC0)

*Mar 1 01:01:58.087: Tunnel1: GRE/IP to decaps 172.16.0.18->172.16.0.17 (len=104 ttl=254)

*Mar 1 01:01:58.091: Tunnel1: GRE decapsulated IP 192.168.10.2->224.0.0.5 (len=80, ttl=1)

All possible debugging has been turned off

HUB#

The following debug detail the process of the initial NHRP registration when SpokeB tunnel goes up:

HUB#

*Mar 1 01:15:02.575: NHRP: Receive Registration Request via Tunnel2 vrf 0, packet size: 81

*Mar 1 01:15:02.579: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar 1 01:15:02.579: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 01:15:02.579: (M) flags: “unique”, reqid: 5

*Mar 1 01:15:02.583: src NBMA: 172.16.0.34

*Mar 1 01:15:02.583: src protocol: 192.168.123.2, dst protocol: 192.168.123.1

*Mar 1 01:15:02.587: (C-1) code: no error(0)

*Mar 1 01:15:02.591: prefix: 255, mtu: 1514, hd_time: 7200

*Mar 1 01:15:02.591: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar 1 01:15:02.595: NHRP: Send Registration Reply via Tunnel2 vrf 0, packet size: 101

*Mar 1 01:15:02.599: src: 192.168.123.1, dst: 192.168.123.2

*Mar 1 01:15:02.603: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar 1 01:15:02.603: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 01:15:02.607: (M) flags: “unique“, reqid: 5

*Mar 1 01:15:02.607: src NBMA: 172.16.0.34

*Mar 1 01:15:02.611: src protocol: 192.168.123.2, dst protocol: 192.168.123.1

*Mar 1 01:15:02.615: (C-1) code: no error(0)

*Mar 1 01:15:02.615: prefix: 255, mtu: 1514, hd_time: 7200

*Mar 1 01:15:02.619: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar 1 01:15:03.659: %OSPF-5-ADJCHG: Process 10, Nbr 2.2.2.2 on Tunnel2 from LOADING to FULL, Loadi ng Done

HUB#

And here the process of NHRP request for resolution from SpokeC that wants to reach SpokeB private network:

HUB#
*Mar 1 01:21:51.131: NHRP: Receive Registration Request via Tunnel2 vrf 0, packet size: 81

*Mar 1 01:21:51.135: NHRP: netid_in = 123, to_us = 0

*Mar 1 01:21:51.135: NHRP: Finding next idb with in_pak id: 0

Trích

[TMQ]

thanks anh, không biết có thể chạy chứng thực VPN mà route tĩnh không ạ.
Thanks.

[hailaxd99cntt]

Theo mình biết khi xài megawan VTN thì bạn sẽ kết nối theo kiểu hình sao (hình sao này nằm trong nội bộ của VTN).
Khi đó thì VTN sẽ route cho bạn các lớp mạng riêng tại mỗi văn phòng để chúng thấy nhau.
Bạn cũng phải cấu hình tại con 878 cho các lớp mạng của mình.
Có một điều con 878 này chạy qua port Rj11 và sử dụng cáp đồng nên tốc độ tối đa là 2Mb thôi.

"Không có việc gì khó chỉ sợ tiền không nhiều"
goldarrow

Bạn ơi 878 có thể chay FE được đấy -> tốc độ không giới hạn 2M nữa có điều phải nâng cấp IOS lên bản c870-advsecurityk9-mz.124-15.T4 thì mới được.

[phamminhtuan]

thanks anh, không biết có thể chạy chứng thực VPN mà route tĩnh không ạ.
Thanks.

Chào bạn,

Có thể chạy VPN và chạy được các giao thức động, lúc này nó gọi là DMVPN.
Và tất nhiên route tĩnh chắc chắn chạy được.