CCIE.pl

site 4 CCIE wannabies
Dzisiaj jest 23 lut 2018, 21:10

Strefa czasowa UTC+01:00




Nowy temat  Odpowiedz w temacie  [ Posty: 7 ] 
Autor Wiadomość
Post #1 : 18 gru 2017, 12:09 
Offline
wannabe
wannabe
Awatar użytkownika

Rejestracja: 20 cze 2007, 08:53
Posty: 136
Czesc,
chce zestawic sesje bgp pomiedzy ASAv (asa991-smp-k8.bin) a ISR 4451x (isr4400-universalk9.03.16.06b.S.155-3.S6b-ext.SPA.bin). Po stronie rutera BGP ma dzialac na domyslnym vrf Mgmt-intf. Pomiedzy ASAv i ruterem jest switch L3 i firewall fortigate, czyli 2 hopki.

Teraz problem, sesja bgp nie zestawia sie bo nie nawiazauje sie polacznie TCP 3way handshake. Z tego co zdebugowalem problem jest z ruterem. Moge zrobic telnet z rutera na port ASA ssh - 22 lub 443 ale na 179 nie, ASA odsyla SYN ACK na probe polaczenia z rutera i nic sie nie dzieje, dostaje tylko ponowienia retransmisji z rutera. Dodatkowo na ASAv przekonfigurowalem http tak, aby serwis sluchal na porcie 179, z innych hostow moge sie polaczyc do takiej uslugi a rutera juz nie. Taka sama sytuacja jest gdy skonfiguruje BGP na ruterze i ASA prawidlowo, czyli address-family ipv4 + ebgp-multihop.

Czy to normalne zachowanie, ze moge polaczyc sie na 22 i 443 z rutera do ASA ale na 179 juz nie, gdy polaczenie wychodzi z vrf Mgmt-intf?


Na górę
Post #2 : 18 gru 2017, 13:11 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3895
Ustawiłeś source-interface na interfejs należący do VRFu po stronie routera?

Co do telnetów/etc - pamiętaj, że po stronie routera możesz ustawić source VRF dla połączeń wychodzących, natomiast kontrola połączeń przychodzących do niego, w tym źródłowego VRFu odbywa się na poziomie danej tablicy routingu i ew. access-class linii VTY/usługi HTTP.


Na górę
Post #3 : 18 gru 2017, 13:54 
Offline
wannabe
wannabe
Awatar użytkownika

Rejestracja: 20 cze 2007, 08:53
Posty: 136
Cytuj:
Ustawiłeś source-interface na interfejs należący do VRFu po stronie routera?

Co do telnetów/etc - pamiętaj, że po stronie routera możesz ustawić source VRF dla połączeń wychodzących, natomiast kontrola połączeń przychodzących do niego, w tym źródłowego VRFu odbywa się na poziomie danej tablicy routingu i ew. access-class linii VTY/usługi HTTP.
Wydaje mi sie ze ustawilem wszystko dobrze, 10.80.11.20 - ASA, 10.80.10.13 - rotuer, ponizej config z rutera:
Kod:
NPPLR1700101#sh run | sec line vty
line vty 0 4
 session-timeout 30
 access-class ACL_VTY in vrf-also
 exec-timeout 30 0
 logging synchronous
 transport input all
 transport output all
NPPLR1700101#sho access-lists ACL_VTY
Standard IP access list ACL_VTY
    5 permit 10.80.11.20 log
    10 permit 10.xx.xx.xx (26 matches)
    20 permit 10.xx.xx.xx (1883 matches)
    30 deny   any log (5 matches)

NPPLR1700101#sh vrf
  Name                             Default RD            Protocols   Interfaces
  Mgmt-intf                        888:888               ipv4,ipv6   Gi0
  
NPPLR1700101#sho ip route vrf Mgmt-intf 10.80.11.20

Routing Table: Mgmt-intf
Routing entry for 10.80.11.20/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.80.10.1
      Route metric is 0, traffic share count is 1

