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

l2 vfi на juniper meshgroup?

Есть такой 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?

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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.

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

Edited by fomka31ru

Share this post


Link to post
Share on other sites

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

 

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;
}
}

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

Добрый день,

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Edited by fomka31ru

Share this post


Link to post
Share on other sites

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

Номер rfc?

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Номер rfc?

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

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

 

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

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

 

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

Edited by fomka31ru

Share this post


Link to post
Share on other sites

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

Номер rfc?

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

 

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

Edited by sio

Share this post


Link to post
Share on other sites

ок, уточню.

 

Я не вижу проблемы связать 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;
+               }
+           }
+       }
+   }

Edited by fomka31ru

Share this post


Link to post
Share on other sites

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

Edited by sio

Share this post


Link to post
Share on other sites

По всем вашим доводам (пункты 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;
       }
   }
}

 

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

Share this post


Link to post
Share on other sites

По всем вашим доводам (пункты 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, или я ошибаюсь?

 

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

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

Share this post


Link to post
Share on other sites

 

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

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

 

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

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

 

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

 

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

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