シスコサポートコミュニティ
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
告知
シスコ サポート コミュニティへようこそ!あなたの ご意見 をお聞かせください。

「エキスパートに質問」WAN, ルーティング, スイッチングについて

シスコの技術サポートエンジニアへ質問して疑問を解決できる「エキスパートに質問」へようこそ!

ここでは、シスコのエキスパートからのアドバイスや最新の情報が得られる場として気軽に質問してみてください。

担当エキスパート:「 新谷 剛史 (ニイタニ ツヨシ)」

ディスカッション開催期間:2011年8月1日~2011年8月14日

「新谷 剛史」は、Cisco Japan TAC のカスタマーサポートエンジニアとして10年ほどサポートを行っております。

CRS-1 等の SP 向けルータのサポートを行っていた時期もありますが、

現在は一般的なルータやL3スイッチでのルーティングを主にサポートしています。

CCIE の R&S 及び SP トラック(#9745)を保有しています。


[質問の投稿方法]

サポートコミュニティへCisco.comIDでログインすると、この説明の右下に「返信」ボタンが表示されます。クリックすると投稿欄が表示されますので、質問をご記入ください。最後に「メッセージの投稿」をクリックすると質問が送信され、完了となります。

もし1つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。
この「エキスパートに質問」のディスカッションスレッドに届いた質問は担当のTACエキスパートが回答しますがすべての質問に返信できないかもしれません。
返信が得られずに開催期間が終了して残ってしまった質問については、サポートコミュニティ事務局が通常のディスカッション フォーラムへ再掲載し、有用な情報の展開へとつなげていきます。

エキスパートから返信が得られた質問については、評価機能でその回答が適切であったかをエキスパートへぜひ伝えてください。

あなたからの質問だけでなく、他コミュニティのメンバーから寄せられた質問の展開を確認するためにも、ぜひこのフォーラムへ再度訪問されることをお待ちしております!

23 件の返信

Re: 「エキスパートに質問」WAN, ルーティング,

いつもお世話になっております。


データセンター相互接続ソリューションを検討しています。


現在、データセンターに VMWawre による仮想インフラを構築していますが、

将来的に複数のデーターセンターを相互接続し、データーセンター間の

仮想マシンライブマイグレーションが実現できないか検討しています。

以下の PTC セミナー資料によると、151-4.M1 等でサポートされる「LISP」の

Dynamic EID を使用することで、実現できそうなのですが、認識間違っていないでしょうか。
http://www.cisco.com/web/JP/partners/pec/ptc/ptc.html

(Other) LISP(Locator/ID Separation Protocol)のご紹介


想定する構成としては、上記資料のスライド47 「シナリオ2:L3接続」 なのですが、

具体的な設定方法、もしくは参考となるドキュメント等をご教示頂ければ幸いです。

(移行後、PTR の LAN 側のセグメントと異なるセグメントを持つホストが、

どのようにして通信を継続するのか等、非常に興味があります。)


どうぞよろしくお願い致します。

New Member

「エキスパートに質問」WAN, ルーティング, スイ

892Jを使用しています。

以下の1.2.3の現象が発生しており、
原因と、対応策を教えて頂きたいです。

1.LAN型払い出し形式でPPPOE接続しているのですが、
892Jからpingを飛ばすと以下の表示がされます。

####################################################################################
ping yahoo.com

Translating "yahoo.com"...domain server (xxx.135.90.1) (xxx.135.65.2)
% Unrecognized host or address, or protocol not running.
####################################################################################

xxx.135.90.1、xxx.135.65.2は外部のDNSサーバアドレスになります。

(xxxは同じアドレスが入っています。)

2.サーバを892Jに接続しており、外部に接続は出来るのですが、
非常に重いです。

3.サーバでHPを表示しようとブラウザを立ち上げた際、
接続先により、ページを接続出来たり、出来なかったりします。
ただし、接続出来ても非常に重い状態です。
(例. yahoo.co.jpには接続出来ないが、googleには接続出来る。)

ノートPCをサーバが使用している物理ポートに接続し、
同じIPアドレスやデフォルトゲートウェイを設定した場合は
上記二つの現象は発生しません。

以下は補足情報になります。

LAN型払い出し形式では、以下の形式で払い出しがされています。

固定IPアドレス---------------------------- xxx.173.243.8/29
ゲートウェイアドレス---------------------- xxx.173.243.9
使用可能アドレス-------------------------- xxx.173.243.10~14

show pppoe sessionの結果は以下の通りです。

####################################################################################
Uniq ID  PPPoE  RemMAC          Port                  Source   VA         State
           SID  LocMAC                                         VA-st
    N/A  50458  yyyy.yyyy.yyyy  Gi0                   Di0      Vi2        UP
                zzzz.zzzz.zzzz                                 UP
####################################################################################

show ip routeの結果は以下の通りです。

####################################################################################
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     192.168.11.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.11.0/30 is directly connected, Vlan100
C       192.168.11.8/29 is directly connected, Vlan110
     xxx.135.64.0/32 is subnetted, 1 subnets
C       xxx.135.64.97 is directly connected, Dialer0
S*   0.0.0.0/0 is directly connected, Dialer0
####################################################################################

show runの結果は以下の通りです。

####################################################################################
version 12.4
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
!
hostname XXXXX
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
logging buffered 512000
!
no aaa new-model
clock timezone JST 9
clock calendar-valid
!
!
ip source-route
!
!
!
!
ip cef
ip name-server xxx.135.90.1
ip name-server xxx.135.65.2
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
username comit password 0 5310
!
!
!
archive
log config
  hidekeys
!
!
!
!
!
interface BRI0
no ip address
encapsulation hdlc
shutdown
isdn termination multidrop
!
interface FastEthernet0
switchport access vlan 100
!
interface FastEthernet1
switchport access vlan 110
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
!
interface FastEthernet5
!
interface FastEthernet6
!
interface FastEthernet7
switchport access vlan 200
!
interface FastEthernet8
no ip address
shutdown
duplex auto
speed auto
!
interface GigabitEthernet0
no ip address
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Vlan1
ip address xxx.173.243.10 255.255.255.248
ip nat outside
ip virtual-reassembly
!
interface Vlan100
ip address 192.168.11.2 255.255.255.252
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1414
!
interface Vlan110
ip address 192.168.11.14 255.255.255.248
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1414
!
interface Vlan200
ip address 192.168.21.14 255.255.255.248
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1414
!
interface Dialer0
ip unnumbered Vlan1
ip mtu 1454
ip nat outside
ip virtual-reassembly
encapsulation ppp
ip tcp adjust-mss 1414
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname   (ID)
ppp chap password 0 (パスワード)
!
interface Dialer1
no ip address
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer0
no ip http server
no ip http secure-server
!
!
ip dns server
ip nat pool test xxx.173.243.9 xxx.173.243.14 netmask 255.255.255.248
ip nat inside source list 1 pool test overload
!
access-list 1 permit 192.168.21.0 0.0.0.7
access-list 1 permit 192.168.11.0 0.0.0.15
dialer-list 1 protocol ip permit
no cdp run

!
!
!
!
!
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
login
!
scheduler max-task-time 5000
end

####################################################################################

「エキスパートに質問」WAN, ルーティング, スイ

Jo Tamura様、

エキスパートへの質問をありがとうございます。

コミュニティ事務局からのお詫びなのですが、

担当エキスパートが今週明けから体調を崩してしまい、

回答が遅れています。

担当の新谷の準備が整い次第、返答いたしますので

ご了承いただけますようどうぞよろしくお願いいたします。

サポートコミュニティ事務局

Cisco Employee

「エキスパートに質問」WAN, ルーティング, スイ

お問い合わせいただきありがとうございます。

また、回答が遅くなりまして申し訳ございませんでした。

1.のご質問については、一般的にDNSサーバから query に対する reply が得られなかった場合に

表示されます。DNSサーバへのルーティングはデフォルトルートを使用するようですので、

まずはサーバへ直接ping疎通が可能かどうかをご確認ください。

ping の疎通ができない場合には、サーバー管理者などへお問い合わせください。

ping 疎通に問題がない場合には、debug domain コマンドを有効にした上で再度お試しいただき、

その出力内容を元にTACにサービスリクエストをオープンいただきますようお願いいたします。

ちなみに、正常に解決できる場合には debug によって下記のような出力が得られます。

(アドレス、ホスト名などは架空のものです)

--------------------------------------------------------------------------

Router#ping hogehoge.com

Translating "hogehoge.com"...domain server (100.1.1.2) [OK]

*Aug  5 01:22:41.867: Domain: query for hogehoge.com type 1 to 100.1.1.2

*Aug  5 01:22:41.875: DOM: dom2cache: hostname is hogehoge.com, RR type=1, class

=1, ttl=1, n=4Reply received ok

--------------------------------------------------------------------------

2.及び3.の問題につきましては、切り分けで使用いただいているノートPCでは、サーバと

同じアドレスを使用しても問題が発生していないようですので、ルータの問題というよりは

サーバに関する問題ではないかと考えられます。

接続アドレスによって遅かったり接続できなかったりする状況を考慮しますと、

一般的にこちらもDNS関係の問題が疑われるかと存じます。

よろしくお願いします。

New Member

Re: 「エキスパートに質問」WAN, ルーティング,

新谷様
ご回答有難うございます。
非常に助かります。

すみません、追加で質問させて下さい。

1.DNSサーバへのping疎通

直接ping疎通した結果、pingが飛びませんでした。
debug ip packet detail を有効化した結果は以下の通りです。

forus FALSE, sendself FALSEという表示が大量に出ているのですが、
原因を特定するコマンドなど、教えて頂ければと思います。
また、debugから読み取れる現象も教えて頂きたいです。

ルーター名#ping xxx.135.90.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to xxx.135.90.1, timeout is 2 seconds:

Aug  9 08:21:31.080: FIBipv4-packet-proc: route packet from (local) src xxx.173.243.10 dst xxx.135.90.1
Aug  9 08:21:31.080: FIBipv4-packet-proc: packet routing succeeded
Aug  9 08:21:31.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, sending
Aug  9 08:21:31.080:     ICMP type=8, code=0
Aug  9 08:21:31.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:31.080:     ICMP type=8, code=0, CCE Output Classification(5), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:31.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:31.080:     ICMP type=8, code=0, Post-routing NAT Outside(16), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:31.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:31.080:     ICMP type=8, code=0, Stateful Inspection(19), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:31.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:31.080:     ICMP type=8, code=0, TCP Adjust MSS(39), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:31.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:31.080:     ICMP type=8, code=0, Dialer idle reset(65), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:31.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Virtual-Access2), len 100, sending full packet
Aug  9 08:21:31.080:     ICMP type=8, code=0.
Aug  9 08:21:33.080: FIBipv4-packet-proc: route packet from (local) src xxx.173.243.10 dst xxx.135.90.1
Aug  9 08:21:33.080: FIBipv4-packet-proc: packet routing succeeded
Aug  9 08:21:33.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, sending
Aug  9 08:21:33.080:     ICMP type=8, code=0
Aug  9 08:21:33.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:33.080:     ICMP type=8, code=0, CCE Output Classification(5), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:33.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:33.080:     ICMP type=8, code=0, Post-routing NAT Outside(16), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:33.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:33.080:     ICMP type=8, code=0, Stateful Inspection(19), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:33.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:33.080:     ICMP type=8, code=0, TCP Adjust MSS(39), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:33.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:33.080:     ICMP type=8, code=0, Dialer idle reset(65), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:33.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Virtual-Access2), len 100, sending full packet
Aug  9 08:21:33.080:     ICMP type=8, code=0.
Aug  9 08:21:35.080: FIBipv4-packet-proc: route packet from (local) src xxx.173.243.10 dst xxx.135.90.1
Aug  9 08:21:35.080: FIBipv4-packet-proc: packet routing succeeded
Aug  9 08:21:35.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, sending
Aug  9 08:21:35.080:     ICMP type=8, code=0
Aug  9 08:21:35.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:35.080:     ICMP type=8, code=0, CCE Output Classification(5), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:35.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:35.080:     ICMP type=8, code=0, Post-routing NAT Outside(16), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:35.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:35.080:     ICMP type=8, code=0, Stateful Inspection(19), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:35.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:35.080:     ICMP type=8, code=0, TCP Adjust MSS(39), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:35.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:35.080:     ICMP type=8, code=0, Dialer idle reset(65), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:35.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Virtual-Access2), len 100, sending full packet
Aug  9 08:21:35.080:     ICMP type=8, code=0.
Aug  9 08:21:37.080: FIBipv4-packet-proc: route packet from (local) src xxx.173.243.10 dst xxx.135.90.1
Aug  9 08:21:37.080: FIBipv4-packet-proc: packet routing succeeded
Aug  9 08:21:37.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, sending
Aug  9 08:21:37.080:     ICMP type=8, code=0
Aug  9 08:21:37.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:37.080:     ICMP type=8, code=0, CCE Output Classification(5), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:37.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:37.080:     ICMP type=8, code=0, Post-routing NAT Outside(16), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:37.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:37.080:     ICMP type=8, code=0, Stateful Inspection(19), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:37.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:37.080:     ICMP type=8, code=0, TCP Adjust MSS(39), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:37.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:37.080:     ICMP type=8, code=0, Dialer idle reset(65), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:37.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Virtual-Access2), len 100, sending full packet
Aug  9 08:21:37.080:     ICMP type=8, code=0.
Aug  9 08:21:39.080: FIBipv4-packet-proc: route packet from (local) src xxx.173.243.10 dst xxx.135.90.1
Aug  9 08:21:39.080: FIBipv4-packet-proc: packet routing succeeded
Aug  9 08:21:39.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, sending
Aug  9 08:21:39.080:     ICMP type=8, code=0
Aug  9 08:21:39.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:39.080:     ICMP type=8, code=0, CCE Output Classification(5), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:39.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:39.080:     ICMP type=8, code=0, Post-routing NAT Outside(16), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:39.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:39.080:     ICMP type=8, code=0, Stateful Inspection(19), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:39.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:39.080:     ICMP type=8, code=0, TCP Adjust MSS(39), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:39.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Dialer0), len 100, output feature
Aug  9 08:21:39.080:     ICMP type=8, code=0, Dialer idle reset(65), rtype 1, forus FALSE, sendself FALSE, mtu 0
Aug  9 08:21:39.080: IP: s=xxx.173.243.10 (local), d=xxx.135.90.1 (Virtual-Access2), len 100, sending full packet
Aug  9 08:21:39.080:     ICMP type=8, code=0.

