telco group network - data.proidea.org.pl · service signalling – multi-hop e-bgp ! none of g-net...

TELCO GROUP NETWORK Rafał Jan Szarecki 23/10/2011

3 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

G-NET

  Regional (MEA) TELCO has 12 national’s OpCo.

  Build international network infrastructure, to allow all OpCo offer VPNs with sites in multiple OpCo.

§  L3 VPN §  L2 VPN/pseudowires of any L2 type §  For internal services (shared IP, Voice clearing) §  For end-users

  Each OpCo runs own network and is quite autonomous §  ASN §  Independent IGP


GOALS

Redundant Infrastructure ; i.e. No Single Point of Failure (link or node)

OAM capabilities and fault detection

High Availability & Fast Traffic Restoration

Scalable to connect 12 OpCos networks, up to 100 PE's in each.

QoS – for VoIP, Video Conference, Business Critical Services, etc

Leverage existing infrastructure

Ease of Provisioning & Operations


SOME GIVEN CONSTRAINS & CHALLENGES §  Foreseen technology for internal links of Global Network (G-Net) is

SDH & GE §  The use of parallel lower-speed links is expected (e.g. 2 x STM1) in

some cases. §  Foreseen technology for NNI links is

§  GE interfaces §  STM-1/STM-4 PoS §  DS3/E3 interfaces

§  Leverage existing GVPN infrastructure with minimal changes

  Challenges - §  Large scale – 11 OpCo’s (Approx 700 PEs), and even more IP/

MPLS nodes §  OpCO’s network and capabilities are unknown §  End-to-End Service restoration

SOLUTION SELECTION


SOLUTION FOR TRANSIT INFRASTRUCTURE   Inter-AS VPN is a must.

§  Option A – ruled out §  Per-end-use provisioning on

transit network - G-NET §  End-user state on transit

network - G-NET ASBR §  Option B – ruled out

§  End-user state on transit network - G-NET ASBR

§  Not exist for L2vpns §  Option C – selected

§  Trusted peers §  No per VPN/PW provisioning

nor states §  L3VPN, L2VPN and VPLS

G-NET

G-NET TOPOLOGY & ARCHITECTURE


G-NET PROTOCOLS& SIGNALLING   Interfaces:

§  Ethernet II encapsulation only (no VLANs). Auto-negotiation enabled. §  Routers back-to-back dark fibre if both routers in same site. §  Aggregated SDH used when multiple parallel links needed.

  OSPF – Traffic Engineering Extension required to be enabled

  RSVP Full Mesh Between G-NET PE’s Only

(GVPN remains on LDP , Internet traffic is native IP forwarding)

  Fast traffic restoration using Facility Backup

  BGP for transport LSP signaling §  Single MPLS LSP from PE in one OpCo, down to PE (loopback) in other OpCo, via G-NET. §  Used also for VPNv4 routing in GVPN

  Aggregation of Sonet Links between Core Routers is recommended – e.g. AMS & FUJ and LON & FUJ

§  Allows for easier Load Balancing of traffic for RSVP LSP on the international fiber links §  Single Link Failure in the bundle doesn't flap the LSP

  Non Stop Routing

OPCO CONNECTIVITY


TRANSPORT LSP SIGNALING

OpCos_1 G-Net

OpCos_3

OpCos_2ASBR

ASBR

ASBR

ASBR

ASBR

ASBR

ASBR

ASBRASBR

ASBR

PE1

PE

PE

MP-EBGPPE1 lo0.0 w/ label


MP-IBGP


ASBR

This protocol depends on OpCo. It could be: •  LDP •  RSVP •  LDP over RSVP •  iBGP-LU


TRANSPORT LSP - FORWARDING PLANE

OpCos_1 G-Net

OpCos_3

OpCos_2ASBR

ASBR

ASBR

ASBR

ASBR

ASBR

ASBR

ASBRASBR

ASBR

PE1

PE

PE

ASBR

Any PE in Any OpCo, can have LSP to each PE in each OpCo. This is Inter-AS transport LSP. No per Inter-AS LSP provisioning Constrained by MP-eBGP community-based policy.


EBGP LU – EXPORT POLICY   Advertise G-NET ASBRs loopback host routes.

§  From inet.3 – no Internet routers exist there.

§  Only /32 prefixes

  All prefix are advertised with no-export community – avoid leaking from OpCo.

  Advertise other OpCo’s PE prefixes

