2007年1月26日 (金)

RouterにHTTPアクセスする

今日、JuniperのSSGにHTTPアクセスして設定などしていたのだが、ふと、シスコでも設定見るくらいはHTTPでできるよなぁ、、なんて思い出した。こんなこと普通はしないと思うが。

ip http server
ip http access-class 10
!
access-list 10 permit 192.168.1.0 0.0.0.255

上記の設定で、仮に192.168.1.0/24にPCを設置し、HTTPでRouterにアクセスすると認証を求められ

username: => 特に何も認証を設定していない場合は何の文字列でもOK
password: => 特に何も認証を設定していない場合はenable password

でHTTPアクセスできる。何でusernameが何でも良いのか、それが仕様なのかよくわからない。とにかくそのように動作する。

なお、Localで認証をかけたい場合は下記のようになる。

ip http authentication local

但し明示的に特権レベル15を指定しておかないとうまくいかない。

username http privilege 15 password 0 cisco

AAAで認証したい場合は下記であるが、privilege 15 をauthorizationできるユーザでないと認証できない。

ip http authentication aaa

| | コメント (5) | トラックバック (0)

2006年12月26日 (火)

bgp redistribute-internal

こんなことを実際に必要とするのかどうかは別として、知ってないとどうにもならないコマンドがある。実際に案件で使用したことがあるので、全く不必要ということはなく、たまには必要ということだろう。

bgp redistribute-internal
IBGPをIGPに再配信する場合に、Defaultでは配信されないので上記のコマンドが必要となる。

=====================================
router ospf 300
  redistribute bgp 200
!
router bgp 200
  bgp redistribute-internal
=====================================

みたいな感じで使用する。このコマンドが無いといつまでたってもIGP(上記の場合はospf)に乗ってくることはない。しかも、上記のコマンドを投入しても、clear ip bgp * をしないと反映されないという敷居の高いコマンドである。シスコ(CCO)曰く

「IBGPの経路情報をIGPに再配信する場合にはルーティングループを引き起こしやすいので注意して使うこと」

と記述がある。全くその通りである。

ちょっと調べ物をしていて、ふとこのコマンドに行き着いたので書いてみました。
基本的にこんなことはガレ兵ブログには期待されてないんでアクセス数が減るだろうな。。

| | コメント (6) | トラックバック (0)

2005年10月16日 (日)

ITおやじからの苦言 その2

以前、ITおやじからの苦言というネタを書いた。Helper を例にして書いたと記憶している。
最近、CCO を読んでいてあることを思い出したので、また苦言を呈させてもらおう。
(こんな偉そうな書き方して、嫌われるな。。)

ACL の fragments キーワードを知っているだろうか。
いや、ほとんどの人は知っていると答えるだろう。
フラグメントアタックを防ぐような場合に使うものであると理解しているだろう。

本当に理解していますか?
そもそもフラグメントパケットってどのように認識されるか知ってますか?

動作を理解して使ってますか。
単に「fragments 打てばいいんでしょ」程度で理解したつもりになってないだろうか。

なお、私も検証ベースで理解したつもりでいるが間違いがあれば是非指摘して欲しいと思っている。

あるパケットが、例えば MTU の問題等で Router でフラグメント化されたような場合を考えてみよう。というか、そうやってフラグメントパケットを作るのが簡単だろうと思う。

まず、フラグメント化される場合、下記にようになるはずである。

1パケット目   :FO=0 MFビット=1
2パケット目以降 :FO>0 MFビット=0

ここで、1パケット目は防げないはずである。というのは「普通のパケット」だから。これを防ごうというのはACLで普通に deny しないといけないので、他の通常トラフィックに影響が出るはずだ。

access-list 199 deny   ip any host 192.168.1.1 log fragments  =>(a)
access-list 199 permit tcp any host 192.168.1.1 eq www log  =>(b)
access-list 199 deny   ip any any log

上記のACLを書くと、1パケット目は (b) の行に match する。そして2パケット目以降は (a) の行に match する。つまり1パケット目は permit されるのである。だから、「FO>0 MFビット=0」だけを送ってくるようなアタックの場合には一切を通さずに防げるのかもしれないが、「結果的にフラグメント化されるパケット」の場合、1パケット目は通るが、それ以降は通らない、という動作をする。

結果としてパケットの再組み立てが行われずに通信としては成り立たない。