ちなみにdebug domainを有効化してyahoo.comにpingを行った結果は以下の通りです。

ルーター名#ping yahoo.com

Translating "yahoo.com"...domain server (xxx.135.90.1)
Aug  9 08:50:02.724: search_nametype_index: yahoo.com
Aug  9 08:50:02.728: search_nametype_index: yahoo.com
Aug  9 08:50:02.728: Domain: query for yahoo.com type 1 to xxx.135.90.1 (xxx.135.65.2)timed out
Aug  9 08:50:11.728: search_nametype_index: yahoo.com
Aug  9 08:50:11.728: Domain: query for yahoo.com type 1 to xxx.135.65.2
% Unrecognized host or address, or protocol not running.

timed out
Aug  9 08:50:20.728: delete_nametype_from_index: searching yahoo.com to delete
Aug  9 08:50:20.728: delete_nametype_from_index: name yahoo.com not found to del
Aug  9 08:50:20.728: delete_nametype_from_index: also found 0 entries to delete directly
Aug  9 08:50:20.728: add_nametype_to_index: added yahoo.com
Aug  9 08:50:20.728: search_nametype_index: yahoo.com
Aug  9 08:50:20.728: search_nametype_index: found yahoo.com for yahoo.com

2.DNSサーバへのルーティングについて

