[c-nsp] OSPF+BGP and MPLS Q's

[r***@mail.com]

Hi all,

I have some practical design questions.

1. Is there a better way of doing the HA than having adjacencies to the router (can be 3 hops away) over two different VLANs and different OSPF cost over trunk links with BFD enabled?
2. Do you find less practical a MPLS network on a multi-area design vs a single-area design?
4. At what point would you introduce RouteReflectors in the network (e.g. when 5, 10, 20 IBGP connections?)

Can come up with some more in the meantime ;)

Thanks!
Ton
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Mark Tinka]

Post by r***@mail.com
1. Is there a better way of doing the HA than having adjacencies to the router (can be 3 hops away) over two different VLANs and different OSPF cost over trunk links with BFD enabled?

I'd say don't run core links in VLAN's.

What adjacencies are you referring to, IGP?

Post by r***@mail.com
2. Do you find less practical a MPLS network on a multi-area design vs a single-area design?

We use IS-IS in a single level (L2-only). This would be the same as Area
0 in OSPF.

My understanding is that a single Area 0 for OSPFv3 should scale as well
as L2-only in IS-IS. But I don't know many folk that run both IPv4 and
IPv6 in a single OSPFv3 deployment (even though it can be done).

Post by r***@mail.com
4. At what point would you introduce RouteReflectors in the network (e.g. when 5, 10, 20 IBGP connections?)

Day 1, regardless of number of routers. Because, you will grow...

Mark.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Aaron Gould]

If you think your network is going to continue to grow , dual route reflector cluster is a huge must have in my mind, I love how you can add address families to one neighbor and let it bounce while the other neighbor stays up with all your routes still there

I have ran a 100 node single area OSPF (area 0.0.0.1) MPLS/LDP network for several years, I believe simplicity and only as much complexity as is required for the job


Aaron

Post by r***@mail.com
Hi all,
I have some practical design questions.
1. Is there a better way of doing the HA than having adjacencies to the router (can be 3 hops away) over two different VLANs and different OSPF cost over trunk links with BFD enabled?
2. Do you find less practical a MPLS network on a multi-area design vs a single-area design?
4. At what point would you introduce RouteReflectors in the network (e.g. when 5, 10, 20 IBGP connections?)
Can come up with some more in the meantime ;)
Thanks!
Ton
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Nick Cutting]

Quick question as I am clueless on large SP networks (I'm a MSP guy not an ISP guy )- why not area 0.0.0.0 ?


-----Original Message-----
From: cisco-nsp <cisco-nsp-***@puck.nether.net> On Behalf Of Aaron Gould
Sent: Thursday, July 19, 2018 6:08 PM
To: ***@mail.com
Cc: cisco-***@puck.nether.net
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's

This message originates from outside of your organisation.

If you think your network is going to continue to grow , dual route reflector cluster is a huge must have in my mind, I love how you can add address families to one neighbor and let it bounce while the other neighbor stays up with all your routes still there

I have ran a 100 node single area OSPF (area 0.0.0.1) MPLS/LDP network for several years, I believe simplicity and only as much complexity as is required for the job


Aaron

Post by r***@mail.com
Hi all,
I have some practical design questions.
1. Is there a better way of doing the HA than having adjacencies to the router (can be 3 hops away) over two different VLANs and different OSPF cost over trunk links with BFD enabled?
2. Do you find less practical a MPLS network on a multi-area design vs a single-area design?
4. At what point would you introduce RouteReflectors in the network
(e.g. when 5, 10, 20 IBGP connections?)
Can come up with some more in the meantime ;)
Thanks!
Ton
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Aaron Gould]

I was waiting for that, lol

Sort of a long story, as everyone knows, networks usually have a story to tell in order to understand why they are the way they are.... If many of us sat back and designed a new network from the ground up, it would be pretty for a day or two, and then eventually grow into something else .... If you leave the company and a new guy comes in, he would probably say , "what idiot designed this network " :/

.... Then when he left the company, someone else would come in and say the same thing about him, lol

originally I did have a backbone area 0 and a very small MPLS network with core IGP area 1, ...well, area 1 continued to grow, and area 0 was eventually decommissioned, and know area 1 remains :)

....I guess I could work through maintenance windows and convert everything to area 0, but I don't feel motivated to do so

