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

VPLS ASR1002 и ASR9001, не проходят пакеты больше 1498 байт "я сошла с ума, какая досада" (с) :-)

Добрый день, уважаемые коллеги!

Вот есть у меня 2 устройства (см.сабж), меж ними ходит сигнализация mpls и вроде бы работают сервисы vpls, НО! выяснился пренеприятнейший момент: внутри vpls на данном участке не проходят пакеты размером больше 1498 байт.

Все мероприятия по контролю mtu на всем пути следования пакетов вроде как выполнены: на 9001 mtu 9000, на ASR1002 - 1546, на присоединенных в качестве стенда коммутаторах с одной и другой стороны mtu 1546

 

схема стенда вкратце: Cat4900 - ASR90001 - ASR1002 - ME3600x

Если с SVI одного коммутатора пинговать SVI другого, то успешный пинг прекращается ровно после установки размера пакета 1499 байт.

конфиг 9001:

l2vpn
logging
 bridge-domain
 pseudowire
!
pw-class core-vpls
 encapsulation mpls
  protocol ldp
 !
!
bridge group from-7606A
 bridge-domain 38
  mtu 1510
  interface Bundle-Ether1.38
  !
  vfi ATVC-Corporate
   neighbor 62.192.224.35 pw-id 38
    pw-class core-vpls

 

конфиг 1002:

l2 vfi ATVC-Corporate manual 
vpn id 38
bridge-domain 38
mtu 1510
neighbor 62.192.224.46 encapsulation mpls
!

 

Попытки поиграться с параметрами mtu внутри bridge-domain ситуацию не меняют совершенно никак.

 

картина сервиса на 1002:

sh mpls l2transport vc 38 det
Local interface: VFI ATVC-Corporate vfi up
 Interworking type is Ethernet
 Destination address: 62.192.224.46, VC ID: 38, VC status: up
   Output interface: Po1.897, imposed label stack {34 16000}
   Preferred path: not configured  
   Default path: active
   Next hop: 62.192.224.14
 Create time: 00:31:22, last status change time: 00:30:59
   Last label FSM state change time: 00:30:59
 Signaling protocol: LDP, peer 62.192.224.46:0 up
   Targeted Hello: 62.192.224.35(LDP Id) -> 62.192.224.46, LDP is UP
   Graceful restart: not configured and not enabled
   Non stop routing: not configured and not enabled
   Status TLV support (local/remote)   : enabled/supported
     LDP route watch                   : enabled
     Label/status state machine        : established, LruRru
     Last local dataplane   status rcvd: No fault
     Last BFD dataplane     status rcvd: Not sent
     Last BFD peer monitor  status rcvd: No fault
     Last local AC  circuit status rcvd: No fault
     Last local AC  circuit status sent: No fault
     Last local PW i/f circ status rcvd: No fault
     Last local LDP TLV     status sent: No fault
     Last remote LDP TLV    status rcvd: No fault
     Last remote LDP ADJ    status rcvd: No fault
   MPLS VC labels: local 155, remote 16000 
   Group ID: local 0, remote 1
   MTU: local 1510, remote 1510
   Remote interface description: ATVC-Corporate
 Sequencing: receive disabled, send disabled
 Control Word: Off (configured: autosense)
 SSO Descriptor: 62.192.224.46/38, local label: 155
 Dataplane:
SSM segment/switch IDs: 4221/8314 (used), PWID: 2
 VC statistics:
   transit packet totals: receive 10, send 11
   transit byte totals:   receive 8172, send 10019
   transit packet drops:  receive 0, seq error 0, send 0

 

На 9001:

sh l2vpn bridge-domain bd-name 38 det
Sat Feb 21 14:22:41.568 MSK
Legend: pp = Partially Programmed.
Bridge group: from-7606A, bridge-domain: 38, id: 1, state: up, ShgId: 0, MSTi: 0
 Coupled state: disabled
 MAC learning: enabled
 MAC withdraw: enabled
   MAC withdraw for Access PW: enabled
   MAC withdraw sent on: bridge port up
   MAC withdraw relaying (access to access): disabled
 Flooding:
   Broadcast & Multicast: enabled
   Unknown unicast: enabled
 MAC aging time: 300 s, Type: inactivity
 MAC limit: 4000, Action: none, Notification: syslog
 MAC limit reached: no
 MAC port down flush: enabled
 MAC Secure: disabled, Logging: disabled
 Split Horizon Group: none
 Dynamic ARP Inspection: disabled, Logging: disabled
 IP Source Guard: disabled, Logging: disabled
 DHCPv4 snooping: disabled
 IGMP Snooping: enabled
 IGMP Snooping profile: none
 MLD Snooping profile: none
 Storm Control: disabled
 Bridge MTU: 1510
 MIB cvplsConfigIndex: 2
 Filter MAC addresses:
 P2MP PW: disabled
 Create time: 01/12/2014 18:50:12 (11w4d ago)
 No status change since creation
 ACs: 1 (1 up), VFIs: 1, PWs: 1 (1 up), PBBs: 0 (0 up)
 List of ACs:
   AC: Bundle-Ether1.38, state is up
     Type VLAN; Num Ranges: 1
     VLAN ranges: [989, 989]
     MTU 8994; XC ID 0xa0000006; interworking none
     MAC learning: enabled
     Flooding:
       Broadcast & Multicast: enabled
       Unknown unicast: enabled
     MAC aging time: 300 s, Type: inactivity
     MAC limit: 4000, Action: none, Notification: syslog
     MAC limit reached: no
     MAC port down flush: enabled
     MAC Secure: disabled, Logging: disabled
     Split Horizon Group: none
     Dynamic ARP Inspection: disabled, Logging: disabled
     IP Source Guard: disabled, Logging: disabled
     DHCPv4 snooping: disabled
     IGMP Snooping: enabled
     IGMP Snooping profile: none
     MLD Snooping profile: none
     Storm Control: disabled
     Static MAC addresses:
     Statistics:
       packets: received 1631, sent 129
       bytes: received 134145, sent 23350
     Storm control drop counters: 
       packets: broadcast 0, multicast 0, unknown unicast 0 
       bytes: broadcast 0, multicast 0, unknown unicast 0 
     Dynamic ARP inspection drop counters: 
       packets: 0, bytes: 0
     IP source guard drop counters: 
       packets: 0, bytes: 0
 List of Access PWs:
 List of VFIs:
   VFI ATVC-Corporate (up)
     PW: neighbor 62.192.224.35, PW ID 38, state is up ( established )
       PW class core-vpls, XC ID 0xc0000001
       Encapsulation MPLS, protocol LDP
       Source address 62.192.224.46
       PW type Ethernet, control word disabled, interworking none
       Sequencing not set

       PW Status TLV in use
         MPLS         Local                          Remote                        
         ------------ ------------------------------ -------------------------
         Label        16000                          155                           
         Group ID     0x1                            0x0                           
         Interface    ATVC-Corporate                 unknown                       
         MTU          1510                           1510                          
         Control word disabled                       disabled                      
         PW type      Ethernet                       Ethernet                      
         VCCV CV type 0x2                            0x2                           
                      (LSP ping verification)        (LSP ping verification)       
         VCCV CC type 0x6                            0x6                           
                      (router alert label)           (router alert label)          
                      (TTL expiry)                   (TTL expiry)                  
         ------------ ------------------------------ -------------------------
       Incoming Status (PW Status TLV):
         Status code: 0x0 (Up) in Notification message
       MIB cpwVcIndex: 3221225473
       Create time: 01/12/2014 18:50:12 (11w4d ago)
       Last time status changed: 21/02/2015 13:51:02 (00:31:39 ago)
       Last time PW went down: 21/02/2015 13:50:38 (00:32:03 ago)
       MAC withdraw messages: sent 1, received 0
       Static MAC addresses:
       Statistics:
         packets: received 129, sent 1583
         bytes: received 23866, sent 136681
       Storm control drop counters: 
         packets: broadcast 0, multicast 0, unknown unicast 0 
         bytes: broadcast 0, multicast 0, unknown unicast 0 
     DHCPv4 snooping: disabled
     IGMP Snooping profile: none
     MLD Snooping profile: none
     VFI Statistics:
       drops: illegal VLAN 0, illegal length 0

 