Router#sh access-lists 199
Extended IP access list 199
    deny ip any host 150.100.1.241 log fragments (2 matches)
    permit tcp any host 150.100.1.241 eq www log (1 match)
    deny ip any any log (315 matches)

ちなみに、ちょっと予想外の動作なのであるが、もし

access-list 199 permit tcp any any eq bgp log =>(c)
access-list 199 deny   ip any host 192.168.1.1 log fragments
access-list 199 permit tcp any host 192.168.1.1 eq www log
access-list 199 deny   ip any any log

みたいに、他のトラフィックを明示的に通したいと思って、上記の例では (c) で bgp を permit する行を書いている。すると、全てのフラグメントパケットはこの ACL を通過してしまう。

なぜかというと、フラグメントされたパケット(2パケット目以降)には Layer4 の情報を持っていないのである。Sniffer 等で拾ってみると「IP Continuation of frame」と見え、1パケット目の続きであるという認識であることがわかる。

この場合、何と (c) の行で match する、すなわち通過するのである。

だから結果として防げていない。
だから (c) のような tcp の permit 文は下の方に書かねばならない。

私も完璧に理解できているわけでもなく、どなたかスペシャリストの方が間違いを発見できたら指摘して欲しいのであるが、ここで言いたいのは、これくらいを自分でやってないと、とても「理解」には程遠いのではないか、という、ITおやじから苦言を呈させてもらいたいと思った次第である。

偉そうな書き方ですいません。。。

| | コメント (2) | トラックバック (0)

2005年9月22日 (木)

結論「Inter-ASでのマルチキャスト」

延々と検証を続けて参りましたが、一定の結論が出ましたのでここに報告します。ガレージ兵頭では技術的なことをほとんど書かないことをポリシーとして運営してきましたが、これだけは書いておこうと思いました。ただ、期待をしている方々もいるかもしれませんが、この内容が直接試験に出たりしませんので、そういうことはご自分で試験を受けて、解析して、を繰り返して頑張ってみて下さい。

検証構成は下記とします。
<R1>.1 ---192.168.2.0/24--- .3<R3>.3 ---192.168.4.024--- .4<R4>

loopbackは
R1  1.1.1.1/32
R3  3.3.3.3/32
R4  4.4.4.4/32

Multicast SourceはR1に接続され、アドレスは192.10.10.1/24
Multicast group addressは225.1.1.100
recieverはR4のloopback 0
ここに、”ip igmp join-group 225.1.1.100”を設定しています。

-------------------------初期config----------------------------
<R1>
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip pim sparse-mode
!
interface GigabitEthernet0/1
ip address 192.168.2.1 255.255.255.0
ip pim sparse-mode
!
interface GigabitEthernet0/2
ip address 192.10.10.9 255.255.255.0
ip pim sparse-mode
!
router bgp 1
bgp router-id 1.1.1.1
neighbor 192.168.2.3 remote-as 3
!
ip pim rp-address 1.1.1.1

<R3>
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip pim sparse-mode
!
interface FastEthernet1/1
ip address 192.168.2.3 255.255.255.0
ip pim sparse-mode
!
interface GigabitEthernet5/1
ip address 192.168.4.3 255.255.255.0
ip pim sparse-mode
!
router ospf 1
router-id 3.3.3.3
network 3.3.3.3 0.0.0.0 area 0
network 192.168.4.0 0.0.0.255 area 0
!
router bgp 3
bgp router-id 3.3.3.3
neighbor 4.4.4.4 remote-as 3
neighbor 4.4.4.4 update-source Loopback0
neighbor 192.168.2.1 remote-as 1
!
address-family ipv4
neighbor 4.4.4.4 activate
no auto-summary
no synchronization
exit-address-family
!
ip pim rp-address 3.3.3.3

<R4>
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip pim sparse-mode
ip igmp join-group 225.1.1.100
!
interface GigabitEthernet0/0
ip address 192.168.4.4 255.255.255.0
ip pim sparse-mode
!
router ospf 1
router-id 4.4.4.4
network 4.4.4.4 0.0.0.0 area 0
network 192.168.4.0 0.0.0.255 area 0
!
router bgp 3
bgp router-id 4.4.4.4
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 update-source Loopback0
!
address-family ipv4
neighbor 3.3.3.3 activate
no auto-summary
no synchronization
exit-address-family
!
ip pim rp-address 3.3.3.3
-------------------------初期config----------------------------

この状態でR1では192.10.10.1から225.1.1.100宛てを受け取ってます。

R1#sh ip mroute 225.1.1.100