Works fine

Aaron

Post by Nick Cutting
Quick question as I am clueless on large SP networks (I'm a MSP guy not an ISP guy )- why not area 0.0.0.0 ?
-----Original Message-----
Sent: Thursday, July 19, 2018 6:08 PM
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's
This message originates from outside of your organisation.
If you think your network is going to continue to grow , dual route reflector cluster is a huge must have in my mind, I love how you can add address families to one neighbor and let it bounce while the other neighbor stays up with all your routes still there
I have ran a 100 node single area OSPF (area 0.0.0.1) MPLS/LDP network for several years, I believe simplicity and only as much complexity as is required for the job
Aaron

Post by r***@mail.com
Hi all,
I have some practical design questions.
1. Is there a better way of doing the HA than having adjacencies to the router (can be 3 hops away) over two different VLANs and different OSPF cost over trunk links with BFD enabled?
2. Do you find less practical a MPLS network on a multi-area design vs a single-area design?
4. At what point would you introduce RouteReflectors in the network
(e.g. when 5, 10, 20 IBGP connections?)
Can come up with some more in the meantime ;)
Thanks!
Ton
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[r***@mail.com]

Anyone else can give an opinion to those three questions?

Thanks.
T.

Sent: Friday, July 20, 2018 at 12:43 AM
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's
I was waiting for that, lol
Sort of a long story, as everyone knows, networks usually have a story to tell in order to understand why they are the way they are.... If many of us sat back and designed a new network from the ground up, it would be pretty for a day or two, and then eventually grow into something else .... If you leave the company and a new guy comes in, he would probably say , "what idiot designed this network " :/
.... Then when he left the company, someone else would come in and say the same thing about him, lol
originally I did have a backbone area 0 and a very small MPLS network with core IGP area 1, ...well, area 1 continued to grow, and area 0 was eventually decommissioned, and know area 1 remains :)
....I guess I could work through maintenance windows and convert everything to area 0, but I don't feel motivated to do so
Works fine
Aaron

Post by Nick Cutting
Quick question as I am clueless on large SP networks (I'm a MSP guy not an ISP guy )- why not area 0.0.0.0 ?
-----Original Message-----
Sent: Thursday, July 19, 2018 6:08 PM
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's
This message originates from outside of your organisation.
If you think your network is going to continue to grow , dual route reflector cluster is a huge must have in my mind, I love how you can add address families to one neighbor and let it bounce while the other neighbor stays up with all your routes still there
I have ran a 100 node single area OSPF (area 0.0.0.1) MPLS/LDP network for several years, I believe simplicity and only as much complexity as is required for the job
Aaron

Post by r***@mail.com
Hi all,
I have some practical design questions.
1. Is there a better way of doing the HA than having adjacencies to the router (can be 3 hops away) over two different VLANs and different OSPF cost over trunk links with BFD enabled?
2. Do you find less practical a MPLS network on a multi-area design vs a single-area design?
4. At what point would you introduce RouteReflectors in the network
(e.g. when 5, 10, 20 IBGP connections?)
Can come up with some more in the meantime ;)
Thanks!
Ton
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Peter Rathlev]

Post by r***@mail.com
Anyone else can give an opinion to those three questions?

Opinions are easy to give. :-) Authority is a different question
altogether. I spend my daytime in a place that started with just 6 PE
routers and has slowly grown to 51 over ~13-15 years. Still not a big
number, but I have been a part of it all the time and have learned some
things the hard way.

We're an closed ("enterprise") IS-IS-based MPLS L3VPN network so things
might not translate directly. We only have IGP links and loopbacks in
IS-IS, just above 200 routes in the global table currently. We around
7000 prefixes in BGP.

I'm also not sure I understand the first question. BFD is a way to
overcome certain failure scenarios if you need to use some kind of L2
transport between the routers. But the better way, since you ask, is to
have two or more physically direct and diverse L3 links between the
routers.

We have always been single area. Our small size considered this will
most likely never be a problem. If the size of your network is within
an order of a magnitude of ours I see no reason at all to introducing
the complexity of multi-area.

