Jump to content
Калькуляторы

Quagga не пойму по маршрутизации.

Собрал в виртуалке след схему

quagga.jpg

CentOS release 6.5

quagga version 0.99.15

 

 

AS12000

bgpd.conf

 

 


hostname AS12000
password zebra
enable password zebra
log file /var/log/quagga/bgpd.log
log stdout 

router bgp 12000
bgp router-id 10.10.1.254
network 10.10.0.0/23
network 10.10.0.0/24
network 10.10.1.0/24

neighbor 172.22.0.2 remote-as 12010
neighbor 172.22.0.2 description Uplink1
neighbor 172.22.0.2 next-hop-self
neighbor 172.22.0.2 soft-reconfiguration inbound


neighbor 172.25.0.2 remote-as 12030
neighbor 172.25.0.2 description Uplink2
neighbor 172.25.0.2 next-hop-self
neighbor 172.25.0.2 soft-reconfiguration inbound

 

 

 

zebra.conf

 

 

hostname AS12000
password 123
enable password 123
log file /var/log/quagga/zebra.log

debug zebra events 
debug zebra packet 

interface vlan10
ipv6 nd suppress-ra 

interface vlan40
ipv6 nd suppress-ra 

interface vlan1000 
ipv6 nd suppress-ra 

ip route 10.10.0.0/23 Null0 254 
ip forwarding 
line vty 
exec-timeout 0 0 

 

 

 

 

 

При пинге с AS12000 ip из AS12010 и AS12030 все норма, а вот ip из AS12020 недоступны

 

sh ip bgp 10.30.0.1

BGP routing table entry for 10.30.0.0/24
Paths: (2 available, best #2, table Default-IP-Routing-Table)
 Advertised to non peer-group peers:
 172.22.0.2
 12010 12020
   172.22.0.2 from 172.22.0.2 (10.20.1.254)
     Origin IGP, localpref 100, valid, external
     Last update: Sat Jul 12 20:20:41 2014

 12030 12020
   172.25.0.2 from 172.25.0.2 (10.40.1.254)
     Origin IGP, localpref 100, valid, external, best
     Last update: Sat Jul 12 20:20:39 2014

 

Тоже самое происходит с любой AS при попытке доступа к ип через одну AS-ку.

Share this post


Link to post
Share on other sites

1) Причем тут квагга если маршруты получаются?

2) net.ipv4.ip_forward - разрешен? Думается, нет. Потому никто ничего и не роутит...

Share this post


Link to post
Share on other sites

1) Причем тут квагга если маршруты получаются?

2) net.ipv4.ip_forward - разрешен? Думается, нет. Потому никто ничего и не роутит...

форвардинг включен

cat /proc/sys/net/ipv4/ip_forward 
1

Share this post


Link to post
Share on other sites

А с AS1220 как выглядит sh ip bgp 10.10.0.0

 