DNSサーバへのルーティングはデフォルトルートを使用していますが、
他のConfigを参考に設定しただけで、根拠がありません。

Ciscoとして、推奨しているルーティング方法があればご案内願います。

また、現在は1つのセッションを接続していますが、
2つのDialerにそれぞれセッションを割り当て、2つのセッションを同時に接続した場合、
現在の設定ですと、一つのDialerにしかデフォルトルートが当たりません。

将来的にマルチセッション環境に移行したいのですが、
セッションが複数の場合のルーティングについてもご案内頂きたいです。

3.トラブル対応方法について

接続出来ないなどの現象が発生した場合、
どこの機能をどのような順番でトラブルシューティングすれば良いかを
まとめたドキュメントなどがあればご案内願います。

以上です。よろしくお願いします。

Cisco Employee

Re: 「エキスパートに質問」WAN, ルーティング,

こちらの質問に関しましては、今回の TAC エキスパートの担当外のため

専門エンジニアより回答いたします。

追加質問をいただきましてありがとうございます。またご連絡が遅くなって

しまい、申し訳けございません。以下頂きました追加質問に回答致します。

>1.DNSサーバへのping疎通

>直接ping疎通した結果、pingが飛びませんでした。

>debug ip packet detail を有効化した結果は以下の通りです。