NPPLR1700101#telnet 10.80.11.20 22 /vrf Mgmt-intf /source-interface gigabitEthernet 0
Trying 10.80.11.20, 22 ... Open
SSH-2.0-Cisco-1.25
                  ^]
[Connection to 10.80.11.20 closed by foreign host]
NPPLR1700101#telnet 10.80.11.20 179 /vrf Mgmt-intf /source-interface gigabitEthernet 0
Trying 10.80.11.20, 179 ...
% Connection timed out; remote host not responding

Ponizej konfig z ASA:
Kod:
NPPLF1700109# sh run http
http server enable 179
http 10.80.10.13 255.255.255.255 FEEDER
NPPLF1700109# sh run ssh
ssh 10.80.10.13 255.255.255.255 FEEDER
NPPLF1700109# sho asp table socket
Protocol   Socket    State      Local Address                                Foreign Address
TCP        0002a4f8  LISTEN     10.80.11.20:22                               0.0.0.0:*
TCP        00cbe628  ESTAB      10.80.11.20:22                               10.xx.xx.xx:29893
SSL        00ce7398  LISTEN     10.80.11.20:179                              0.0.0.0:*
Zrzut ruchu z interfejsu ASA, ten sam ruch lapie na FW do ktorego podlaczony jest interfejs rutera 10.80.10.13:
Kod:
NPPLF1700109# sho cap cap

20 packets captured

   1: 12:49:24.765051       10.80.10.13.34146 > 10.80.11.20.22: S 2876853627:2876853627(0) win 4128 <mss 536>
   2: 12:49:24.765158       10.80.11.20.22 > 10.80.10.13.34146: S 2252837786:2252837786(0) ack 2876853628 win 8192 <mss 1380>
   3: 12:49:24.765905       10.80.10.13.34146 > 10.80.11.20.22: . ack 2252837787 win 4128
   4: 12:49:24.766333       10.80.10.13.34146 > 10.80.11.20.22: . ack 2252837787 win 4128
   5: 12:49:24.767599       10.80.11.20.22 > 10.80.10.13.34146: P 2252837787:2252837806(19) ack 2876853628 win 32768
   6: 12:49:24.968120       10.80.10.13.34146 > 10.80.11.20.22: . ack 2252837806 win 4109
   7: 12:49:27.176733       10.80.10.13.34146 > 10.80.11.20.22: P 2876853628:2876853629(1) ack 2252837806 win 4109
   8: 12:49:27.176809       10.80.11.20.22 > 10.80.10.13.34146: . ack 2876853629 win 32768
   9: 12:49:27.176931       10.80.11.20.22 > 10.80.10.13.34146: FP 2252837806:2252837806(0) ack 2876853629 win 32768
  10: 12:49:27.177297       10.80.10.13.34146 > 10.80.11.20.22: . ack 2252837807 win 4109
  11: 12:49:27.177618       10.80.10.13.34146 > 10.80.11.20.22: FP 2876853629:2876853629(0) ack 2252837807 win 4109
  12: 12:49:27.177664       10.80.11.20.22 > 10.80.10.13.34146: . ack 2876853630 win 32768
  13: 12:49:35.786351       10.80.10.13.63842 > 10.80.11.20.179: S 2371287220:2371287220(0) win 4128 <mss 536>
  14: 12:49:35.786595       10.80.11.20.179 > 10.80.10.13.63842: S 1627040581:1627040581(0) ack 2371287221 win 32768 <mss 536>
  15: 12:49:37.787053       10.80.10.13.63842 > 10.80.11.20.179: S 2371287220:2371287220(0) win 4128 <mss 536>
  16: 12:49:37.817981       10.80.11.20.179 > 10.80.10.13.63842: S 1627040581:1627040581(0) ack 2371287221 win 32768 <mss 536>
  17: 12:49:41.786366       10.80.10.13.63842 > 10.80.11.20.179: S 2371287220:2371287220(0) win 4128 <mss 536>
  18: 12:49:41.848237       10.80.11.20.179 > 10.80.10.13.63842: S 1627040581:1627040581(0) ack 2371287221 win 32768 <mss 536>
  19: 12:49:49.786244       10.80.10.13.63842 > 10.80.11.20.179: S 2371287220:2371287220(0) win 4128 <mss 536>
  20: 12:49:49.880203       10.80.11.20.179 > 10.80.10.13.63842: S 1627040581:1627040581(0) ack 2371287221 win 32768 <mss 536>