(*, 225.1.1.100), 4d22h/stopped, RP 1.1.1.1, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(192.10.10.1, 225.1.1.100), 4d22h/00:02:55, flags: PTA
  Incoming interface: GigabitEthernet0/2, RPF nbr 0.0.0.0
  Outgoing interface list: Null

R4では、(*,G)に対するエントリが出来ています。
( ip igmp join-group 225.1.1.100)

R4#sh ip mroute

(*, 225.1.1.100), 00:26:22/00:02:50, RP 3.3.3.3, flags: SJCL
  Incoming interface: GigabitEthernet0/0, RPF nbr 192.168.4.3
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:26:22/00:02:50

R3でも(*,G)に対するエントリは出来ています。

R3#sh ip mroute

(*, 225.1.1.100), 00:01:04/00:03:24, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet5/1, Forward/Sparse, 00:01:04/00:03:24

しかし、この(*,G)はこのルータで止まってます。
ここで、R1、R3にMSDPの設定を行います。

<R1>
ip msdp peer 192.168.2.3 connect-source GigabitEthernet0/1

<R3>
ip msdp peer 192.168.2.1 connect-source FastEthernet1/1
 
これでR3でR1の持っている情報を受け取ることが出来ます。

R3#sh ip msdp sa-cache 225.1.1.100
MSDP Source-Active Cache - 1 entries for 225.1.1.100
(192.10.10.1, 225.1.1.100), RP 1.1.1.1, BGP/AS 0, 00:00:13/00:05:46, Peer 192.168.2.1

ここでR4で見てみます。

R4#sh ip mroute

(*, 225.1.1.100), 00:31:14/00:02:56, RP 3.3.3.3, flags: SJCL
  Incoming interface: GigabitEthernet0/0, RPF nbr 192.168.4.3
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:31:14/00:02:56

です。” flags: SJCL”になってます。これは、
S - Sparse
J - Join SPT
C - Connected
L - Local

つまり、シェアードツリーからSPTへ移行しようとしています。
この時点で、(*,G)に関してはAS間通信が出来ている事になります。
ただし、R4で見ると、

R4#sh ip mroute

(*, 225.1.1.100), 00:08:13/00:03:12, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet5/1, Forward/Sparse, 00:08:13/00:03:12

です。”flags: S”です。つまり、SPTへ移行しようとしていません。
これはなぜかというと、R4が192.10.10.1のルート情報を持っていないからです。
ここで各ルータに以下の設定を入れます。

<R1>
router bgp 1
!
address-family ipv4 multicast
neighbor 192.168.2.3 activate
no auto-summary
no synchronization
network 192.10.10.0
exit-address-family

<R3>
router bgp 3
!
address-family ipv4 multicast
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 next-hop-self
neighbor 192.168.2.1 activate
no auto-summary
exit-address-family

<R4>
router bgp 3
!
address-family ipv4 multicast
neighbor 3.3.3.3 activate
no auto-summary
no synchronization
exit-address-family

とすると、BGP経由でSource情報を得られるのでDataがSPTで流れ始めます。

R4#sh ip bgp ipv4 multicast
BGP table version is 2, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i192.10.10.0      3.3.3.3                  0    100      0 1 i

R4#sh ip mroute

(*, 225.1.1.100), 01:07:52/stopped, RP 3.3.3.3, flags: SJCL
  Incoming interface: GigabitEthernet0/0, RPF nbr 192.168.4.3
  Outgoing interface list:
    Loopback0, Forward/Sparse, 01:07:52/00:02:24

(192.10.10.1, 225.1.1.100), 00:03:49/00:02:59, flags: LJT
  Incoming interface: GigabitEthernet0/0, RPF nbr 192.168.4.3, Mbgp
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:03:49/00:02:24

R4#sh ip mroute active
Active IP Multicast Sources - sending >= 4 kbps

Group: 225.1.1.100, (?)
   Source: 192.10.10.1 (?)
     Rate: 34 pps/341 kbps(1sec), 341 kbps(last 0 secs), 379 kbps(life avg)

以上、分かりにくいかもしれませんが、いろいろなエッセンスを盛り込んだ内容としたつもりでございます。今日の夜には構成を壊しますので、これにてこの検証は終了です。

| | コメント (0) | トラックバック (0)

2005年8月14日 (日)

local-asとremote-as

router bgp 100
neighbor 192.168.1.1 remote-as 200

を動作している状態で、同じAS番号をlocas-asでは設定できない