>forus FALSE, sendself FALSEという表示が大量に出ているのですが、

>原因を特定するコマンドなど、教えて頂ければと思います。

>また、debugから読み取れる現象も教えて頂きたいです。

弊社にて、相手のいない IP アドレスに ping を行った場合にも、forus FALSE,

sendself FALSEと表示されますので、このメッセージ自体が今回の問題に関して、

特別な意味を持っているわけではありません。結果から読み取れる事としては、

単純に相手端末からの応答がない事のみです。

また、DNSのデバッグも取得頂いておりますが、こちらの出力からも、DNSサーバ

からの応答がないという状態が確認できるのみです。

Aug  9 08:50:02.728: Domain: query for yahoo.com type 1 to xxx.135.90.1 (xxx.135.65.2)timed out

※ 弊社にて、DNSサーバの動作していない ping の届く端末を name-server に

指定した場合、以下のような結果となりました。

Aug 18 13:38:28.282: Domain: query for yahoo.com type 1 to 192.168.1.1 port unreachable error

※ 対向が存在しないアドレスを指定した場合は、ご提示いただいたデバッグ

出力と同じ結果が得られました。

PPPoE_Client#ping yahoo.com

Translating "yahoo.com"...domain server (192.168.1.10)

*Aug 18 14:06:22.934: search_nametype_index: yahoo.com

*Aug 18 14:06:22.934: search_nametype_index: yahoo.com

*Aug 18 14:06:22.934: Domain: query for yahoo.com type 1 to 192.168.1.10 (192.168.1.11)timed out

<snip>

以上の点から、ログからわかる状況としては、DNSサーバとは完全に通信ができて

いないということがわかりますが、ここからは、本当の原因は、わかりません。

Rouer からは、DNS/pingのいずれの場合でも、DNSサーバとは通信ができていませんが

先に頂きましたご報告では、Router に接続したサーバや、PC からは、遅いなどの症状が

伴うものの通信も確認できたようにお伺いいたしておりますので、Router で確認した結果

とは異なっています。

>>2.サーバを892Jに接続しており、外部に接続は出来るのですが、

>>非常に重いです。

>>

>>3.サーバでHPを表示しようとブラウザを立ち上げた際、

>>接続先により、ページを接続出来たり、出来なかったりします。

>>ただし、接続出来ても非常に重い状態です。

>>(例. yahoo.co.jpには接続出来ないが、googleには接続出来る。)

>>

>>ノートPCをサーバが使用している物理ポートに接続し、

>>同じIPアドレスやデフォルトゲートウェイを設定した場合は

>>上記二つの現象は発生しません。

よろしければ、NATの設定を以下のように変更してみて頂けますでしょうか?

interface vlan 1

no ip nat outside  <<< vlan 1 のip nat outeside は不要です。

no ip nat pool test xxx.173.243.9 xxx.173.243.14 netmask 255.255.255.248

no ip nat inside source list 1 pool test overload

ip nat inside source list 1 interface Vlan1 overload

上記は、NAT(overload)変換を行う際に、globalアドレスとして、Vlan1に

割当てたアドレスのみを使用する場合の設定になります。もし複数の

グローバルアドレスを使用して、ダイナミックにアドレスの変換テーブル

を使用する必要など無いようであれば、上記の変更をお試し頂け

ますようお願いいたします。

また、VLAN 100、110、200 などに小さいサブネットを設定していますが

なにか意図などはありますでしょうか?

特にないようであれば、プライベートアドレスを使用しておりますので

24 ビットマスクで設定いただいた方が、わかりやすいのではないかと思います。

また、ノート PCを Vlan1 に接続し、グローバルアドレスを設定し、DNSサーバに

対してPingを実施した場合には、応答はありますでしょうか?

ping のパケットサイズを変更した場合の動作に変化があるかどうかなども