20 packets shown
Z innego hosta, który nie jest ruterem, jak najbardziej moge sie polaczyc na interfejs ASA port 179 10.80.11.20.


Na górę
Post #4 : 23 gru 2017, 11:28 
Offline
wannabe
wannabe
Awatar użytkownika

Rejestracja: 09 maja 2006, 14:28
Posty: 278
Lokalizacja: Warszawa
Cytuj:
Czesc,
chce zestawic sesje bgp pomiedzy ASAv (asa991-smp-k8.bin) a ISR 4451x (isr4400-universalk9.03.16.06b.S.155-3.S6b-ext.SPA.bin). Po stronie rutera BGP ma dzialac na domyslnym vrf Mgmt-intf. Pomiedzy ASAv i ruterem jest switch L3 i firewall fortigate, czyli 2 hopki.

Teraz problem, sesja bgp nie zestawia sie bo nie nawiazauje sie polacznie TCP 3way handshake. Z tego co zdebugowalem problem jest z ruterem. Moge zrobic telnet z rutera na port ASA ssh - 22 lub 443 ale na 179 nie, ASA odsyla SYN ACK na probe polaczenia z rutera i nic sie nie dzieje, dostaje tylko ponowienia retransmisji z rutera. Dodatkowo na ASAv przekonfigurowalem http tak, aby serwis sluchal na porcie 179, z innych hostow moge sie polaczyc do takiej uslugi a rutera juz nie. Taka sama sytuacja jest gdy skonfiguruje BGP na ruterze i ASA prawidlowo, czyli address-family ipv4 + ebgp-multihop.

Czy to normalne zachowanie, ze moge polaczyc sie na 22 i 443 z rutera do ASA ale na 179 juz nie, gdy polaczenie wychodzi z vrf Mgmt-intf?
Nie masz problemów może z TTL? W eBGP masz TTL na 1 ustawiony. TTL Security masz poprawnie ustawione? Jeszcze MTU bym sprawdził na wszystkich urządzeniach.

_________________
Pozdrawiam
Krzysiek Te.


Na górę
Post #5 : 29 gru 2017, 10:01 
Offline
wannabe
wannabe
Awatar użytkownika

Rejestracja: 20 cze 2007, 08:53
Posty: 136
Cytuj:

Nie masz problemów może z TTL? W eBGP masz TTL na 1 ustawiony. TTL Security masz poprawnie ustawione? Jeszcze MTU bym sprawdził na wszystkich urządzeniach.
Czesc, wykonuje probe polaczenia na port 179 ktory wystawilem na http ASA, TTL nic nie ma tutaj do rzeczy bo nie lacze sie do samej uslugi BGP, ruch wraca na router cisco (widac to w logach) ale nie jest przez niego przetwarzany. Zrobilem to w ramach testu, inne hosty moga sie polaczyc do takiej uslugi.

Napisalem wczesniej ze sesje chce zestawic z interfejsem management rutera, domyślnie jest to vrf Mgmt-intf ktory jest po wyjeciu rutera z pudelka. Moze to jest problem?


Na górę
Post #6 : 29 gru 2017, 13:52 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3895
Cytuj:
Taka sama sytuacja jest gdy skonfiguruje BGP na ruterze i ASA prawidlowo, czyli address-family ipv4 + ebgp-multihop.
O to pytałem na samym początku. Pokaż konfigurację tego BGP, jeśli robisz ją tak jak napisałeś powyżej, robisz to źle.

Jeśli sesja ma być z VRFu Mgmt-intf to tak powinna zostać skonfigurowana w procesie BGP.


