[al18811]

Есть такой cisco-конфиг:

pseudowire-class VP
encapsulation mpls
!
l2 vfi NAME manual
neighbor x.y.z.v 111111 pw-class VP
neighbor x.y.z.v 111112 pw-class VP
neighbor x.y.z.k 555666 pw-class VP
!

 

Нужно сделать тоже самое на juniper mx (junos 11.3/11.4). Есть mesh-group, вроде бы всё хорошо, но vpls-id(тоже самое что у cisco vc-id) можно назначить только на всю mesh-group, а per-neighbour нельзя. Можно ли повторить конфиг cisco vfi на juniper?

[CityFox]

У Juniper в одном VPLS может быть несколько mesh-group c разными vpls-id.

Но всего mesh-group может быть то ли 16, то ли 18 на коробку.

 

Еще можно попробовать терминировать l2circuit на lt интерфейс и другой конец этого lt запихивать в VPLS.

[al18811]

CityFox, спасибо. Может накидать конфиг с l2circuit? А то 16 mesh-group(в реальности, 14) маловато будет

[fomka31ru]

RI-BGP {
   instance-type vpls;
   interface ge-0/0/0.77; ## 'ge-0/0/0.77' is not defined
   protocols {
       vpls {
           site-range 255;
           interface ge-0/0/0.77;
           site site1 {
               site-identifier 1;
           }
       }
   }
}
RI-LDP {
   instance-type vpls;
   protocols {
       vpls {
           vpls-id 1;
           neighbor 1.1.1.1 {
               encapsulation-type ethernet-vlan;
           }
           neighbor 1.1.1.2 {
               encapsulation-type ethernet;
           }
           connectivity-type permanent;
       }
   }
}

 

на вскидку, первый для построения использует BGP сигнализацию, второй - LDP.

и презенташка на эту тему

Изменено 4 апреля, 2012 пользователем fomka31ru

[CityFox]

Выглядеть должно как-то так:

 

lt-0/0/0 {
unit 0 {
 encapsulation vlan-ccc;
 vlan-id 100;
 peer-unit 1;
}
unit 1 {
 encapsulation vlan-bridge;
 vlan-id 100;
 peer-unit 0;
}
}


l2circuit {
neighbor 10.1.1.1 {
 interface lt-0/0/0.0 {
 virtual-circuit-id 10;
 }
}
}

routing-instance {
 test {
   instance-type vpls;
   interface lt-0/0/0.1;
}
}

[agr]

Для lt-0/0/0.1 наверно все же надо encapsulation vlan-vpls . Еще на серии MX для того, чтобы создать lt интерфейс, нужно пожертвовать одним физическим портом. Жертвоприношение делается командой

set chassis fpc 0 pic 0 tunnel-services bandwidth 10g

По поводу других платформ не скажу.

[Tima]

Еще на серии MX для того, чтобы создать lt интерфейс, нужно пожертвовать одним физическим портом. Жертвоприношение делается командой

set chassis fpc 0 pic 0 tunnel-services bandwidth 10g

По поводу других платформ не скажу.

 

 

Это справедливо только для DPC плат, на MPC портом жертвовать не надо.

 

p.s. Автору топика эта ссылка не поможет?

[al18811]

и презенташка на эту тему

Автору топика эта ссылка не поможет?

 

В обоих случаях, нет решения для per-neighbor vpls-id(vc-id). JTAC отправили к l2circuit увидев такую конфигурацию cisco, а именно сюда

[nfs5]

В обоих случаях, нет решения для per-neighbor vpls-id(vc-id). JTAC отправили к l2circuit увидев такую конфигурацию cisco, а именно сюда

 

Добрый день,

Удалось решить задачу назначения per neighbor vpls-id на Juniper более простым способом, чем предлагает CityFox?

[al18811]

Не удалось

[fomka31ru]

есть rfc в котором PW-ID должен быть одинаковым для всего VPLS домена.

Ориентироваться на проприетарную цисковскую хрень как-то не кошерно.

 

Можно конечно извратиться, потому что "все" ориентируются на "циска то, циска это, а в циске..." и

сделать через lt интерфейсы (пример где-то выше был), только использовать encapsulation vlan-vpls

Изменено 26 октября, 2012 пользователем fomka31ru

[sio]

есть rfc в котором PW-ID должен быть одинаковым для всего VPLS домена.

Номер rfc?

Ориентироваться на проприетарную цисковскую хрень как-то не кошерно.

Красиво описанная ущербность Джунипера :) Получается, что у всех вендоров можно уникальный vc-id на пира вешать, а у Джунипера нельзя. А как тогда h-vpls? А если мне надо несколько vc от одного пира принять?

[al18811]

Красиво описанная ущербность Джунипера :) Получается, что у всех вендоров можно уникальный vc-id на пира вешать, а у Джунипера нельзя. А как тогда h-vpls? А если мне надо несколько vc от одного пира принять?

 

На juniper-е любую vpls-фантазию можно реализовать средствами bgp-сигнализации путём rt import/export(идеалогия на все 146% такая же как у обычных mpls l3vpn). И на новых Cisco (ASR и т.п.) тоже это есть, а грабли появляются при попытке подружить c7600(с простыми линейными картами) с juniper-ами

[fomka31ru]

есть rfc в котором PW-ID должен быть одинаковым для всего VPLS домена.