§  If this prefix is marked by community “To-all-opco”, or

§  If this prefix is marked by community “To-opco-XXX” where XXX is peering OpCo for this session

§  It is responsibility of OpCo, to mark it’s prefixes by communities when advertise it to G-NET.

OPCO_1

GGIPVPN

BGP-LU

BGP-LU

mark by community "To-opco-OPCO_1"OPCO_2

BGP-LU

if community "To-opco-OPCO_1"

then ACCEPTelse reject

if community "To-opco-OPCO_2"

then acceptelse REJECT


SERVICE MODEL – VPN-TRANSPARENT §  G-NET transparent to VPN Provisioning between Opco’s §  Any type of L3VPN and L2VPN is possible form G-NET point of

view §  NNI are MPLS over whatever. VPN traffic in over MPLS when cross NNI §  L2VPN for PPP, ATM, Ethernet, FR are supported – depends only on

OpCo PEs capabilities. §  VPNv4 and VPNv6 are supported - depends only on OpCo PEs

capabilities. §  Any topology of L3VPN and L2VPN is possible form G-NET point

of view §  E.g. Hub-and Spoke with hub on one PE in one OpCo and spokes on

PEs in this OpCo and other OpCo. §  Extranet topologies across OpCo §  Fully controlled by Route Target extended community. Not dependent

on Topology and NNI technical implementation. §  Note: Some limitation exist for UAE OpCo.


SERVICE MODEL

§  G-NET participates in provisioning of NNI only – Transport LSP between OpCos using MP-eBGP (Labeled IPv4 Unicast)

§  G-NET doesn’t carry individual VPN routes (also cannot enforce any per VPN policies.)

§  Multiple QoS classes are available in G-NET §  OpCos responsible for Mapping traffic as per G-NET markings §  No bandwidth control on NNI with OpCos – up to interface speed


THE END-TO-END SERVICE ARCHITECTURE   None of Global Network nodes sees customer information. Good for scaling and T-shooting.

  Only NNI nodes of Global Network sees OpCos global tunnels information. Good for scaling and T-shooting. RFC 3107

  Internal network information's are not visible to peering networks. Global Network do not need to bother with OpCos topology, IGP routing or LDP/RSVP signalling. Good for scaling and T-shooting.


SERVICES ARCHITECTURE – L3VPN   Inter AS VPN – OPTION C (RFC4364)   The G-NET internal LSP signalling using RSVP   Inter-Provider Global Tunnel signalling is E-BGP

§  Labelled IPv4 NLRI (AFI=1 SAFI=4) provides label to PE (IPv4 address) binding. In effect every PE knows label to use to reach every other PE.

§  NNI nodes act as ASBRs §  have to know label binding for proper handling of MPLS traffic on NNI links. §  No need for global eBGP full mesh.

  Service signalling – multi-hop E-BGP §  None of G-NET nodes take a part of this signalling. §  Regular VPNv4 NLRI (AFI=1, SAFI=128), w/ RD and RT communities. Provides

VPN demux label and customer prefixes to stake holders PEs. §  NNI nodes do not participate in this signalling. §  (Option) Route-Target-Filter (AFI=1 SAFI=132). Allows PE to advertise for which

VPNs (RTs) it is configured. This allows to filter out unnecessary VPNv4 prefixes update closer to originator. Automatic routing policy.(RFC4684)

§  Please note that RR inside each of OpCos can (but not must) be used – as usual for BGP routing.


L3VPN SERVICE PROVISIONING

OpCos_1 G-NetOpCos_2

ASBR2.2

ASBR2.1

ASBR3.2

ASBR3.1

ASBR2.4

ASBR2.3

ASBR1.2

ASBR1.1PE1

PE

ASBR

MP-EBGPlabelled IPv4PE1 loop +label C +NH=ASBR2.1

MP-EBGP (w/ no-next-hop change)VPNv4 unicast + label + NH=PE1 loop.

VPN RR

RSVP/LDPPE1 loop

+ label A

MP-EBGPlabelled IPv4PE1 loop +label B +NH=ASBR1.1

MP-EBGPlabelled IPv4PE1 loop +label D +NH=ASBR2.1

MP-EBGPlabelled IPv4PE1 loop +label E +NH=ASBR3.2

RSVP ASBR2.1 loop