sh ip bgp 10.10.0.0
BGP routing table entry for 10.10.0.0/24
Paths: (2 available, best #2, table Default-IP-Routing-Table)
 Advertised to non peer-group peers:
 172.23.0.1
 12030 12000
   172.23.0.1 from 172.23.0.1 (10.40.1.254)
     Origin IGP, localpref 100, valid, external
     Last update: Sat Jul 12 20:20:59 2014

 12010 12000
   172.24.0.1 from 172.24.0.1 (10.20.1.254)
     Origin IGP, localpref 100, valid, external, best
     Last update: Sat Jul 12 20:20:58 2014

Share this post


Link to post
Share on other sites
router bgp 12000

bgp router-id 10.10.1.254

network 10.10.0.0/23

network 10.10.0.0/24

network 10.10.1.0/24

 

Я не специалист BGP, но это точна так?

Edited by Mindaugas

Share this post


Link to post
Share on other sites
router bgp 12000

bgp router-id 10.10.1.254

network 10.10.0.0/23

network 10.10.0.0/24

network 10.10.1.0/24

 

Я не специалист BGP, но это точна так?

 

Да вроде норма, разбил /23 подсеть на две /24

Share this post


Link to post
Share on other sites

iptables может что-то содержит? Пинг вообще не особый показатель, смотрите tcpdumpом на роутерах пакеты.

Share this post


Link to post
Share on other sites

iptables чист.

tcpdump пакеты фиксирует

10:24:40.281924 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
   172.22.0.1 > 10.30.0.1: ICMP echo request, id 5429, seq 19, length 64

 

Но трафик так и не идет, nmap тоже ничего не видит

nmap -sS 10.30.0.1

Starting Nmap 5.51 ( http://nmap.org ) at 2014-07-13 10:32 MSK
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.05 seconds

 

Хотя если запустить nmap с соседней AS12010, то все норма

nmap -sS 10.30.0.1

Starting Nmap 5.51 ( http://nmap.org ) at 2014-07-13 10:35 MSK
Nmap scan report for 10.30.0.1
Host is up (0.00013s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
111/tcp open  rpcbind
179/tcp open  bgp

Share this post


Link to post
Share on other sites

если у вас получился роутинг асимметричный, то надо выключать rp_filter. ещё вариант, что сосед не знает о сети, в которую входит ip.src c которого идёт ping

 

в вашем случае, лучше смотреть таблицу маршрутизации не в bgp, а в ядре linux-а через ip или route (на случай глюков bgpd/zebra, хотя это и маловероятно)

Share this post


Link to post
Share on other sites

Отключите кваггу и настройте статику. Если ping заработает, то проблема в настройках квагги. По сути квагга добавляет аналогичные маршруты в ТМ ядра.

Если не заработает то крутите ядро.

Share this post


Link to post
Share on other sites

Остановил quagga, прописал маршруты руками

 

AS12000

10.30.0.0/23 via 172.22.0.2 dev vlan10 
10.20.0.0/23 via 172.22.0.2 dev vlan10 

 

AS12010

10.30.0.0/23 via 172.24.0.1 dev vlan30 
10.10.0.0/23 via 172.22.0.1 dev vlan10 

 

AS12030

10.10.0.0/23 via 172.24.0.1 dev vlan30 
10.20.0.0/23 via 172.24.0.1 dev vlan30 

 

Результ тотже, соседние пингуются без проблем, а через одну - нет.

Share this post


Link to post
Share on other sites

задайте явно ip.source для пинга из 10ой сети. у вас пинг идёт с 172* и хост "через одну" не знает об этом src

 

после выключения zebra у вас ip.forward по прежнему =1 или становится 0?

Share this post


Link to post
Share on other sites

задайте явно ip.source для пинга из 10ой сети. у вас пинг идёт с 172* и хост "через одну" не знает об этом src

 

после выключения zebra у вас ip.forward по прежнему =1 или становится 0?

Точно, указал

ping 10.30.0.1 -I 10.10.0.1

и пинг пошел.

Спасибо.

Share this post


Link to post
Share on other sites

neighbor 172.22.0.2 next-hop-self вот это вам зачем на ebgp линках?

Share this post


Link to post
Share on other sites

Merridius

оно же не влияет в случае ebgp, так что пофиг есть там оно или нет

Share this post


Link to post
Share on other sites

Merridius

оно же не влияет в случае ebgp, так что пофиг есть там оно или нет

 

Да оно понятно. Считаю, чем меньше лишнего, тем лучше.

Share this post


Link to post
Share on other sites

Иногда явное указание неявных правил даже рекомендуют, например в одном из банков принято писать deny any в конце ACL-ей, даже если оно и так там есть, видимо кто-то когда-то с этим накололся и ввели такую политику.

Share this post


Link to post
Share on other sites

Иногда явное указание неявных правил даже рекомендуют, например в одном из банков принято писать deny any в конце ACL-ей, даже если оно и так там есть, видимо кто-то когда-то с этим накололся и ввели такую политику.

 

Кто-то когда-то просто мануалы не читал. :-)

Потом это приводит и к другим перлам с PBR, например. И политика снова меняется.

Share this post


Link to post
Share on other sites
Иногда явное указание неявных правил даже рекомендуют, например в одном из банков принято писать deny any в конце ACL-ей, даже если оно и так там есть, видимо кто-то когда-то с этим накололся и ввели такую политику.
а чтобы добавить в такой ацл правило надо его переписать ? отличная практика. :)

Share this post


Link to post
Share on other sites

pfexec

далеко не на всех cisco ACL-и редактируются через замену

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this