We started the network without route reflectors. When we grew to more
than 20 PE routers we configured three existing PEs as RRs. This was a
bit more complex than we wanted, so we eventually started using two
Cisco 2901 as RRs. They have been with us since and are not breaking a
sweat handling the ~7000 networks and ~17000 paths we have in BGP.

Having RRs really simplifies deploying new PEs. Big networks probably
have even the deployment of new PEs fully automated, but would then
choose RRs for scalability reasons.

If I were to start over I would implement RRs from the very start.

We use unique (type 1) RDs per PE and thus have all PEs see paths from
all other PEs, not just the "best" path, giving us quick failover.

[Mark Tinka]

Post by Peter Rathlev
I'm also not sure I understand the first question. BFD is a way to
overcome certain failure scenarios if you need to use some kind of L2
transport between the routers. But the better way, since you ask, is to
have two or more physically direct and diverse L3 links between the
routers.

For backbone links, I'd stay away from VLAN's, especially if those
VLAN's are used to handle multiple physical paths over one physical port.

This is one area where you want to spend money and make sure each link
sits on its own port. You can reduce costs by having those ports on one
line card, but that's as far as I'd take the concession.

Also, there used to be some strangeness with running MPLS and other
features on VLAN's. I'm not sure if those issues still exist, but if I
were you, I'd rather not find out.

Post by Peter Rathlev
We have always been single area. Our small size considered this will
most likely never be a problem. If the size of your network is within
an order of a magnitude of ours I see no reason at all to introducing
the complexity of multi-area.

Agreed.

IS-IS and OSPFv3 should scale to thousands of routers. Your biggest
limitations are going to be whether you decide to split your IGP into
domains because some of your devices have a small FIB (think ASR920's
with 20,000 supported entries, e.t.c.). But this will depend on how many
devices you have. Your planning should be around your the size of the
"FIB-weakest" devices you operate.

Those using OSPFv2 with thousands of routers should advise their experience.

Post by Peter Rathlev
We started the network without route reflectors. When we grew to more
than 20 PE routers we configured three existing PEs as RRs. This was a
bit more complex than we wanted, so we eventually started using two
Cisco 2901 as RRs. They have been with us since and are not breaking a
sweat handling the ~7000 networks and ~17000 paths we have in BGP.
Having RRs really simplifies deploying new PEs. Big networks probably
have even the deployment of new PEs fully automated, but would then
choose RRs for scalability reasons.
If I were to start over I would implement RRs from the very start.

Sage advice, like I also suggested before - do it right now, don't wait
for things to grow... they will.

Your decision here should be whether you want in-path or out-of-path
RR's. If you're doing MPLS, and for simplicity, I'd say go for
out-of-path RR's.

If you choose to go for out-of-path RR's, then you give yourself a lot
of options re: the type of kit you can use, namely, x86 servers running
a VM that is hosting a production-grade software version of a
traditional router, e.g., CSR1000v or xRV (Cisco), vRR (Juniper) or
VSR-RR (Nokia, formerly ALU).

Post by Peter Rathlev
We use unique (type 1) RDs per PE and thus have all PEs see paths from
all other PEs, not just the "best" path, giving us quick failover.

I don't do Internet in a VRF, but it's quite a popular architecture for
several operators on this and other mailing lists.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[r***@mail.com]

Hi Mark,

Would like to get back to this with some more questions.

1. Imagine a ring topology with core switches each sw connected with dual 10G links thus Port channel for increased capacity. The redundancy is achieved from OSPF adjacency over two different VLANs with BFD enabled (first vlan going clock wise and second vlan anti clockwise traversing the trunk links). 

Would be interested to know your thought on preparing this type of config for MPLS. Convert the trunk links into L3 links? If yes, what about other VLANs (customer vlans) traversing the trunks?


What for considering whether a device can be in backbone area 0 or not? Because some are not and for simplicity I want to consider having all in area 0.

Thanks!
Ton

Sent: Monday, July 23, 2018 at 6:28 PM
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's

Post by Peter Rathlev
I'm also not sure I understand the first question. BFD is a way to
overcome certain failure scenarios if you need to use some kind of L2
transport between the routers. But the better way, since you ask, is to
have two or more physically direct and diverse L3 links between the
routers.