MP-IBGPVPNv4 unicast, multicastVPNv6 unicast, multicast

VPN RR

RSVP/LDP ASBR3.1 loop


ASBR2.2

ASBR2.1

ASBR3.2

ASBR3.1

ASBR2.4

ASBR2.3

ASBR1.2

ASBR1.1PE1

PE

ASBR

VPN RR VPN RR

label swapC <-- D

label swapD <-- E

label swapB <-- C

label swapA <-- B

PE2

Not a RR iBGP ó eBGP advertisement works always


SERVICES ARCHITECTURE – L2VPN   Inter AS VPN – OPTION C (RFC4364)   The G-NET internal LSP signalling using RSVP   Inter-Provider Global Tunnel signalling is E-BGP

§  Labelled IPv4 NLRI (AFI=1 SAFI=4) provides label to PE (IPv4 address) binding. In effect every PE knows label to use to reach every other PE.

§  NNI nodes act as ASBRs §  have to know label binding for proper handling of MPLS traffic on NNI links. §  No need for global eBGP full mesh.

  Service signalling – Targeted LDP w/ FEC 128 §  None of G-NET nodes take a part of this signalling. §  Service signalling depends on OpCo who shares given pseudo-wire, and their

PE capabilities. §  T-LDP w/ FEC 128 – most popular, common denominator. Safe choice. §  Other options possible.

§  T-LDP provides VPN (VC) demux label for each pseudo-wire to stake holders PEs.

§  NNI nodes do not participate in this signalling.


OPTION C – L2VPN SERVICE PROVISIONING (USING TARGETED LDP)


ASBR2.2

ASBR2.1

ASBR3.2

ASBR3.1

ASBR2.4

ASBR2.3

ASBR1.2

ASBR1.1PE1

PE

ASBR

MP-EBGPlabelled IPv4PE1 loop +label C +NH=ASBR2.1

RSVP/LDPPE1 loop

+ label A

MP-EBGPlabelled IPv4PE1 loop +label B +NH=ASBR1.1

MP-EBGPlabelled IPv4PE1 loop +label D +NH=ASBR2.1

MP-EBGPlabelled IPv4PE1 loop +label E +NH=ASBR3.2

RSVP ASBR2.1 loop