Прошу помощи у компетентного сообщества.

Заранее спасибо.

Share this post


Link to post
Share on other sites

А что на интерфейсах?

 

позволю себе повториться:

 

на 9001 mtu 9000, на ASR1002 - 1546, на присоединенных в качестве стенда коммутаторах с одной и другой стороны mtu 1546

 

или Вы не это имели ввиду?

Share this post


Link to post
Share on other sites

такое ощущение, что позабыто rewrite ingress tag pop 1 symmetric.

 

Оно бы тогда вообще не работало imho, а пакеты ходят и вполне себе стабильно с разными vpnid.

вот настройки instances с обеих сторон:

ASR9001:

sh run int bundle-ether 1.38
Tue Feb 24 09:04:19.281 MSK
interface Bundle-Ether1.38 l2transport
encapsulation dot1q 989
rewrite ingress tag push dot1q 38 symmetric

ASR1002:

interface Port-channel1
description *** Uplink ***
mtu 1546
no ip address
load-interval 30
no negotiation auto
ip rsvp bandwidth
service instance 38 ethernet
 encapsulation dot1q 989
 rewrite ingress tag push dot1q 38 symmetric
 bridge-domain 38
!

Share this post


Link to post
Share on other sites

Не совсем понятен смысл в навешивании дополнительной метки в pw, вы же сами только увеличиваете транзитное мту. К слову, на sh int X/X/X счетчик overrun ни где не щелкает по случаю?

Share this post


Link to post
Share on other sites

Не совсем понятен смысл в навешивании дополнительной метки в pw, вы же сами только увеличиваете транзитное мту.

Это в областном центре так построена metro сетка была в свое время - до ядра с один тегом, дальше навешиваем второй, заворачиваем в vpls и тащим до брасов уже с 2 тегами, l2-connected короче :-) Ну и с данным проблемным узлом схему никто не стал менять, ибо надо гонять трафик корпоратов в vpls по обсласти. На увеличение транзитного mtu в общем и целом пофик, магистрали позволяют гнать пакеты больше стандартных 1500 байт.

 

на sh int X/X/X счетчик overrun ни где не щелкает по случаю?

 

ASR 9000:


sh int bundle-ether 1   
Tue Feb 24 10:27:51.511 MSK
Bundle-Ether1 is up, line protocol is up 
 Interface state transitions: 1
 Hardware is Aggregated Ethernet interface(s), address is 10f3.1101.1533
 Description: *** to 4900M-ASR9K1 ***
 Internet address is Unknown
 MTU 9000 bytes, BW 40000000 Kbit (Max: 40000000 Kbit)
    reliability 255/255, txload 0/255, rxload 0/255
 Encapsulation ARPA,
 Full-duplex, 40000Mb/s
 loopback not set,
   No. of members in this bundle: 4
     TenGigE0/0/2/0               Full-duplex  10000Mb/s    Active          
     TenGigE0/0/2/1               Full-duplex  10000Mb/s    Active          
     TenGigE1/0/2/0               Full-duplex  10000Mb/s    Active          
     TenGigE1/0/2/1               Full-duplex  10000Mb/s    Active          
 Last input 00:00:00, output 00:00:00
 Last clearing of "show interface" counters never
 5 minute input rate 125207000 bits/sec, 11542 packets/sec
 5 minute output rate 136572000 bits/sec, 12337 packets/sec
    119385117068 packets input, 109177102630018 bytes, 9 total input drops
    974725 drops for unrecognized upper-level protocol
    Received 5691368 broadcast packets, 119034021250 multicast packets
             0 runts, 0 giants, 0 throttles, 0 parity
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    120324498222 packets output, 113962259386753 bytes, 0 total output drops
    Output 885698 broadcast packets, 101422960 multicast packets
    0 output errors, 0 underruns, 0 applique, 0 resets
    0 output buffer failures, 0 output buffers swapped out
    0 carrier transitions