For backbone links, I'd stay away from VLAN's, especially if those
VLAN's are used to handle multiple physical paths over one physical port.
This is one area where you want to spend money and make sure each link
sits on its own port. You can reduce costs by having those ports on one
line card, but that's as far as I'd take the concession.
Also, there used to be some strangeness with running MPLS and other
features on VLAN's. I'm not sure if those issues still exist, but if I
were you, I'd rather not find out.

Post by Peter Rathlev
We have always been single area. Our small size considered this will
most likely never be a problem. If the size of your network is within
an order of a magnitude of ours I see no reason at all to introducing
the complexity of multi-area.

Agreed.
IS-IS and OSPFv3 should scale to thousands of routers. Your biggest
limitations are going to be whether you decide to split your IGP into
domains because some of your devices have a small FIB (think ASR920's
with 20,000 supported entries, e.t.c.). But this will depend on how many
devices you have. Your planning should be around your the size of the
"FIB-weakest" devices you operate.
Those using OSPFv2 with thousands of routers should advise their experience.

Post by Peter Rathlev
We started the network without route reflectors. When we grew to more
than 20 PE routers we configured three existing PEs as RRs. This was a
bit more complex than we wanted, so we eventually started using two
Cisco 2901 as RRs. They have been with us since and are not breaking a
sweat handling the ~7000 networks and ~17000 paths we have in BGP.
Having RRs really simplifies deploying new PEs. Big networks probably
have even the deployment of new PEs fully automated, but would then
choose RRs for scalability reasons.
If I were to start over I would implement RRs from the very start.

Sage advice, like I also suggested before - do it right now, don't wait
for things to grow... they will.
Your decision here should be whether you want in-path or out-of-path
RR's. If you're doing MPLS, and for simplicity, I'd say go for
out-of-path RR's.
If you choose to go for out-of-path RR's, then you give yourself a lot
of options re: the type of kit you can use, namely, x86 servers running
a VM that is hosting a production-grade software version of a
traditional router, e.g., CSR1000v or xRV (Cisco), vRR (Juniper) or
VSR-RR (Nokia, formerly ALU).

Post by Peter Rathlev
We use unique (type 1) RDs per PE and thus have all PEs see paths from
all other PEs, not just the "best" path, giving us quick failover.

I don't do Internet in a VRF, but it's quite a popular architecture for
several operators on this and other mailing lists.
Mark.

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermai

[r***@mail.com]

Bump. Anyone?

Sent: Friday, August 31, 2018 at 10:47 PM
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's
Hi Mark,
Would like to get back to this with some more questions.
1. Imagine a ring topology with core switches each sw connected with dual 10G links thus Port channel for increased capacity. The redundancy is achieved from OSPF adjacency over two different VLANs with BFD enabled (first vlan going clock wise and second vlan anti clockwise traversing the trunk links). 
Would be interested to know your thought on preparing this type of config for MPLS. Convert the trunk links into L3 links? If yes, what about other VLANs (customer vlans) traversing the trunks?
What for considering whether a device can be in backbone area 0 or not? Because some are not and for simplicity I want to consider having all in area 0.
Thanks!
Ton

Sent: Monday, July 23, 2018 at 6:28 PM
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's

Post by Peter Rathlev
I'm also not sure I understand the first question. BFD is a way to
overcome certain failure scenarios if you need to use some kind of L2
transport between the routers. But the better way, since you ask, is to
have two or more physically direct and diverse L3 links between the
routers.

For backbone links, I'd stay away from VLAN's, especially if those
VLAN's are used to handle multiple physical paths over one physical port.
This is one area where you want to spend money and make sure each link
sits on its own port. You can reduce costs by having those ports on one
line card, but that's as far as I'd take the concession.
Also, there used to be some strangeness with running MPLS and other
features on VLAN's. I'm not sure if those issues still exist, but if I
were you, I'd rather not find out.

Post by Peter Rathlev
We have always been single area. Our small size considered this will
most likely never be a problem. If the size of your network is within
an order of a magnitude of ours I see no reason at all to introducing
the complexity of multi-area.

Agreed.
IS-IS and OSPFv3 should scale to thousands of routers. Your biggest
limitations are going to be whether you decide to split your IGP into
domains because some of your devices have a small FIB (think ASR920's
with 20,000 supported entries, e.t.c.). But this will depend on how many
devices you have. Your planning should be around your the size of the
"FIB-weakest" devices you operate.
Those using OSPFv2 with thousands of routers should advise their experience.