Targeted LDPFEC 128(L2vpn/VPLS pseudowire + labl + neighbour PE1

RSVP/LDP ASBR3.1 loop


ASBR2.2

ASBR2.1

ASBR3.2

ASBR3.1

ASBR2.4

ASBR2.3

ASBR1.2

ASBR1.1PE1

PE

ASBR

label swapC <-- D

label swapD <-- E

label swapB <-- C

label swapA <-- B

PRE-REQUIREMENTS


PRE-REQUIREMENTS   Autonomous System Numbers of OpCo have to be unique among all OpCos and G-NET.

§  GGIPVP uses public ASN. §  OpCo should use public ASN – guarantee uniqueness today and in future (acquisitions) §  There is possible work-a-round

§  showed later §  Depends on OpCo’s ASBR capabilities

  IP addresses on PE’s and ASBR’s have to be unique among all OpCos and G-NET. §  ASBRs of GGIPVP uses public addresses. §  Use Public address for PE and ASBR loopbacks – guarantee uniqueness today and in future

(acquisitions) §  Other addresses in OpCo network (links, other loopbacks) can be private. §  There is possible work-a-round

§  showed later §  Depends on OpCo’s ASBR capabilities

  All PEs and ASBRs have to support Inter-AS VPN option C. Including but not limited to: §  3-ple label push §  Resolving L3VPN and L2VPN routes NH by labeled BGP routes. §  There is possible work-a-round – the same as for non-unique PE loopback addresses.

LIMITATIONS


LIMITATIONS   VPLS

§  Not a design requirement §  Work with ingress replication of BUM traffic.

§  Bandwidth inefficient. §  Suitable when majority of traffic is unicast.

§  For scaled BUM handling, P2MP LSP needed across AS border.

  Multicast VPN §  Not a Design requirement §  No well established standard for Inter-AS MVPN operation.

§  Draft-rosen do not discuss it. Will be not standardized as RFC. §  Inter-AS NG-MVPN define it. This technology is not established in

industry.


LIVE EXAMPLE DESIGN

  OpCo1 §  OSPF area 0 §  LDP §  LDP to eBGP export §  iBGP full mesh

§  VPNv4 §  IPv4 LU §  RT

§  ASN 100 §  VRF

§  RT 100:1

  OpCo2 §  OSPF area 0 §  RSVP

§  Lo0.0 export to eBGP LU §  iBGP w/ RR


§  ASN 200 §  VRF

§  RT 100:1


LIVE EXAMPLE TOPOLOGY OpCo1ASN: 200loopback: 82.0.0.x/32p2p: 82.x.y.z/30

OpCo3ASN: 300loopback: 83.0.0.x/32p2p: 83.x.y.z/30

GGIPVPNASN: 8888loopback: 188.0.0.x/32p2p: 188.x.y.z/30


O1PE1

O1PE2

O1A3

O1A4

A5

A6

A7

A8

O2A9

O2A10

O2PE11

O2RR12

O3C13 O3C14

br1

br3

br2

br4

br5

br6

br7

br8

br9

br10

br11

br12

br13

br14

br15

br16

br17 br18

br19

em1

em1

em1

em1

em1

em1em1

em1 em1

em1

em1

em1

em1 em1

em3

em3

em3

em3

em3

em3

em3

em3

em3em3

em3

em4

em4

em4

em4

em4

em4

em4

em4

em5

em5 em5

em3 em3

O2A9 loopback: 82.0.0.9O1PE2 loopback: 81.0.0.2O1A3-O1A4: 81.3.4.1-81.3.4.2O2A9-A7: 188.7.9.2-188.7.9.1


CONFIGS   [protocols bgp ] !

  group internal { !

  type internal; !

  local-address 81.0.0.3; !

  family inet { !

  labeled-unicast { !

  rib-group bgp-lu; !

  rib { !

  inet.3; !

  } !

  } !

  } !

  family inet-vpn { !

  any; !

  } !

  multipath; !

  neighbor 81.0.0.1; !

  neighbor 81.0.0.2; !

  neighbor 81.0.0.4; !

  } !

  group external { !

  family inet { !



  rib { !

  inet.3; !

  } !

  } !

  } !

  export LDP; !

  neighbor 188.3.5.2 { !

  peer-as 8888; !

  } !

  } !

  [policy-options policy-statement LDP ] !

  Term PE_lo0 { !

  from protocol ldp; !

  then { !

  community + “To-all-opco”; !

  accept; !

  } !

  } !

  Term this_ASBR_lo0 { !

  from interface lo0.0; !

  then { !


  accept; !

  } !

  } !


CONFIGS   [ protocols bgp] !

  group internal { !



  advertise-inactive; !

  family inet { !



  rib { !

  inet.3; !

  } !

  } !

  } !


  any; !

  } !

  export own-lo0; !

  multipath; !

  neighbor 82.0.0.12; !

  } !

  group external { !

  advertise-inactive; !

  family inet { !



  rib { !

  inet.3; !

  } !

  } !

  } !

  export own-lo0; !

  neighbor 188.8.10.1 { !

  peer-as 8888; !

  } !

  } !

  [policy-options ] !

  policy-statement own-lo0 { !

  term this_node_lo0 { !

  from interface lo0.0; !

  then { !


  accept; !

  } !

  } !

  } !


INSPECTION   root@O1A3# run show route receive-protocol bgp 188.3.5.2 82.0.0.11 detail !

  inet.0: 22 destinations, 28 routes (22 active, 0 holddown, 0 hidden) !

  * 82.0.0.11/32 (2 entries, 1 announced) !

  Accepted !

  Route Label: 300224 !

  Nexthop: 188.3.5.2 !

  AS path: 8888 200 I !


  * 82.0.0.11/32 (2 entries, 1 announced) !

  Accepted !


  Nexthop: 188.3.5.2 !

  AS path: 8888 200 I !


INSPECTION root@O1A3# run show route 82.0.0.11 !


  + = Active Route, - = Last Active, * = Both!

  82.0.0.11/32 *[BGP/170] 00:07:35, localpref 100 !

  AS path: 8888 200 I !

  > to 188.3.5.2 via em1.0, Push 300224 !

  [BGP/170] 00:07:19, localpref 100, from 81.0.0.4 !

  AS path: 8888 200 I !

  > to 81.3.4.2 via em4.0, Push 300192 !



  82.0.0.11/32 *[BGP/170] 00:07:35, localpref 100 !

  AS path: 8888 200 I !

  > to 188.3.5.2 via em1.0, Push 300224 !


  AS path: 8888 200 I !

  > to 81.3.4.2 via em4.0, Push 300192 !