確認頂けますよう、お願い致します。

そのほか、ノートPCを Vlan 100, 110, 200などに接続し、所定のアドレス

192.168.x.x を設定した場合は、NAT変換して通信を行うことになるもの

と思いますが、その場合の ping の結果などもご確認いただけます

よう、お願い致します。

>2.DNSサーバへのルーティングについて

>DNSサーバへのルーティングはデフォルトルートを使用していますが、

>他のConfigを参考に設定しただけで、根拠がありません。

>Ciscoとして、推奨しているルーティング方法があればご案内願います。

>

>また、現在は1つのセッションを接続していますが、

>2つのDialerにそれぞれセッションを割り当て、2つのセッションを同時に接続した場合、

>現在の設定ですと、一つのDialerにしかデフォルトルートが当たりません。

>

>将来的にマルチセッション環境に移行したいのですが、セッションが複数の場合の

>ルーティングについてもご案内頂きたいです。

DNSサーバへのルーティングに関しては、デフォルトルートを使用して

いる現状のままで、問題はありません。

マルチセッションに関しては、どのようなネットワークを構築したいのか

などの要件に依存するものと思いますので、構成図や、条件などをご提示

いただけますよう、お願い致します。よろしければ、本件の通信障害が

解決した後、あらためてご質問いただけますよう、お願い致します。

>3.トラブル対応方法について

>接続出来ないなどの現象が発生した場合、

>どこの機能をどのような順番でトラブルシューティングすれば良いかを

>まとめたドキュメントなどがあればご案内願います。

特にまとめられた資料などはありませんが、回線などから順番に確認ください。

1) Flets 回線の場合、端末を直接 PPPoE接続するなどして問題なく

通信ができるかどうかを確認ください。フレッツから接続確認の方法の

ご案内があった様におもいますので、併せて参照ください。

2) PPPoEセッションの接続をご確認ください。

  [show pppoe session ]で確認ください。

3) 通信状況を確認ください。

今回の作業でも実施いただいていますが、PING / HTTP / DNS など

を利用して、ルータから実施した場合、配下の端末から実施した場合

などポイントごとに、通信が『できる/できない』などを切り分けして

ください。 NAT の設定も行われておりますが、NATの設定を外した

場合の動作などもご確認ください。

例)X.X.X.Xのセグメントからは、ping ができるが、router からは

できないなどです。

4) 回線に問題が無く、NATなどの設定を外した場合においても

問題が継続する場合、PPPoE/PPP のデバッグを取得いただき、

LCPパラメータなどのネゴシエーションの状態などもご確認ください。

多くの場合は、パラメータが一致しない場合、接続できないという症状

になりますが、仮に、相手側が要求するパラメータ以外で接続が完了

してしまうような場合(MTUが一致しないまま接続のみ完了してしまった

場合)などには、通信に支障を来す恐れがありますので、一度ご確認

いただければと思います。

PPPoEの接続時の状態を確認するためのデバッグログは、以下の通りです。

こちらに関して、詳細な調査が必要であれば、 JAPAN TACまでサービス

リクエストをオープンいただければと思います。

debug ppp negothiation

  debug ppp authentication

  debug ppp packet

  debug pppoe events

  debug pppoe errors

  debug pppoe packets

  接続を確認するための show command は以下の通りです。 

  show pppoe session

  show ip interface brief

  TACにサービスリクエストをオープンする場合は、基本的な情報

  として、以下のログも取得ください。

  show tech-support

  show logging

以上、よろしくお願い致します。

「エキスパートに質問」WAN, ルーティング, スイ

申し訳ございません。ロードマップを見逃していました。

VM Mobility は、IOS15.2(2)T からサポートで、現在は Nexus でのみサポートという事で理解しました。

まずは、15.2(2)T のリリースを待ちたいと思います。

大変失礼しました。

「エキスパートに質問」WAN, ルーティング, スイ

t-yamashita様、

エキスパートへ質問へのご参加ありがとうございます。

ご質問に関してはご自身で解決されたと認識しておりますが、

エキスパートから回答ができず失礼いたしました。

担当エキスパートが今週明けから体調を崩してしまい、

対応ができませんでした。

本日から復帰いたしましたので、他のご質問などがありましたら

またぜひご参加ください。

どうぞよろしくお願いいたします。

サポートコミュニティ事務局

New Member

「エキスパートに質問」WAN, ルーティング, スイ

質問です。

EIGRPでstubネットワークを構成しているのですが、ルータで以下メッセージログが出力され、

ネイバーがリセットされていました。

・stub側ルータ

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor X.X.X.X (FastEthernet0.1) is down: peer info changed

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor X.X.X.X (FastEthernet0.1) is up: new adjacency

・対向ルータ

%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor Y.Y.Y.Y (GigabitEthernet0/0/2) is down: Interface PEER-TERMINATION received

%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor Y.Y.Y.Y (GigabitEthernet0/0/2) is up: new adjacency

どのようなときに上記ログが出力されるのでしょうか?

ご教授願います。

以上です。

「エキスパートに質問」WAN, ルーティング, スイ

Kazushi Imai様、

エキスパートへの質問をありがとうございます。

コミュニティ事務局からのお詫びなのですが、

担当エキスパートが今週明けから体調を崩してしまい、