Post by Peter Rathlev
We started the network without route reflectors. When we grew to more
than 20 PE routers we configured three existing PEs as RRs. This was a
bit more complex than we wanted, so we eventually started using two
Cisco 2901 as RRs. They have been with us since and are not breaking a
sweat handling the ~7000 networks and ~17000 paths we have in BGP.
Having RRs really simplifies deploying new PEs. Big networks probably
have even the deployment of new PEs fully automated, but would then
choose RRs for scalability reasons.
If I were to start over I would implement RRs from the very start.

Sage advice, like I also suggested before - do it right now, don't wait
for things to grow... they will.
Your decision here should be whether you want in-path or out-of-path
RR's. If you're doing MPLS, and for simplicity, I'd say go for
out-of-path RR's.
If you choose to go for out-of-path RR's, then you give yourself a lot
of options re: the type of kit you can use, namely, x86 servers running
a VM that is hosting a production-grade software version of a
traditional router, e.g., CSR1000v or xRV (Cisco), vRR (Juniper) or
VSR-RR (Nokia, formerly ALU).

Post by Peter Rathlev
We use unique (type 1) RDs per PE and thus have all PEs see paths from
all other PEs, not just the "best" path, giving us quick failover.

I don't do Internet in a VRF, but it's quite a popular architecture for
several operators on this and other mailing lists.
Mark.

_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
arc

[Mark Tinka]

Do your devices support IP/MPLS?

Mark.

Post by r***@mail.com
Bump. Anyone?

Sent: Friday, August 31, 2018 at 10:47 PM
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's
Hi Mark,
Would like to get back to this with some more questions.
1. Imagine a ring topology with core switches each sw connected with dual 10G links thus Port channel for increased capacity. The redundancy is achieved from OSPF adjacency over two different VLANs with BFD enabled (first vlan going clock wise and second vlan anti clockwise traversing the trunk links). 
Would be interested to know your thought on preparing this type of config for MPLS. Convert the trunk links into L3 links? If yes, what about other VLANs (customer vlans) traversing the trunks?
What for considering whether a device can be in backbone area 0 or not? Because some are not and for simplicity I want to consider having all in area 0.
Thanks!
Ton

Sent: Monday, July 23, 2018 at 6:28 PM
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's

Post by Peter Rathlev
I'm also not sure I understand the first question. BFD is a way to
overcome certain failure scenarios if you need to use some kind of L2
transport between the routers. But the better way, since you ask, is to
have two or more physically direct and diverse L3 links between the
routers.

For backbone links, I'd stay away from VLAN's, especially if those
VLAN's are used to handle multiple physical paths over one physical port.
This is one area where you want to spend money and make sure each link
sits on its own port. You can reduce costs by having those ports on one
line card, but that's as far as I'd take the concession.
Also, there used to be some strangeness with running MPLS and other
features on VLAN's. I'm not sure if those issues still exist, but if I
were you, I'd rather not find out.

Post by Peter Rathlev
We have always been single area. Our small size considered this will
most likely never be a problem. If the size of your network is within
an order of a magnitude of ours I see no reason at all to introducing
the complexity of multi-area.

Agreed.
IS-IS and OSPFv3 should scale to thousands of routers. Your biggest
limitations are going to be whether you decide to split your IGP into
domains because some of your devices have a small FIB (think ASR920's
with 20,000 supported entries, e.t.c.). But this will depend on how many
devices you have. Your planning should be around your the size of the
"FIB-weakest" devices you operate.
Those using OSPFv2 with thousands of routers should advise their experience.

Post by Peter Rathlev
We started the network without route reflectors. When we grew to more
than 20 PE routers we configured three existing PEs as RRs. This was a
bit more complex than we wanted, so we eventually started using two
Cisco 2901 as RRs. They have been with us since and are not breaking a
sweat handling the ~7000 networks and ~17000 paths we have in BGP.
Having RRs really simplifies deploying new PEs. Big networks probably
have even the deployment of new PEs fully automated, but would then
choose RRs for scalability reasons.
If I were to start over I would implement RRs from the very start.