ASR 1002:

sh int po1
Port-channel1 is up, line protocol is up 
 Hardware is GEChannel, address is b0fa.eb6d.d4c0 (bia b0fa.eb6d.d4c0)
 Description: *** Uplink ***
 MTU 1546 bytes, BW 4000000 Kbit/sec, DLY 10 usec, 
    reliability 255/255, txload 71/255, rxload 72/255
 Encapsulation 802.1Q Virtual LAN, Vlan ID  1., loopback not set
 Keepalive set (10 sec)
 ARP type: ARPA, ARP Timeout 04:00:00
   No. of active members in this channel: 4 
       Member 0 : GigabitEthernet0/0/0 , Full-duplex, 1000Mb/s
       Member 1 : GigabitEthernet0/0/1 , Full-duplex, 1000Mb/s
       Member 2 : GigabitEthernet0/0/2 , Full-duplex, 1000Mb/s
       Member 3 : GigabitEthernet0/0/3 , Full-duplex, 1000Mb/s
   No. of PF_JUMBO supported members in this channel : 4
 Last input 00:00:00, output never, output hang never
 Last clearing of "show interface" counters never
 Input queue: 0/1500/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/160 (size/max)
 30 second input rate 1128781000 bits/sec, 161402 packets/sec
 30 second output rate 1104648000 bits/sec, 160212 packets/sec
    1915874878090 packets input, 1508394751333050 bytes, 0 no buffer
    Received 0 broadcasts (0 IP multicasts)
    0 runts, 0 giants, 0 throttles 
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    0 watchdog, 1460134970 multicast, 0 pause input
    1913933913125 packets output, 1502470216771266 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 unknown protocol drops
    0 babbles, 0 late collision, 0 deferred
    0 lost carrier, 0 no carrier, 0 pause output
    0 output buffer failures, 0 output buffers swapped out

 

Вот нет у меня идей, окромя одновления ПО на asr1002, но хотелось бы еще поколдовать, чтобы окончательно в тщетности попыток убедиться :-)

Share this post


Link to post
Share on other sites

а попробуйте все же с двух сторон rewrite ingress tag pop 1 sym

навесить лишние метки на выходе можно и другими способами (например приземлив vpls в dot1ad интерфейс)

Share this post


Link to post
Share on other sites

а попробуйте все же с двух сторон rewrite ingress tag pop 1 sym

Заработало, спасибо Вам за помощь.

Т.е. по-Вашему так оно каноничнее для железа cisco? :-)

Share this post


Link to post
Share on other sites

Т.е. по-Вашему так оно каноничнее для железа cisco? :-)

по мне так логичней таскать в pw-трубе чистый трафик, а все необходимые метки навешивать на нужных концах.

Share this post


Link to post
Share on other sites

Апну топик, ибо в прошлый раз не довели до конца как выяснилось :-)

Итак: в варианте, который вроде как всех устроил, есть один косяк: на устройствах, кроме asr9000 (7600, ASR1000) при попытке сделать следующее:

 

service instance 38 ethernet
 encapsulation dot1q 988,989
 rewrite ingress tag pop 1 symmetric
 bridge-domain 38

 

Все заканчивается ошибкой и не дает она больше 1 vlan в bridge-domain загнать с интерфейса. Судя по документации на ASR9000 там это дело разрешено, потому что циска сама добавляет служебные теги к пакетам, если их на входе снимают, и отправляет все это дальше внутри vpls, а вот более старые платформы такого не делают.

Так что опять актуален вопрос: как все-таки преодолеть этот дурацкий баг с нестандартным mtu в vpls у asr1000.

Share this post


Link to post
Share on other sites

Рисуйте схему и подробное ТЗ - что откуда и куда надо передать, с указанием моделей железок.

Пока я вижу только то, что вы пытаетесь в одной трубе передать 2 влана, и приземлить их через 1 bd.