回答が遅れています。

担当の新谷の準備が整い次第、返答いたしますので

ご了承いただけますようどうぞよろしくお願いいたします。

サポートコミュニティ事務局

Cisco Employee

「エキスパートに質問」WAN, ルーティング, スイ

お問い合わせいただきありがとうございます。

また、回答が遅くなりまして申し訳ございませんでした。

peer info changed は、stub の設定が変更された場合に発生します。

この変更は、stub コマンドのオプションの追加・削除なども該当します。

例:eigrp stub を設定していて、新たに connected オプションを追加設定した場合

--------------------------------------------------------------------------

Router(config-router)#eigrp stub connected

*Aug  5 01:48:28.459: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 100.1.1.2

(Ethernet0/0) is down: peer info changed

Router(config-router)#

*Aug  5 01:48:29.603: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 100.1.1.2

(Ethernet0/0) is up: new adjacency

--------------------------------------------------------------------------

設定が変更された場合には、それまでneighborに対して広報していた情報を

一旦リセットする必要があるため、neighbor down が発生します。

自発的な neighbor down ですので、対向機器では PEER-TERMINATION 等が

確認できます。

よろしくお願いします。

New Member

「エキスパートに質問」WAN, ルーティング, スイ

Tsuyoshi Niitani様

peer info changed ”の件、回答ありがとうございました。

回答のとおり、stubの設定変更を確認出来ました。

また、追加で質問なのですが、eigrpのネイバー状態の変更を

EEMを利用し、syslog情報をトリガにsnmp-trapを生成したいのですが、

サンプルコンフィグレーション等は御座いませんか?

宜しくお願い致します。

Cisco Employee

「エキスパートに質問」WAN, ルーティング, スイ

引き続きお問い合わせいただきありがとうございます。

CCOに合致するサンプルコンフィグレーションはありませんでしたが、

下記のような設定で、EIGRP neighbor down 時に出力される syslog を

トリガーとしてSNMP-Trap を生成することができます。

こちらの例では、EIGRP neighbor down 時のメッセージに含まれる、"is down:" の文字列をトリガーとして

"EIGRP neighbor down" という文字列を含む SNMP-trap を送信するようになっています。

(string、アドレスなどは目的に応じて追加・変更願います)

--------------------------------------------------------------------------

snmp-server enable traps event-manager

snmp-server host 172.20.1.2 version 2c test

!

event manager applet traptest

event syslog pattern "is down:"

action 1.0 snmp-trap strdata "EIGRP neighbor down"

--------------------------------------------------------------------------

(string、server アドレスなどは目的に応じて追加・変更ください)

英語版となってしまいますが、EEMについてはこちらもご参照ください。

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6815/config_guide_eem_configuration_for_cisco_integrated_services_router_platforms.html

よろしくお願いします。

Cisco Employee

「エキスパートに質問」WAN, ルーティング, スイ

お問い合わせいただきありがとうございます。

また、回答が遅くなりまして申し訳ございませんでした。

15.2(2)T につきましては、現在のところ2011年11月ごろのリリースを予定しております。

申し訳ございませんが今しばらくお待ちいただきますようお願いいたします。

よろしくお願いします。

「エキスパートに質問」WAN, ルーティング, スイ

ご回答ありがとうございます。11月まで待ちたいと思います。

大変恐縮なのですが、追加で2点、質問させてください。

1. この VM Mobility (dynamic EID)は、Cisco ルータのみで可能でしょうか。

2. VM が異なるサブネットへ移動後、通信が継続可能となる仕組みですが、以下の認識であっていますでしょうか。

① VM が G/W(ルータ)へ ARP 送信

② ルータが Proxy Arp reply により応答

③ VM のホストルートを、MS に登録

どうぞよろしくお願い致します。

「エキスパートに質問」WAN, ルーティング, スイ

t-yamashita様、

こちらの内容につきまして、サポートコミュニティ事務局より回答させていただきます。

ご質問の内容は機能の具体的な動作に関することになりますので、

リリース後のリリースノートをご確認の上、お問い合わせいただきたいと思います。

どうぞよろしくお願いいたします。

「エキスパートに質問」WAN, ルーティング, スイ

シスコサポートコミュニティ様

了解しました。

リリースを待ちますといいつつ、色々気になってしまい、大変失礼しました。

ご回答ありがとうございました。

New Member

「エキスパートに質問」WAN, ルーティング, スイ

ご質問させてください。

PPPoEでの接続についてなのですが、

通常、PPPoEは常時セッションを接続しているものだと思ってますが、

そのセッションをアイドルタイムアウトにて、切断することは可能でしょうか。

もし可能である場合、どのようなコマンドを使用したらよいのでしょうか。

尚、機器は「892Jルータ」を使用します。

お忙しいところお手数をお掛け致しますが、

ご教授の程、宜しくお願い致します。

Cisco Employee

「エキスパートに質問」WAN, ルーティング, スイ

こちらの質問に関しましては、今回の TAC エキスパートの担当外のため

専門エンジニアより回答いたします。

お問い合わせいただきましてありがとうございます。

回答が遅れました事、お詫び申し上げます。以下回答となります。

ご指摘いただいているとおり、PPPoE は 常時接続媒体である Ethernet

上で、PPP 接続を行う方式であるため、PPPoE セッションをアイドルタイム