Sage advice, like I also suggested before - do it right now, don't wait
for things to grow... they will.
Your decision here should be whether you want in-path or out-of-path
RR's. If you're doing MPLS, and for simplicity, I'd say go for
out-of-path RR's.
If you choose to go for out-of-path RR's, then you give yourself a lot
of options re: the type of kit you can use, namely, x86 servers running
a VM that is hosting a production-grade software version of a
traditional router, e.g., CSR1000v or xRV (Cisco), vRR (Juniper) or
VSR-RR (Nokia, formerly ALU).

Post by Peter Rathlev
We use unique (type 1) RDs per PE and thus have all PEs see paths from
all other PEs, not just the "best" path, giving us quick failover.

I don't do Internet in a VRF, but it's quite a popular architecture for
several operators on this and other mailing lists.
Mark.

_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/

[a***@netconsultings.com]

Peter Rathlev
Sent: Monday, July 23, 2018 3:42 PM

Post by r***@mail.com
Anyone else can give an opinion to those three questions?

Opinions are easy to give. :-) Authority is a different question

altogether. I

spend my daytime in a place that started with just 6 PE routers and has

slowly

grown to 51 over ~13-15 years. Still not a big number, but I have been a

part

of it all the time and have learned some things the hard way.
We're an closed ("enterprise") IS-IS-based MPLS L3VPN network so things
might not translate directly. We only have IGP links and loopbacks in

IS-IS,

just above 200 routes in the global table currently. We around
7000 prefixes in BGP.
I'm also not sure I understand the first question. BFD is a way to

overcome

certain failure scenarios if you need to use some kind of L2 transport
between the routers. But the better way, since you ask, is to have two or
more physically direct and diverse L3 links between the routers.
We have always been single area. Our small size considered this will most
likely never be a problem. If the size of your network is within an order

of a

magnitude of ours I see no reason at all to introducing the complexity of
multi-area.
We started the network without route reflectors. When we grew to more
than 20 PE routers we configured three existing PEs as RRs. This was a bit
more complex than we wanted, so we eventually started using two Cisco
2901 as RRs. They have been with us since and are not breaking a sweat
handling the ~7000 networks and ~17000 paths we have in BGP.
Having RRs really simplifies deploying new PEs. Big networks probably have
even the deployment of new PEs fully automated, but would then choose
RRs for scalability reasons.
If I were to start over I would implement RRs from the very start.
We use unique (type 1) RDs per PE and thus have all PEs see paths from all
other PEs, not just the "best" path, giving us quick failover.

This topic of RRs is actually very interesting,
At first networks where meant to be very decentralized to sustain attacks,
and the pendulum keeps on swinging back and forth on the
centralize/decentralize front -while the RR thing seems to be stable through
that.
I guess one of the reasons is that using the RRs gives the control of the
scalability and robustness "sliders" of the solution to the operator.
(in other words the scalability and robustness is agnostic to each other or
to the number of the BGP speakers in the network giving us the best possible
versatility)

1a) You can increase robustness by using different RRs for different
prefix-groups (or AFs) - the more the better robustness (and as a side
effect the solution will scale better).
1b) you can have 1 (non-resilient) or two and more RRs per prefix-group.
2) And also for any of the AFs or prefix-groups you can have different
slices or "Planes" each carrying a subset of prefixes thus increasing the
scalability of the solution.
3) If number of sessions per RR is a problem you can add more RRs per
AF-group (or per AF-group slice) each terminating just a subset of all BGP
sessions
-then you end up with separate infrastructures of RR per 1b) or per 2).

Each of these you can scale in or out independently depending on your
requirements.

Although I'd suggest you want to have 1a to at least divide Public Internet
prefixes and your internal VPN prefixes.
The 1b) is a given for anyone who's using RRs even if they are using just a
single prefix-group (i.e. at least 2 RRs for the whole network)


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[a***@netconsultings.com]

Hi see inline,

Sent: Thursday, July 19, 2018 8:32 PM
Hi all,
I have some practical design questions.
1. Is there a better way of doing the HA than having adjacencies to the

router

(can be 3 hops away) over two different VLANs and different OSPF cost over
trunk links with BFD enabled?