Na górę
Post #7 : 03 sty 2018, 08:56 
Offline
wannabe
wannabe
Awatar użytkownika

Rejestracja: 20 cze 2007, 08:53
Posty: 136
Cytuj:
Cytuj:
Taka sama sytuacja jest gdy skonfiguruje BGP na ruterze i ASA prawidlowo, czyli address-family ipv4 + ebgp-multihop.
O to pytałem na samym początku. Pokaż konfigurację tego BGP, jeśli robisz ją tak jak napisałeś powyżej, robisz to źle.

Jeśli sesja ma być z VRFu Mgmt-intf to tak powinna zostać skonfigurowana w procesie BGP.
Czesc, skonfigurowalem BGP na globalnej tablicy routingu, z tego wzgledu że potrzebuje leakowac do tablicy globalnej wiecej niz 1000 prefixow a nie chce zmieniac domyslnych ustawien. Ponizej konfiguracja ktora testowałem, może jest coś źle:
Kod:
router bgp 65001
 bgp log-neighbor-changes
 network X.X.X.0
 neighbor A.A.A.249 remote-as 65001
 neighbor A.A.A.249 update-source Loopback0
 neighbor A.A.A.249 next-hop-self
 neighbor B.B.B.73 remote-as BBB
 neighbor B.B.B.73 send-community both
 neighbor B.B.B.73 route-map ROUTE_MAP_IN in
 neighbor B.B.B.73 route-map ROUTE_MAP_OUT out
 address-family ipv4 vrf Mgmt-intf
	neighbor 10.80.11.20 remote-as 65000
	neighbor 10.80.11.20 ebgp-multihop 4
	neighbor 10.80.11.20 update-source GigabitEthernet0
	neighbor 10.80.11.20 activate
	neighbor 10.80.11.20 send-community both
	neighbor 10.80.11.20 next-hop-self
	neighbor 10.80.11.20 soft-reconfiguration inbound
	neighbor 10.80.11.20 route-map ROUTE_FEEDER_IN in
lbromirs, wydaje mi sie ze problemem nie jest samo bgp, nie rozumiem dlaczego nie moge zrobic telnet z routera -> na fake usluge bgp ktora tak naprawde jest uruchomiona na serwisie HTTP ASA. W czasie testow usunalem powyzsza konfiguracje bgp, jak widac w logach z poprzedniego mojego postu, na 22 moglem sie polaczyc z rutera (czyli acl vrf routing jest OK), na 179 ASA wysylala odpowiedz ale router ciagle stukal SYN. Z innego hosta moglem jak najbardziej polaczyc sie na taka usluge ASA port 179.

Może jest jakieś zabezpieczenie na samym ruterze odnosnie portu 179? Przypominam że vrf Mgmt-intf to domyslny VRF ktory jest w konfigu po wyjeciu rutera z pudelka.


Na górę
Wyświetl posty nie starsze niż:  Sortuj wg  
Nowy temat  Odpowiedz w temacie  [ Posty: 7 ] 

Strefa czasowa UTC+01:00


Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość


Nie możesz tworzyć nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Przejdź do:  
cron
This Website is not sponsored by, endorsed by or affiliated with Cisco Systems, Inc. Cisco, Cisco Systems, CCDA, CCNA, CCDP, CCNP, CCIE, CCSI, CCIP, the Cisco Systems logo and the CCIE logo are trademarks or registered trademarks of Cisco Systems, Inc. in the United States and certain other countries. Używamy informacji zapisanych za pomocą cookies i podobnych technologii m.in. w celach reklamowych i statystycznych oraz w celu dostosowania naszych serwisów do indywidualnych potrzeb użytkowników. Mogą też stosować je współpracujące z nami firmy. W programie służącym do obsługi internetu można zmienić ustawienia dotyczące cookies. Korzystanie z naszych serwisów internetowych bez zmiany ustawień dotyczących cookies oznacza, że będą one zapisane w pamięci urządzenia.



Technologię dostarcza phpBB® Forum Software © phpBB Limited
Polski pakiet językowy dostarcza phpBB.pl