INSPECTION   root@O1PE2# run show route 82.0.0.11 table inet.3 !



  82.0.0.11/32 *[BGP/170] 00:11:02, localpref 100, from 81.0.0.4 !

  AS path: 8888 200 I !

  > to 81.2.4.2 via em3.0, Push 300192 !


  AS path: 8888 200 I !

  > to 81.2.4.2 via em3.0, Push 300272, Push 299808(top) !

  root@O1PE2# run show route table inet.3 !



  [...] !

  81.0.0.3/32 *[LDP/9] 00:31:44, metric 1 !

  > to 81.2.4.2 via em3.0, Push 299808 !


INSPECTON   root@O1PE2# run ping 82.0.0.11 source 81.0.0.2 !

  PING 82.0.0.11 (82.0.0.11): 56 data bytes !

  64 bytes from 82.0.0.11: icmp_seq=0 ttl=59 time=11.552 ms!

  64 bytes from 82.0.0.11: icmp_seq=1 ttl=59 time=7.926 ms !

  root@O1PE2# run traceroute 82.0.0.11 source 81.0.0.2 !

  traceroute to 82.0.0.11 (82.0.0.11) from 81.0.0.2, 30 hops max, 40 byte packets !

  1 81.2.4.2 (81.2.4.2) 7.528 ms 6.272 ms 0.446 ms!

  MPLS Label=300192 CoS=0 TTL=1 S=1 !

  2 188.4.6.2 (188.4.6.2) 1.001 ms 0.421 ms 7.467 ms!


  3 188.6.8.2 (188.6.8.2) 9.169 ms 188.5.6.1 (188.5.6.1) 1.224 ms 188.6.8.2 (188.6.8.2) 14.541 ms!


  4 188.5.7.2 (188.5.7.2) 6.146 ms 188.8.10.2 (188.8.10.2) 4.145 ms 188.5.7.2 (188.5.7.2) 2.760 ms!


  5 82.0.0.11 (82.0.0.11) 7.510 ms 188.7.9.2 (188.7.9.2) 9.148 ms 82.0.0.11 (82.0.0.11) 8.122 ms!



REALITY CHECK

  Unique ASN? NO

  Unique IP on loopbacks? NO

  Option C / RFC3107 / 3-tple push on OpCo’s PE? NO

  And one of OpCo use Kompella, BGP L2VPN J


LIVE EXAMPLE DESIGN – OVERLAPPING AS

  OpCo1 §  OSPF area 0 §  LDP §  LDP to eBGP export §  iBGP full mesh


§  ASN 100 §  VRF

§  RT 100:1

  OpCo2 §  OSPF area 0 §  RSVP

§  Lo0.0 export to eBGP LU §  iBGP w/ RR


§  ASN 100 §  VRF

§  RT 100:1


THE OVERLAPPING AS PROBLEM   ASBR “sh route protocol bgp”

§  Missing OpCo root@O1PE1# run show route 82/8 !![edit] !root@O1A3# run show route 82/8 !![edit] !root@O2RR12# run show route 81/8 !![edit] !!

§  But exist on G-NET ASBRs root@A8# ...show route 81/6 table inet.3 terse | match "inet.3|A Des|\*" !!inet.3: 20 destinations, 29 routes (20 active, 0 holddown, 0 hidden) !+ = Active Route, - = Last Active, * = Both !A Destination P Prf Metric 1 Metric 2 Next hop AS path !* 81.0.0.1/32 B 170 100 1 188.7.8.1 100 I !* 81.0.0.2/32 B 170 100 1 188.7.8.1 100 I !* 81.0.0.3/32 B 170 100 >188.7.8.1 100 I !* 81.0.0.4/32 B 170 100 >188.7.8.1 100 I !* 82.0.0.9/32 B 170 100 >188.8.10.2 100 I !* 82.0.0.10/32 B 170 100 >188.8.10.2 100 I !* 82.0.0.11/32 B 170 100 >188.8.10.2 100 I !