R6(config-router)#neighbor 192.168.1.1 local-as 200
% Cannot have local-as same as remote-as number

少なくとも2600や3600では設定できないが、7301では設定できる。なぜ、できる/できないがプラットフォームで分かれるのか、それがわからない。

| | コメント (0) | トラックバック (0)

2005年8月11日 (木)

PIXのOSPF

すいません。
何ということはない、PIXでの普通のOSPFです。
F/WでOSPFなんて動かすか? なんて議論はさておいて、一応動きます。昔、DynamicRoutingでF/Wを切り替えろ、という要件があって困ったことを思い出しました。その時は6.3じゃなかったから。その案件、結果的に負けました。
PIX6.3のことをnetworkerさんが書いていたので、懐かしくて、自分でその後に勉強した際のログを探しました。あまりに普通の構成ですいません。

area 10(Loopback)
|
R1
200.1.1.254
|
| area 0
|
200.1.1.1(Outside)
PIX
192.168.1.1(Inside)
|
| area 5
|
192.168.1.254
R2

R1#
interface Loopback0
ip address 210.1.1.254 255.255.255.0
!
interface Ethernet0
ip address 200.1.1.254 255.255.255.0
!
router ospf 100
network 200.1.1.0 0.0.0.255 area 0
network 210.1.1.0 0.0.0.255 area 10

R2#
interface Loopback0
ip address 192.168.100.254 255.255.255.0
!
interface Ethernet0
ip address 192.168.1.254 255.255.255.0
!
router ospf 100
network 192.168.1.0 0.0.0.255 area 5
!

pixfirewall#
ip address outside 200.1.1.1 255.255.255.0
ip address inside 192.168.1.1 255.255.255.0
router ospf 100
  network 192.168.1.0 255.255.255.0 area 5
  network 200.1.1.0 255.255.255.0 area 0

R1#sh ip route
C    200.1.1.0/24 is directly connected, Ethernet0
O IA 192.168.1.0/24 [110/20] via 200.1.1.1, 00:01:04, Ethernet0
C    210.1.1.0/24 is directly connected, Loopback0

R2#sh ip route
O IA 200.1.1.0/24 [110/20] via 192.168.1.1, 00:01:52, Ethernet0
C    192.168.1.0/24 is directly connected, Ethernet0
     210.1.1.0/32 is subnetted, 1 subnets
O IA    210.1.1.254 [110/21] via 192.168.1.1, 00:01:53, Ethernet0
C    192.168.100.0/24 is directly connected, Loopback0

| | コメント (0) | トラックバック (0)

2005年7月17日 (日)

OSPFでの認証設定

OSPFでの認証設定ですが、書き方が大きく二種類あると思います。
どう呼んだらいいのかわかりませんが、「古い書き方」「新しい書き方」と書くことにします。

古い書き方の場合は、
・router ospf xx の配下
・interface の配下
の両方に一行ずつ設定をしなければならなかったと思います。

新しい書き方の場合は、interfaceの配下にのみ二行を設定すれば済みます。
とても楽なのでこちらの方をお勧めします。

interface Serial0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 cisco

という感じ(md5の場合)で、お互いの対抗のinterfaceに設定を書けばいいのでわかりやすく混乱することがありません。

古い書き方の場合は、virtual-linkがあると理解に苦しみましたが

http://www.cisco.com/warp/public/104/27.html

新しい書き方では

router ospf 100
area 5 virtual-link 1.1.1.1 authentication message-digest
area 5 virtual-link 1.1.1.1 message-digest-key 1 md5 cisco

という感じで、両側に書けばいいのでとてもわかりやすいと思うのですが。
ずっと古い書き方でやってきたので切り替えには勇気が必要でしたが、とても楽になりました。

皆さんはどちらを使用してますでしょうか。

| | コメント (2) | トラックバック (0)

2005年7月16日 (土)

RIPにおけるスタティックの再配信

ちょっと変なことを考えてみた。

Lo0--R1(192.168.1.1)-----------(192.168.1.2)R2--Lo0

上記の構成でRIPを動作させる。
ここで、下記のstaticを設定し、RIPに再配信する。

<R1>
interface Loopback0
ip address 200.1.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
!
router rip
network 192.168.1.0
network 200.1.1.0

<R2>
interface Loopback0
ip address 200.2.2.2 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.0
!
router rip
network 192.168.1.0
network 200.2.2.0

もちろんRoutingTableは下記となる。

