lumenok

РДП вполне рабочее решение, интегрировали у нескольких операторов, есть свои тонкости в интеграции, но это зависит от биллинга. Софтовые брасы, бесплатные можно смотреть в сторону accell-ppp, отличное решение, но если ни разу не настраивали, нагрузку надо давать понемногу и тюнить. С рдп вполне реально договорится на рассрочки. На рдп переходили в том числе с reback и asr.

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

без qinq на прошивк 1.2.5p3 config ter vlan 10 name transit10 exit vlan 1550 name transit1550 exit ! interface xgei_1/4/2 switchport vlan 10,1550 tag exit ! pon onu-profile gpon remote VLAN_TRANSIT service VlanTransit gemport 1 vlan 10,1550 gemport 1 loop enable ! ! interface gpon-olt_1/1/8 onu 100 type ONT_1G sn ZTEGC06BA470 onu 100 profile line LP_ONU-1G remote VLAN_TRANSIT exit ! interface gpon-onu_1/1/8:100 security storm-control broadcast rate 256 direction ingress vport 1 switchport mode trunk vport 1 switchport vlan 10,1550 tag vport 1 exit !

А зачем такая короткая лиза? Мы на старых тплинках часто такое наблюдаем.

А после прописывания ону сброс и ресет онушки делали? send omci restore interface ont 0/111

Да дело в том что когда я пингую клиентом по ethernet , то такой проблемы нет!

ВСем привет, я все по старой проблеме , плавает пинг, когда клиент смотрит ютуб или качает торренты, то есть при нагрузке канала. С gpon ранее дело не имели, если канал не нагружен, то пинг до шлюза 2-3 ms, иногда подскакивает до 10, это норма для gpon'a? Скриншоты приложил.

Поделитесь мибами, пожалуйста!

>Если он не умеет терминировать, то почему вы называете его брас? Наверное лишь часть функций браса, радиус сессии абонентов и применяемые им политики , а так режем на нем скорости! По цене это индивидуально, покрайней мере у нас было!

Перешли с redback' ов se100 на rdp который econat2040, терминировать не умеет, ставился в разрез, делаем на нем брас и нат, а также фильтрацию ркн, есть свои нюансы, но все устраивает.

Olt, только L2

День добрый! Тестирует zte c320 прошивка 1.2.5p3. Никто сталкивался такой проблемой. У абонента на gpon пинг плавает, даже до шлюза, а если абонен тсмотрит например видео в ютубу то даже до шлюза может прыгать до 40 мс? Абонентов всего пять , все тестовые.

CSCva92216 Help | Feedback Feedback BGP session is reset when unrecognized capability received in OPEN message CSCva92216 Description Symptom: BGP session will not come up with peer if an unrecognized or unsupported capability is received from the peer in the BGP OPEN. Message similar to the following might be observed: Aug 4 16:20:22.627: %BGP-3-NOTIFICATION: sent to neighbor 10.100.100.100 active 2/0 (open: unspecific subcode) 0 bytes Aug 4 16:20:22.627: %BGP-4-MSGDUMP: unsupported or mal-formatted message received from 10.100.100.100: Expected behavior is that the local device should ignore the unrecognized/unsupported capability and bring the session up with the known capabilities, but that does not occur. Conditions: Local device is an IOS or IOS-XE device running a release that has the changes introduced in CSCuz20869. Remote BGP peer sends a BGP OPEN which advertises a capability that is not recognized or not supported by the local device. Workaround: Identify the unsupported capability that is being advertised, and reconfigure the remote peer to suppress advertisement of this capability. The exact method to do so will vary based on the remote peer's platform, software version, etc; The unsupported capability can be identified by enabling "debug bgp ipv4 unicast in" on the local peer. For example the following debug messages tell us that the peer is sending as BGP capability 5 which is not supported by the local peer: *Sep 11 18:31:14.867: BGP: 10.128.129.134 active OPEN has CAPABILITY code: 5, length 6 *Sep 11 18:31:14.867: BGP: 10.128.129.134 active unrecognized capability code: 5 *Sep 11 18:31:14.867: BGP: 10.128.129.134 active malformed/un-supported OPEN capability *Sep 11 18:31:14.867: BGP: 10.128.129.134 active went from OpenSent to Closing *Sep 11 18:31:14.867: %BGP-3-NOTIFICATION: sent to neighbor 10.128.129.134 active 2/0 (open: unspecific subcode) 0 bytes Further Problem Description: This defect is unintended collateral caused by the fix of CSCuz20869. If a given release does not have the prior fix, then it is not impacted by this problem. Никто не словил еще такой же сюрприз на cisco по bgp? Описание на cisco.com

Не забывайте нас освещать!)

В режим конфигурирования нас входили ? config nas