* 82.0.0.12/32 B 170 100 >188.8.10.2 100 I !!root@A8# run show route advertising-protocol bgp 188.8.10.2 !!inet.3: 20 destinations, 29 routes (20 active, 0 holddown, 0 hidden) ! Prefix Nexthop MED Lclpref AS path !* 188.0.0.5/32 Self 250 I !* 188.0.0.6/32 Self 250 I !* 188.0.0.7/32 Self 250 I !* 188.0.0.8/32 Self I !!


THE OVERLAPPING ASN SOLUTION (1)

  In BGP ASN is used in 3 places §  In BGP OPEN message. Each ASBR compares ASN received from

given peer in OPEN message, with ASN locally configured for this peer. If not match, session will not be established.

§  In AS PATH attribute. When ASBR advertise prefix by eBGP, it prepends own ASN to string of ASN on AS PATH attribute.

§  Each BGP speaker compare ASN on as-path of reciver NLRI with own AS. If find match, NLRI is considered looped back, and dropped.

  JUNOS has “local-as autonomous-system <loops number> <private | alias> no-prepend-global-as” knob. Use it on OpCo ASBR on MP-eBGP session.

§  Change ASN in OPEN message to unique local one. §  Control inclusion/exclusion of global/local ASNs in AS Path.



AS 100 AS 100 AS 8888

PE1 Lo0: a.a.a.a

Local-as 200

NLRI for IP b.b.b.b/32 discarded due to as

loop 1st AS on as-path ==

own global AS

PE40 Lo0: b.b.b.b/32

NLRI for IP a.a.a.a/32 discarded due to as

loop last AS on as-path ==

own global AS

IP: a.a.a.a/32 Label: 123456 As-path 100$

IP: b.b.b.b/32 Label: 123456 As-path 200 100$


INSPECTION   root@O2A9# run show route 81/8 hidden detail table inet.3 !


  81.0.0.1/32 (1 entry, 0 announced) !

  BGP !

  Next hop type: Router !

  Next-hop reference count: 2 !

  Source: 188.7.9.1 !

  Next hop: 188.7.9.1 via em1.0, selected !

  Label operation: Push 301248 !

  State: <Hidden Ext> !

  Local AS: 100 Peer AS: 8888 !

  Age: 40 !

  Task: BGP_8888_200.188.7.9.1+60934 !

  AS path: 8888 100 I (Looped: 100) !


  Router ID: 188.0.0.7 !

  Secondary Tables: inet.0 !

  root@A5# run show route advertising-protocol bgp 188.3.5.1 82/8 !


  Prefix Nexthop MED Lclpref AS path !

  * 82.0.0.9/32 Self 200 I !

  * 82.0.0.10/32 Self 200 I !

  * 82.0.0.11/32 Self 200 100 I !

  * 82.0.0.12/32 Self 200 100 I !

  root@O1A3# run show route protocol bgp 82/8 terse table inet.3 !


  + = Active Route, - = Last Active, * = Both !

  A Destination P Prf Metric 1 Metric 2 Next hop AS path !

  * 82.0.0.9/32 B 170 100 >188.3.5.2 8888 200 I !

  * 82.0.0.10/32 B 170 100 >188.3.5.2 8888 200 I !

Missing 2 prefixes was silently discarded due to AS loop

All OpCo1 prefixes was hidden due to AS loop



AS 100 AS 100 AS 8888

PE1 Lo0: a.a.a.a

Local-as 200 alias

accepted


NLRI for IP a.a.a.a/32 discarded due to as

loop last AS on as-path ==

own global AS


IP: b.b.b.b/32 Label: 123456 As-path 200 $


INSPECTION   root@O1PE1# run show route protocol bgp 82/8 terse table inet.3 !


  + = Active Route, - = Last Active, * = Both !


  * 82.0.0.9/32 B 170 100 >81.1.3.2 8888 200 I !

  B 170 100 81.1.2.2 8888 200 I !

  >81.1.3.2 !

  * 82.0.0.10/32 B 170 100 >81.1.3.2 8888 200 I !

  B 170 100 81.1.2.2 8888 200 I !

  >81.1.3.2 !

  * 82.0.0.11/32 B 170 100 >81.1.3.2 8888 200 I !

  B 170 100 81.1.2.2 8888 200 I !

  >81.1.3.2 !

  * 82.0.0.12/32 B 170 100

>81.1.3.2 8888 200 I !

  B 170 100 81.1.2.2 8888 200 I !

  >81.1.3.2 !

