Quagga

[Tem]

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

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-ку.

[NiTr0]

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

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

[Tem]

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

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

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

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

[disappointed]

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

[Tem]

А с 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

[Mindaugas]

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 July 12, 2014 by Mindaugas

[Tem]

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

[DVM-Avgoor]

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

[Tem]

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

[s.lobanov]

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

 

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

[QWE]

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

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

[Tem]

Остановил 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 

 

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

[s.lobanov]

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

 

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

[Tem]

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

 

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

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

ping 10.30.0.1 -I 10.10.0.1

и пинг пошел.

Спасибо.

[Merridius]

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

[s.lobanov]

Merridius

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

[Merridius]

Merridius

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

 

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

[s.lobanov]

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

[DVM-Avgoor]

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

 

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

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

[pfexec]

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

а чтобы добавить в такой ацл правило надо его переписать ? отличная практика. :)

[s.lobanov]

pfexec

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