Номер rfc?

Ориентироваться на проприетарную цисковскую хрень как-то не кошерно.

Красиво описанная ущербность Джунипера :) Получается, что у всех вендоров можно уникальный vc-id на пира вешать, а у Джунипера нельзя. А как тогда h-vpls? А если мне надо несколько vc от одного пира принять?

 

rfc 4762, читать в конце для тех у кого гугл забанен.

Про h-vpls не вижу проблем. Снова слова из воздуха?

 

зы: забыл добавить - циска *амно :)

Изменено 27 октября, 2012 пользователем fomka31ru

[sio]

есть rfc в котором PW-ID должен быть одинаковым для всего VPLS домена.

Номер rfc?

rfc 4762, читать в конце для тех у кого гугл забанен.

Про h-vpls не вижу проблем. Снова слова из воздуха?

 

зы: забыл добавить - циска *амно :)

RFC 4762 значит. Ну и как реализуется на Джунипере пункт 10.1.3 этого RFC?

[fomka31ru]

RFC 4762 значит. Ну и как реализуется на Джунипере пункт 10.1.3 этого RFC?

 

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

[sio]

RFC 4762 значит. Ну и как реализуется на Джунипере пункт 10.1.3 этого RFC?

 

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

Этот пункт предусматривает наличие двух vc до одного PE, пример цисковского конфига в первом сообщении этой темы, если вы его читали :)

[fomka31ru]

А какой смысл в 2х vc между 2мя устройствами?

[sio]

А какой смысл в 2х vc между 2мя устройствами?

1. удалённый PE тупо не умеет vpls или он на этом PE хреново работает.

2. кол-во vpls на железку как правило значительно меньше чем vc/vll/xconnect, для всех хотелок может и не хватить.

3. может оказаться так, что на PE сильно нежелательно изучать все mac-адреса vpls, ибо ресурсы ограничены.

 

Это так, навскидку.

 

4. модная нынче фича - vpls требует отдельной лицензии за отдельное бабло :)

Изменено 29 октября, 2012 пользователем sio

[fomka31ru]

ок, уточню.

 

Я не вижу проблемы связать PE h-vpls с двумя разными PE VPLS для redundancy,

если это имелось в виду, но не совсем понимаю для чего делать 2 vc между PE1 и PE2.

 

вот конфиг

 

#show | compare
[edit protocols]
+   l2circuit {
+       neighbor 1.1.1.1 {
+           interface ge-0/0/1.0 {
+               virtual-circuit-id 1110111;
+               backup-neighbor 2.2.2.2 {
+                   virtual-circuit-id 2220222;
+                   standby;
+               }
+           }
+       }
+   }

Изменено 29 октября, 2012 пользователем fomka31ru

[sio]

fomka31ru, видимо мы говорим на разных языках, я привёл 4 причины делать две и более pw с одного PE до vpls на другом PE, я указал пункт в RFC с картинкой в ascii и с описанием этой ситуации - не вижу никаких причин обсуждать далее, почему это не может делать Джунипер и почему при этом *авном оказывается Циска.

Изменено 29 октября, 2012 пользователем sio

[fomka31ru]

По всем вашим доводам (пункты 1,2,3) достаточно одной сессии в пределах одного VPLS домена.

Если же очень захотелось сделать 2 pw в сторону одного PE, welcome

 

# show routing-instances vpls 
instance-type vpls;
protocols {
   vpls {
       mesh-group 1 {
           vpls-id 1110111;
           neighbor 1.1.1.1;
       }
       mesh-group 2 {
           vpls-id 2220222;
           neighbor 1.1.1.1;
       }
   }
}

 

это один из вариантов

[sio]

По всем вашим доводам (пункты 1,2,3) достаточно одной сессии в пределах одного VPLS домена.

Если же очень захотелось сделать 2 pw в сторону одного PE, welcome

 

# show routing-instances vpls 
instance-type vpls;
protocols {
   vpls {
       mesh-group 1 {
           vpls-id 1110111;
           neighbor 1.1.1.1;
       }
       mesh-group 2 {
           vpls-id 2220222;
           neighbor 1.1.1.1;
       }
   }
}

 

это один из вариантов

1. Как подключить две CE с одного PE в vpls на другом PE одной pw без организации vpls на первом PE?

2. Вариант с разными mesh группами не имеет практического применения, т.к. этих групп всего 14-16, или я ошибаюсь?

 

Вы автору темы можете что-нибудь посоветовать?

Мне видится только один вариант - внешняя петля и замена одной цисковской команды страницей джуниперовского конфига.

[fomka31ru]

 

1. Как подключить две CE с одного PE в vpls на другом PE одной pw без организации vpls на первом PE?

2. Вариант с разными mesh группами не имеет практического применения, т.к. этих групп всего 14-16, или я ошибаюсь?

 

Вы автору темы можете что-нибудь посоветовать?

Мне видится только один вариант - внешняя петля и замена одной цисковской команды страницей джуниперовского конфига.

 

Если в случае PE будет выступать Juniper, то этот вариант возможен с использованием bridge-domains. Если что-то другое, то да упираемся в ограничение mesh-group, либо использовать логические туннели.

 

И если мне помнится, то функционал с указанием pw-id на нейбора в vpls появился у циски только на IOS XR (поправьте, если ошибаюсь)