アウトで終了することは、出来ません。

PPPoE 上で動作する PPP セッションをアイドルタイムアウトで一旦終了することは

可能です。具体的には、Dialer Interfaceにて、[ ppp timout idle ]を

指定することで対応が可能です。しかしながら、PPPoE での接続の場合は、PPPoE が

定期的に接続を開始し、この動作を制御する事ができません。そのため、 PPPのアイドル

タイマーで、PPPoE/ PPP セッションを 一時的に終了しても、PPPoEの接続開始要求を

トリガーにして再び接続状態となりますので、実施する意味がありません。

参考までに、上記でご説明いたしました、PPP のアイドルタイムアウトの設定を行った場合

の動作を確認いたしましたのでご確認ください。

1) PPPoEセッションが存在する状態から、ユーザを確認

PPPoE_Client#show users

    Line       User       Host(s)              Idle       Location

*  0 con 0                idle                 00:00:00  

  Interface    User               Mode         Idle     Peer Address

  Vi2          PPPoE_Server       PPPoE        00:00:05 192.168.1.1

2) ユーザ名を指定して詳細を確認

PPPoE_Client#show caller user PPPoE_Server

  User: PPPoE_Server, line Vi2, service PPPoE

        Connected for 00:00:15, Idle for 00:00:05

  Timeouts:    Limit     Remaining Timer Type

               -         -         -         <<<< アイドルタイムの値がありません。

  PPP: LCP Open, CHAP (->), IPCP

  Dialer: Connected to , inbound

          Type is DIALER PPPOE, group Di1

  IP: Local 192.168.1.15/32, remote 192.168.1.1

  Counts: 11 packets input, 217 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          10 packets output, 332 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

3)[ppp timout idle ]で ppp のアイドルタイムアウトを設定します。

PPPoE_Client#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

PPPoE_Client(config)#int dialer 1

PPPoE_Client(config-if)#ppp timeout idle ?

  <1-4294967>  Idle timeout value in seconds

PPPoE_Client(config-if)#ppp timeout idle 30

PPPoE_Client(config-if)#exit              

PPPoE_Client(config)#exit

PPPoE_Client#

4) 再度詳細を確認します。

PPPoE_Client#show caller user PPPoE_Server

  User: PPPoE_Server, line Vi2, service PPPoE

        Connected for 00:00:56, Idle for 00:00:15

  Timeouts:    Limit     Remaining Timer Type

               00:00:30  00:00:14  PPP idle  <<<< アイドルタイムが設定されました。

  PPP: LCP Open, CHAP (->), IPCP

  Dialer: Connected to , inbound

          Type is DIALER PPPOE, group Di1

  IP: Local 192.168.1.15/32, remote 192.168.1.1

  Counts: 19 packets input, 329 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          18 packets output, 444 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

5) 上の例では、15秒間通信の無い状態であることがわかります。

これをリセットするために、Ping を行います。

PPPoE_Client#ping 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 second

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4

6) 再度詳細を確認します。

PPPoE_Client#show caller user PPPoE_Server

  User: PPPoE_Server, line Vi2, service PPPoE

        Connected for 00:01:12, Idle for 00:00:02  <<< アイドルタイム値がリセットされ

  Timeouts:    Limit     Remaining Timer Type

               00:00:30  00:00:27  PPP idle     <<< 残り時間が増加

  PPP: LCP Open, CHAP (->), IPCP

  Dialer: Connected to , inbound

          Type is DIALER PPPOE, group Di1

  IP: Local 192.168.1.15/32, remote 192.168.1.1

  Counts: 28 packets input, 895 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          27 packets output, 1110 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

7) タイムアウトになるまで待ちます。         

PPPoE_Client#show caller user PPPoE_Server

  User: PPPoE_Server, line Vi2, service PPPoE

        Connected for 00:01:36, Idle for 00:00:25

  Timeouts:    Limit     Remaining Timer Type

               00:00:30  00:00:04  PPP idle

  PPP: LCP Open, CHAP (->), IPCP

  Dialer: Connected to , inbound

          Type is DIALER PPPOE, group Di1

  IP: Local 192.168.1.15/32, remote 192.168.1.1

  Counts: 32 packets input, 951 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          31 packets output, 1166 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

PPPoE_Client#show caller user PPPoE_Server

  User: PPPoE_Server, line Vi2, service PPPoE

        Connected for 00:01:38, Idle for 00:00:28

  Timeouts:    Limit     Remaining Timer Type

               00:00:30  00:00:01  PPP idle

  PPP: LCP Open, CHAP (->), IPCP

  Dialer: Connected to , inbound

          Type is DIALER PPPOE, group Di1

  IP: Local 192.168.1.15/32, remote 192.168.1.1

  Counts: 32 packets input, 951 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          31 packets output, 1166 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

8) PPP のアイドルタイムアウトでセッションが終了します。

*Aug 18 11:25:15.618: %DIALER-6-UNBIND: Interface Vi2 unbound from profile Di1

*Aug 18 11:25:15.622: %LINEPROTO-5-UPDOWN: Line protocol on Interfaces Virtual-Access2, changed state to down

*Aug 18 11:25:15.622: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down

9) 一旦は終了した PPPoE セッションが、再び接続状態となります。

*Aug 18 11:25:38.806: %DIALER-6-BIND: Interface Vi2 bound to profile Di1