Как минимум не понимаю нахрена тут bd. Более того, многие железки вовсе не дают применять единый bd в нескольких service instance.

Задача решаема, но только если подробно расписать чего вы хотите в итоге передать.

Share this post


Link to post
Share on other sites

Пока я вижу только то, что вы пытаетесь в одной трубе передать 2 влана, и приземлить их через 1 bd.

Именно это и делается, расскажите, что по-Вашему не так? В терминологии MEF это E-LAN. На 76 платформе и стыках её и 9000 все это прекрасно живет именно в том виде, который я пытался реализовать на стыке 9000 и 1000, и даже здесь оно взлетает, ибо в общем-то сделано по мануалу от всемилюбимоговендора :-)

Как минимум не понимаю нахрена тут bd.

А как бы сделали Вы, имея набор из 7600, 9000 и 1000 серий устройств?

Share this post


Link to post
Share on other sites

А как бы сделали Вы, имея набор из 7600, 9000 и 1000 серий устройств?

Сильно зависит от того, какую роль исполняет каждое из устройств. Приземление в bd интересно разве что на 3600, в котором можно еще и vfi развернуть. a9k не в счет, там bd вообще как основной инструмент.

Share this post


Link to post
Share on other sites

Сильно зависит от того, какую роль исполняет каждое из устройств.

В данном случае PE

 

Приземление в bd интересно разве что на 3600, в котором можно еще и vfi развернуть.

Именно это и сделано, я честно не знаю как еще по-другому прогнать пачку vlan от разных абонентов в одном vpls, ну разве еще selective qinq городить на комумтаторах, но vfi с bd в данном разрезе мне кажутся сильно более удобными

Share this post


Link to post
Share on other sites

Именно это и сделано, я честно не знаю как еще по-другому прогнать пачку vlan от разных абонентов в одном vpls, ну разве еще selective qinq городить на комумтаторах, но vfi с bd в данном разрезе мне кажутся сильно более удобными

На 76-й с ES+ картами работает такая конструкция:

service instance 988 ethernet
 encapsulation dot1q 988
 rewrite ingress tag pop 1 symmetric
 bridge-domain 38
service instance 989 ethernet
 encapsulation dot1q 989
 rewrite ingress tag pop 1 symmetric
 bridge-domain 38

Edited by sio

Share this post


Link to post
Share on other sites

Апну топик, ибо в прошлый раз не довели до конца как выяснилось :-)

Итак: в варианте, который вроде как всех устроил, есть один косяк: на устройствах, кроме asr9000 (7600, ASR1000) при попытке сделать следующее:

 

service instance 38 ethernet
 encapsulation dot1q 988,989
 rewrite ingress tag pop 1 symmetric
 bridge-domain 38

 

Все заканчивается ошибкой и не дает она больше 1 vlan в bridge-domain загнать с интерфейса. Судя по документации на ASR9000 там это дело разрешено, потому что циска сама добавляет служебные теги к пакетам, если их на входе снимают, и отправляет все это дальше внутри vpls, а вот более старые платформы такого не делают.

Так что опять актуален вопрос: как все-таки преодолеть этот дурацкий баг с нестандартным mtu в vpls у asr1000.

Если подумать, то такое поведение логично, эта настройка симметрична, допустим прямой трафик она отработает. а подумайте что циска должна сделать с обратным трафиком.

Share this post


Link to post
Share on other sites

На 76-й с ES+ картами работает такая конструкция:

Да, но при попытке добавить несколько vlans в один bd говорит, что платформа такого не умеет, у меня правда карты просто ES

Если подумать, то такое поведение логично, эта настройка симметрична, допустим прямой трафик она отработает. а подумайте что циска должна сделать с обратным трафиком.

Вы правы, в 9-тонниках например служебные теги навешивают, чтобы не путался трафик (так в доке написано по крайней мере).

В общем вывод пока один - баг в софте 1000 серии, к выходным попробую обновиться до 3.13.2, посмотреть, а вдруг индийские товарищи исправились :-)

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