root@A8# run show route advertising-protocol bgp 188.8.10.2 81/8 !

inet.3: 20 destinations, 29 routes (20 active, 0 holddown, 0 hidden) !

Prefix Nexthop MED Lclpref AS path !

* 81.0.0.1/32 Self 100 I !

* 81.0.0.2/32 Self 100 I !

* 81.0.0.3/32 Self 100 I !

* 81.0.0.4/32 Self 100 I !

!

root@O2A10# run show route table inet.3 81/8 !

!

[edit] !Missing 2 prefixes was silently discarded due to AS loop



AS 100 AS 100 AS 8888

PE1 Lo0: a.a.a.a

Local-as 200 alias

accepted




Local-as 400 alias

accepted


CONFIGURATION   root@O1PE1# show routing-options autonomous-system !

  100; !

  root@O1PE1# show protocols bgp group internal !



  family inet { !


  [...] !

  } !

  } !

  } !


  any; !

  } !

  multipath; !

  neighbor 81.0.0.2; !

  neighbor 81.0.0.3; !

  neighbor 81.0.0.4; !

  root@O1A3# show routing-options autonomous-system !

  100; !

  root@O1A3# show protocols bgp group external !

  family inet { !


  [...] !

  } !

  } !

  export LDP; !

  neighbor 188.3.5.2 { !

  peer-as 8888; !

  local-as 400 alias; !

  } !


INSPECTION   root@O2A10# run show route table inet.3 81/8 terse !




  * 81.0.0.1/32 B 170 100 >188.8.10.1 8888 400 I !

  B 170 100 >82.9.10.1 8888 400 I !

  * 81.0.0.2/32 B 170 100 >188.8.10.1 8888 400 I !

  B 170 100 >82.9.10.1 8888 400 I !

  * 81.0.0.3/32 B 170 100 >188.8.10.1 8888 400 I !

  B 170 100 >82.9.10.1 8888 400 I !

  * 81.0.0.4/32 B 170 100 >188.8.10.1 8888 400 I !

  B 170 100 >82.9.10.1 8888 400 I !

  root@O2PE11# run show route table inet.3 81/8 terse !




  * 81.0.0.1/32 B 170 100 >82.9.11.1 8888 400 I !

  * 81.0.0.2/32 B 170 100 >82.9.11.1 8888 400 I !

  * 81.0.0.3/32 B 170 100 >82.9.11.1 8888 400 I !

  * 81.0.0.4/32 B 170 100 >82.9.11.1 8888 400 I !


INSPECTION   root@O1PE1# run ping 82.0.0.11 source 81.0.0.1 count 3 !   PING 82.0.0.11 (82.0.0.11): 56 data bytes !   64 bytes from 82.0.0.11: icmp_seq=0 ttl=60 time=1.318 ms !



  --- 82.0.0.11 ping statistics --- !   3 packets transmitted, 3 packets received, 0% packet loss !

  round-trip min/avg/max/stddev = 0.900/1.087/1.318/0.173 ms !


THE OVERLAPPING IP PROBLEM   Let assume ASBR of OPCO 2 learns same prefix (81.0.0.1) form:

§  IGP/LDP in own AS 100 §  MP-EBGP LU from G-NET. The as-path is 8888 400

  It selects IGP as best route.   The O1PE1 in OpCo 1 is not reachable from OpCo2.

root@O2A9# run show route 81.0.0.1 table inet.3 !!inet.3: 19 destinations, 23 routes (19 active, 0 holddown, 0 hidden) !+ = Active Route, - = Last Active, * = Both !!81.0.0.1/32 *[LDP/9] 00:00:28, metric 1 ! > to 82.9.11.2 via em4.0 ! [BGP/170] 00:00:23, localpref 100, from 82.0.0.12 ! AS path: I ! > to 82.9.11.2 via em4.0 !!root@O1A4# run show route 81.0.0.1 table inet.3 !!inet.3: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) !+ = Active Route, - = Last Active, * = Both !!81.0.0.1/32 *[LDP/9] 00:41:19, metric 1 ! > to 81.2.4.1 via em3.0, Push 299776 ! to 81.3.4.1 via em4.0, Push 299824 !