R1#sh ip route
C    200.1.1.0/24 is directly connected, Loopback0
R    200.2.2.0/24 [120/1] via 192.168.1.2, 00:00:21, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0

R2#sh ip route
R    200.1.1.0/24 [120/1] via 192.168.1.1, 00:00:07, FastEthernet0/0
C    200.2.2.0/24 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, FastEthernet0/0」

ここで、下記のスタティックルートを設定し、RIPに再配信する。

ip route 100.1.1.0 255.255.255.0 192.168.1.2
!
router rip
redistribute static

要するにどこかへのスタティックルートを対抗のインタフェース向けにして、
それをRIPに再配信するのだが、これをR1は広報するだろうか。

R1#debug ip rip
RIP protocol debugging is on
R1#
*Mar  1 00:41:11.307: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (192.168.1.1)
*Mar  1 00:41:11.307: RIP: build update entries
*Mar  1 00:41:11.307:   network 200.1.1.0 metric 1

広報しなかった。
これは何のルールに引っかかって広報しないのだろうか。
だってイーサネットなんだから、192.168.1.0/24に第三のルータがいればそれ向けに広報しないの?
スプリットホライズンでもないし、広報しないというルールがわかんないです。

まぁ、何となく広報しそうにはないんだけど、どういう実装なのかそれがわからない。
R1が広報した結果、R2がRoutingTableに載せないというのであればそれは納得できるのだけど。

| | コメント (9) | トラックバック (0)

2005年7月12日 (火)

ITおやじからの苦言

例えばの例である。AutoInstallという機能をご存知だろうか。単にCCOで紹介されているFeatureのことである。別に大した機能ではなく、普通にCCOに記述がある。私は受講したことがないのだが、CCIE対策を銘打っているセミナーでも紹介されるらしい。新規ルータが接続される先の既存ルータは下記configみたいになると思う。私はIOS11.3の頃(多分)に検証した。
helper-addressを書くというテクニックで語られる。

interface Serial0/1
ip address 192.168.1.1 255.255.255.0
ip helper-address 200.200.200.1
encapsulation frame-relay
frame-relay map ip 192.168.1.2 300 broadcast
frame-relay lmi-type ansi

新規routerはまずIPアドレスを取得しようとする。Framerelayインタフェースの場合、まず最初にHDLCで接続しようとして失敗し、次にencap framerelayで接続する。ここで、対向のインタフェースのframerelay mapから自分のインタフェースのIPアドレスを取得する。encap HDLC の場合は、192.168.1.1の様に末尾のアドレスを1にしておくと新しいrouterのIPアドレスは92.168.1.2となる。次にTFTPでnetwork-confgファイルから自分のhostnameを解決しようとする・・・
ここらで止めておこう。

設定そのものを紹介しようとしているわけではない。皆さんもほとんどの方が「そんなの知ってる。helperでしょ。」と言うだろう。
本当ですか?
本当に動作を知ってますか?
実はCCOの通りに動作しない個所があることをご存知ですか?
現在のCCOでは知らないが11.3の頃は明らかに記述に間違いがあった。私は丸2日かかってその間違いを発見した。苦労したから誰にも教えない(笑)

実際にTFTPサーバを立てて、network-confgファイルとconfigファイルを準備してこのAutoInstallを実際に動作させたことのある方は何%いるだろうか。この精度で検証をしない人は合格できない。神になるために試練を、単にconfigのテクニックだけで超えれるはずはない。

もし、(例えば、であるが)これにNATなどが絡んだネットワークだったら?
単なるテクニックでしかこのFeatureを知らない人には、こういうところを越えられない。

というITおやじからの苦言である。私には頭の冴えがないので地道にやっていかないと若い連中には勝てない。それが羨ましいだけか。また、勉強勉強。。

| | コメント (2) | トラックバック (0)

PIXを経由するBGP認証

意味の無い設定シリーズ。読み飛ばして下さい。

R1-----(inside)PIX(outside)-----R2

上記の構成で、R1とR2はBGPのPeerに認証を設定できるであろうか。
答えは「できる」である。
但し、簡単にはできない。構成上の制約もある。PIXでNATすると認証に失敗する。
R1のPIX側のアドレスを1.1.1.1とすると

static (inside,outside) 1.1.1.1 1.1.1.1.1 norandomseq

のようにしなければならない。NATしてしまうとBad-Authenticationというエラーを吐く。(PIXは6.2を使用してます)

| | コメント (2) | トラックバック (0)

より以前の記事一覧