{"id":1323,"date":"2009-03-12T08:24:19","date_gmt":"2009-03-12T07:24:19","guid":{"rendered":"http:\/\/security-planet.de\/?p=1323"},"modified":"2009-03-12T08:24:19","modified_gmt":"2009-03-12T07:24:19","slug":"remote-rip-routing","status":"publish","type":"post","link":"https:\/\/cyber-fi.net\/index.php\/2009\/03\/12\/remote-rip-routing\/","title":{"rendered":"Remote RIP-Routing"},"content":{"rendered":"

IGPs werden normalerweise dazu verwendet, um direkt angeschlossenen Nachbarn Routing-Informationen zu senden. Aber was ist, wenn man einem entfernten Router ein Update senden m\u00f6chte:<\/p>\n\n\n
\"remote-rip\"<\/p>\n<\/td>\n<\/tr>\n<\/table>\n

Kann R3 ein RIP-Update an R1 senden wenn R2 kein RIP spricht? Tunnel etc. sind nat\u00fcrlich nicht erlaubt. Ja, es geht. Z.B., indem R3 diesen Traffic direkt per Unicast versendet.
\nDie Konfiguration von R1 startet mit einer IP auf dem Interface und dem Aktivieren von RIP:<\/p>\n

interface FastEthernet0\/0\n ip address 10.10.1.1 255.255.255.0\n!\nrouter rip\n version 2\n passive-interface default\n network 10.0.0.0\n no auto-summary<\/code><\/pre>\n
Auf R2 werden nur die Interfaces konfiguriert, kein RIP:<\/p>\n
interface FastEthernet0\/0\n ip address 10.10.1.2 255.255.255.0\n!\ninterface FastEthernet0\/1\n ip address 10.10.2.2 255.255.255.0<\/code><\/pre>\n
Router R3 spricht RIP, benutzt R1 als Neighbor und sendet daher diesem seine Updates als Unicast. Alle Interfaces werden passiv gesetzt (auch auf R1), per Multicast sollen keine Nachbarn mehr erreicht werden. Weiterhin ben\u00f6tigt R3 eine Route, um R1 zu erreichen:<\/p>\n
interface Loopback0\n ip address 1.1.1.1 255.255.255.255\n!\ninterface FastEthernet0\/1\n ip address 10.10.2.3 255.255.255.0\n!         \nrouter rip\n version 2\n passive-interface default\n network 1.0.0.0\n network 10.0.0.0\n neighbor 10.10.1.1\n no auto-summary\n!\nip route 0.0.0.0 0.0.0.0 10.10.2.2<\/code><\/pre>\n
Mit dieser Konfig f\u00e4ngt R3 an, seine Updates zu senden:<\/p>\n
*Mar  1 00:12:26.291: RIP: sending v2 update to 10.10.1.1 via FastEthernet0\/1 (10.10.2.3)\n*Mar  1 00:12:26.291: RIP: build update entries\n*Mar  1 00:12:26.291:   1.1.1.1\/32 via 0.0.0.0, metric 1, tag 0\n<\/code><\/pre>\n
Diese Updates kommen auch bei R1 an, werden dort aber aufgrund der ung\u00fcltigen Source-Adresse verworfen:<\/p>\n
*Mar  1 00:44:50.767: RIP: ignored v2 update from bad source 10.10.2.3 on FastEthernet0\/0<\/code><\/pre>\n
Wenn in der RIP-Konfiguration die Validierung der Source-Adresse abgeschaltet wird, kann die Route von R3 problemlos gelernt werden:<\/p>\n
router rip\n version 2\n passive-interface default\n no validate-update-source\n network 10.0.0.0\n no auto-summary<\/code><\/pre>\n
Router#sh ip route rip\n     1.0.0.0\/32 is subnetted, 1 subnets\nR       1.1.1.1 [120\/1] via 10.10.2.3, 00:00:21\n<\/code><\/pre>\n
Wird das f\u00fcr irgendetwas ben\u00f6tigt? Vermutlich nicht, aber interessant ist dieses Verhalten trotzdem … \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"
IGPs werden normalerweise dazu verwendet, um direkt angeschlossenen Nachbarn Routing-Informationen zu senden. Aber was ist, wenn man einem entfernten Router ein Update senden m\u00f6chte: Kann R3 ein RIP-Update an R1 senden wenn R2 kein RIP spricht? Tunnel etc. sind nat\u00fcrlich nicht erlaubt. Ja, es geht. Z.B., indem R3 diesen Traffic direkt per Unicast versendet. Die <\/p>\n
continue reading<\/a><\/div>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"twitterCardType":"","cardImageID":0,"cardImage":"","cardTitle":"","cardDesc":"","cardImageAlt":"","cardPlayer":"","cardPlayerWidth":0,"cardPlayerHeight":0,"cardPlayerStream":"","cardPlayerCodec":"","footnotes":""},"categories":[5],"tags":[307,358,512],"class_list":["post-1323","post","type-post","status-publish","format-standard","hentry","category-cisco","tag-ios","tag-konfiguration","tag-rip"],"_links":{"self":[{"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/posts\/1323","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/comments?post=1323"}],"version-history":[{"count":0,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/posts\/1323\/revisions"}],"wp:attachment":[{"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/media?parent=1323"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/categories?post=1323"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/tags?post=1323"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}