!root@A8# run show route 81.0.0.1 terse table inet.3 !!inet.3: 19 destinations, 29 routes (19 active, 0 holddown, 0 hidden) !+ = Active Route, - = Last Active, * = Both !!A Destination P Prf Metric 1 Metric 2

" Next hop AS path !* 81.0.0.1/32 B 170 100

" " >188.8.10.2 200 I ! B 170 100

" " >188.7.8.1 200 I !

" " 188.6.8.1 ! B 170 100 1

" " >188.7.8.1 400 I !

" " 188.6.8.1 ! B 170 100 1

" " >188.7.8.1 400 I !

" " 188.6.8.1 !!


THE OVERLAPPING IP SOLUTION (1)   Re-addressing is ultimate way but …

§  Make OpCo ASBR aware about VPN LSP, and force them to switch traffic base on.

§  Do not advertise PE’s loopback (because of overlapping)

AS 100 AS 100 AS 8888

PE1 Lo0: a.a.a.a

IP: b.b.b.b/32 Label: 123456 As-path 400$

PE40 Lo0: a.a.a.a

Local-as 400 alias

ASBR1 Lo0: b.b.b.b

VPNv4: v.v..v.v/32 NH: c.c.c.c Label: 128356 As-path 400 $

VPNv4: v.v.v.v/32 NH: b.b.b.b Label: 97456 As-path 400 $

ß VPNv4: v.v..v.v/32 NH: a.a.a.a

ASBR5 Lo0: c.c.c.c

VPNv4: v.v..v.v/32 NH: a.a.a.a Label: 128356 As-path I $

Local-as 200 alias

Local-as 200 alias

Local-as 400 alias


OVERLAPING AS AND IP LIVE PRESENTATION OpCo1ASN: 100loopback: 81.0.0.x/32p2p: 81.x.y.z/30


GGIPVPNASN: 8888loopback: 188.0.0.x/32p2p: 188.x.y.z/30


O1PE1

O1PE2

O1A3

O1A4

A5

A6

A7

A8

O2A9

O2A10

O2PE11

O2RR12

O3C13 O3C14

br1

br3

br2

br4

br5

br6

br7

br8

br9

br10

br11

br12

br13

br14

br15

br16

br17 br18

br19

em1

em1

em1

em1

em1

em1em1

em1 em1

em1

em1

em1

em1 em1

em3

em3

em3

em3

em3

em3

em3

em3

em3em3

em3

em4

em4

em4

em4

em4

em4

em4

em4

em5

em5 em5

em3 em3


INSPECTION   root@O1PE1# ping 200.11.11.11 source 100.1.1.1 count 3 routing-instance test-vpn!

  PING 200.11.11.11 (200.11.11.11): 56 data bytes !   64 bytes from 200.11.11.11: icmp_seq=0 ttl=64 time=0.857 ms!



  --- 200.11.11.11 ping statistics --- !   3 packets transmitted, 3 packets received, 0% packet loss !


THE OVERLAPPING IP SOLUTION (2)   Re-addressing is ultimate way but …   Make OpCo ASBR aware about pseudo-wire LSP, and force them to switch traffic base on it.

  Local PW stitching is not defined by standard – platform dependent.

AS 100 AS 100 AS 8888

PE1 Lo0: a.a.a.a


PE40 Lo0: a.a.a.a

Local PW xconnect/

stitch

ASBR1 Lo0: b.b.b.b

T-LDP ASBR5-PE40 FEC128: 15643

T-LDP ASBR1-ASBR5 FEC128: 42945

ASBR5 Lo0: c.c.c.c

T-LDP PE1-ASBR1 FEC128: 12345


THE OVERLAPPING IP SOLUTION (3)

  Only IP of loopback of OpCo ASBR (b.b.b.b), used for multihop VPN MP-eBGP session has to be unique across OpCos.

  The ASBR must handle multihop MP-eBGP session for VPNv4/6.

  The ASBR must preform NHS policy on MP-iBGP session for VPNv4/6.

  Note. PE do not need to support Inter-As option C at all.

  Note II. Special care need to be given for RD if they are based on IPv4 (or auto-RD). Overlaping IP may lead to assigning same RD value to different VPNs by different OpCo. If customer IP address space also overlap, there is risk of dropping prefix of one of VPNs. This is because VPNv4 addresses may happen to be equal in both VPNs.

telco group network - data.proidea.org.pl · service signalling – multi-hop e-bgp ! none of g-net...

Documents