I'm not sure I understand the question,
But if you plan on doing:
PE1--PE2--PE3
PE1-vlan100-PE2-vlan200-PE3
PE1----------vlan300--------PE3
This will not increase the resilience of the setup.
As the two paths between PE1 and PE3 will share the same shared resource
groups (SRG) so if one path fails both paths will fail in fact.

2. Do you find less practical a MPLS network on a multi-area design vs a
single-area design?

Starting at single area everywhere is always more practical, (you can
monitor ospf statistics SPF calculations in particular from time to time to
see if it's too much for the OSPF to handle).
Depending on the platform OSPF will scale to 100s of thousands of routes
just fine.
(beyond 1M -I'm not sure if that request was fulfilled back in the days or
even whether the implementation was made available publically, but other
things like multi-area interfaces did, anyways might be a fun test to do
actually, anyone?).

4. At what point would you introduce RouteReflectors in the network (e.g.
when 5, 10, 20 IBGP connections?)

Well if you plan on having the whole core provisioning fully automated (e.g.
adding new bgp speaker or routing policy and monitoring) then that doesn't
matter - though the complexity doesn't disappear it's just moved to another
domain.
With full mesh you'll get all paths visible by all BGP speakers natively
(might or might not be welcome), but there are ways of accomplishing that
even if RRs are used instead of full-mesh (wit e.g. Type-1 RDs in VPNv4/6
AFs and Add-Path in IPv4/6 AFs) -but again, complexity doesn't disappear
it's just moved to another domain.
Another decision factor worth considering with every new design is where
would you fall in terms of the overall deployments types graph, and I'd say
most of the folks here would *cluster around the RRs deployment, so there's
a lot more knowledge (and bug fixes) around how to handle that type of
complexity in the community in comparison with the camp around full-mesh
iBGP (or fully automated iBGP deployments for that matter).

*pun unintended
I imagine this multidimensional graph (# of dimensions = config
parameters/features we consider), where regions around MP-BGP with VPNv4 and
OSPF and RRs would be relatively denser and clumped together in comparison
to say regions around MP-BGP with Multicast and EIGRP and full-mesh, I think
of google's zero-shot translation (interlingua graph).

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Netravnen]

Hi ringbit,

Post by r***@mail.com
1. Is there a better way of doing the HA than having adjacencies to the router (can be 3 hops away) over two different VLANs and different OSPF cost over trunk links with BFD enabled?

Minimized usage of VLAN's in the core is my recommendation. And only
VLAN's at edge ports.
For the HA part. Having OSPF with ECMP would be my solution. Maybe
doing the metric setting for links manually for all core ports with
OSPF enabled to stricly control chosen paths.

Post by r***@mail.com
4. At what point would you introduce RouteReflectors in the network (e.g. when 5, 10, 20 IBGP connections?)

Will depend on you network topology.
https://packetpushers.net/bgp-rr-design-part-1/
If you asked me. I would start as soon as I reach ~5 devices running
BGP with different sizes of BGP feeds (some running fullfeed, other
only running partial feed). Doing filtering on RRs is easier done than
doing filtering on _every_ bgp enabled device doing it.

/Netravnen
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Mark Tinka]

Post by Netravnen
Minimized usage of VLAN's in the core is my recommendation. And only
VLAN's at edge ports.
For the HA part. Having OSPF with ECMP would be my solution. Maybe
doing the metric setting for links manually for all core ports with
OSPF enabled to stricly control chosen paths.

The OP never replied to my query, but my suggestion would be that if the
kit supports IP/MPLS, let the OP just run that on the core-facing links,
and not fiddle about with VLAN's and that...

Mark.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Ring Bit]

Hi Mark,

Tried to DM you but didn't work. Can you DM?

Ty!
Ton

Sent: Wednesday, September 12, 2018 at 2:29 PM
Subject: Re: [c-nsp] OSPF+BGP and MPLS Q's

Post by Netravnen
Minimized usage of VLAN's in the core is my recommendation. And only
VLAN's at edge ports.
For the HA part. Having OSPF with ECMP would be my solution. Maybe
doing the metric setting for links manually for all core ports with
OSPF enabled to stricly control chosen paths.

The OP never replied to my query, but my suggestion would be that if the
kit supports IP/MPLS, let the OP just run that on the core-facing links,
and not fiddle about with VLAN's and that...
Mark.

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/