*Aug 18 11:25:38.810: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up

*Aug 18 11:25:38.938: %LINEPROTO-5-UPDOWN: Line protocol on Interfaces Virtual-Access2, changed state to up

以上よろしくお願い致します。

New Member

Re: 「エキスパートに質問」WAN, ルーティング,

質問です。

IOSが(12.X→15.X)になってから、OSPFのStaticルート再配布時のコスト計算方式が

変更されているように思いますが、以下の認識で正しいでしょうか?

こちらで確認の認識では、以下の動きと思っています。

router ospf 1

redistribute static metric-type 1 subnet

・IOS:12.4 (Cisco1812Jにて確認)

①再配布するASBRルータにて、各Staticルートのメトリックにデフォルトメトリック(20)を足して、ネイバーに伝播。

②ネイバールータでのメトリックは、受け取ったメトリックに受信インタフェースのコストを足した値になる。

・IOS:15.0 (Cisco892Jにて確認)

①再配布するASBRルータにて、各Staticルートのメトリックにデフォルトメトリック(20)と、

Staticルータのネクストホップインタフェースのコストを足し、ネイバーに伝播。

②ネイバールータでのメトリックは、受け取ったメトリックに受信インタフェースのコストを足した値になる。

また、その他OSPFのコスト計算方式が変わった点がありましたら、

教えて頂けないでしょうか。

以上、宜しくお願い致します。

Cisco Employee

Re: 「エキスパートに質問」WAN, ルーティング,

お問い合わせありがとうございます。

お問い合わせいただいた点について確認させていただきましたが、12.4 と 15.0 で OSPF External 経路の

配布方法・メトリック計算方法に差異は確認できませんでした。

お問い合わせいただいているような、メトリック計算の差が発生する理由として考えられるものとしては、

External LSA に Forwarding Address がセットされているか否かの差が考えられます。

R1 --- (cost 10) --- R2 --- (172.20.1.0/24:cost 1) --- R3

R2 が ASBR で、R3 のアドレス(172.20.1.3)を next-hop とする次のような static route を、

提示いただいている設定により再配信しているとします。

ip route 192.168.1.1 255.255.255.255 172.20.1.3

この時、R2 が R2-R3 の 172.20.1.0/24 の link を OSPF network として広報しているかにより、

R1 でのメトリックの計算結果が変わります。

next-hop に対する network を OSPF で広報していない場合:

LSA が持つメトリックはデフォルトの 20 となります。

R2 が 作成する External LSA には Forwarding Address は set されません(0.0.0.0 となります)。

この場合、R1 で算出されるこのexternal経路に対するメトリックは、

LSA のメトリック 20 + R1 から R2 までのメトリック 10 = 30 となります。

next-hop に対する network を OSPF で広報している場合:

LSA が持つメトリックはデフォルトの 20 となります。

R2 が 作成する External LSA には Forwarding Address として172.20.1.3 がsetされます。

この場合、R1 で算出されるこのexternal経路に対するメトリックは、

LSA のメトリック 20 + Forwarding address に対する link のメトリック 1 + R1 から R2 までのメトリック 10  = 31 となります。

この計算方法については、12.4/15.0ともに同様となります。

お問い合わせいただいている状況から、おそらく、12.4 の環境では Forwarding Address がセットされておらず、

15.0の環境ではセットされていたのではないかと推測いたします。

show ip ospf database external

コマンドで、それぞれの環境で配布されている External LSA に Forwarding Address が

セットされているかどうかをご確認いただけますと幸いです。

もし、設定上 Forwarding Address がセットされるべきであるにもかかわらずセットされていない、

あるいはその逆の状況が確認できる場合には、何らかの問題が発生している可能性が考えられます。

その場合はお手数ですが、詳細な設定およびネットワーク構成の情報とともに、

TACにサービスリクエストをオープンいただきますようお願いいたします。

よろしくおねがいします。

New Member

Re: 「エキスパートに質問」WAN, ルーティング,

Niitani様

ありがとうございます。

改めてやってみましたが、

共に、ForwordingAddressはSetされていました。

NetHopが広報されているいないで、

コスト計算が異なることは分かりました。

R1 --- (cost 10) --- R2(cost:1)--- (172.20.1.0/24) ---(cost:5) R3

             |

          R4

R3 が ASBR で、同セグメントR4 のアドレス(172.20.1.254)を next-hop とする

次のような static route を、OSPFによって再配信しているとします。

ip route 192.168.1.1 255.255.255.255 172.20.1.254

※R1,R2,R3は接続インタフェースをOSPFのNetworkとして指定する。

この場合のLSAのメトリックは、

20(default)  +  R3のForwarding address に対する link のメトリック 5  +  R2 (R3 向け)のメトリック 1  =26に

なるのでしょうか?

以上、宜しくお願いします。

Re: 「エキスパートに質問」WAN, ルーティング,

masse0102様、

エキスパートに質問へのご参加をありがとうございました。

今回の期間は8/14までとなっておりますので、

追加のご質問は通常のWANコミュニティへ投稿いただき

広く回答を募集いただきたいと思います。

どうぞよろしくお願いいたします。

サポートコミュニティ事務局

10842
閲覧回数
93
いいね!
23
返信
作成コンテンツを作成するには してください