Re: [c-nsp] OSPF routing question

2018-07-17 Thread Erik Sundberg 
Lee,


Change the Floating static route to an administrative distance of 254, so it is 
higher than OSPF.


router static
 address-family ipv4 unicast
 45.x.x.0/22 Null0 254


When the route is learned via OSPF it will have a metric of 110 and the ospf 
route will be installed into the routing table.

When the route is not learned via OSPF the floating static router on your Edge 
router will be active. This will still allow BGP to advertise the route.



Also, if you don't want to advertise the floating static route to other devices 
in your network you can do the following.

Add the tag 1 on the static route will stop it from being redistributed in your 
network.


router static
 address-family ipv4 unicast
 45.x.x.0/22 Null0 254 tag 1


router ospf 1
 log adjacency changes
 redistribute static route-policy IPV4-OSPF-REDIST-STATIC


route-policy IPV4-OSPF-REDIST-STATIC
  if tag eq 1 then
drop
  endif
  done

If a static route has the tag of 1 it will not be redistributed into OSPF, so 
the rest of the network will not learn about the route.


-

Side note, most ISP's will only advertise there Loopback and Core "Circuits" 
IPs in there IGP.  They will run iBGP between all of the there devices and 
allow BGP to redistribute the static and connected interfaces. BGP is also 
easier to manipulate routes on your network. Send me an email if you would like 
to know more.

Here is an old but still very relevant power point on this.

https://www.pacnog.org/pacnog2/track2/routing/a3-1up.pdf
3 - OSPF for ISPs - 
PacNOG
www.pacnog.org
© 2005 Cisco Systems, Inc. All rights reserved. 1 Session Number 
Presentation_ID Cisco Confidential Deploying OSPF for ISPs ISP/IXP Workshops














From: cisco-nsp  on behalf of Lee Starnes 

Sent: Tuesday, July 17, 2018 4:17:25 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] OSPF routing question

Hello everyone,

I have a question about OSPF route redistribution. We have no issues
redistributing subnets in the network out of our /19 blocks. But we have a
/22 block that the entire /22 is allocated to a single client. The routes
redistribute across all the all switches except back to the edge routers
that announce them via BGP to our upstream carriers. This being because
there are holdown routes for the BGP on this of the same size IP block. Is
there a way to allow the /22 block to propagate to the edge routers and
still maintain the hold down routes we need to announce that /22 via BGP to
our various upstream carriers?

Edge routers are configured as such:

router static
 address-family ipv4 unicast
 45.x.x.0/22 Null0 19

router bgp ASNUMBER
address-family ipv4 unicast
network 45.x.x.0/22


router ospf NUMBER
 log adjacency changes
 redistribute connected
 redistribute static
 area W.X.Y.Z
  !
  interface TenGigE0/3/0/0
   passive disable
  !
  interface TenGigE0/3/3/0
   passive disable
  !


Any ideas are greatly appreciated.

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



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner. Thank 
you.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] router suggestion for backup link

2018-07-17 Thread Łukasz Bromirski 
Gert,

> On 14 Jul 2018, at 08:25, Gert Doering  wrote:
> 
> This very much depends on what this box needs to do, except "2.5 Gbit".
> 
> ISR44xx ends at 2 Gbit/s for the 4451, so it's not interesting anyway.

ISRs can get ‘performance’ or ‘boost’ license, with which the internal
shaper “goes to eleven” (with ‘performance’) license and is turned off
completely (with ‘boost’). You can’t run VMs on ISR 4k’s anymore
with those, but the performance goes way above 2.5Gbit/s required.

The latest slide decks on ciscolive.com  should have it 
as this slide
was presented on the ISR architecture session, however all I can
get now fast is this small screenshot from German blog:
https://alln-extcloud-storage.cisco.com/gblogs/sites/48/Bildschirmfoto-2018-02-11-um-14.45.48-500x284.png

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] OSPF routing question

2018-07-17 Thread Lee Starnes 
Hello everyone,

I have a question about OSPF route redistribution. We have no issues
redistributing subnets in the network out of our /19 blocks. But we have a
/22 block that the entire /22 is allocated to a single client. The routes
redistribute across all the all switches except back to the edge routers
that announce them via BGP to our upstream carriers. This being because
there are holdown routes for the BGP on this of the same size IP block. Is
there a way to allow the /22 block to propagate to the edge routers and
still maintain the hold down routes we need to announce that /22 via BGP to
our various upstream carriers?

Edge routers are configured as such:

router static
 address-family ipv4 unicast
 45.x.x.0/22 Null0 19

router bgp ASNUMBER
address-family ipv4 unicast
network 45.x.x.0/22


router ospf NUMBER
 log adjacency changes
 redistribute connected
 redistribute static
 area W.X.Y.Z
  !
  interface TenGigE0/3/0/0
   passive disable
  !
  interface TenGigE0/3/3/0
   passive disable
  !


Any ideas are greatly appreciated.

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

Re: [c-nsp] EVPN Book/paper recommendation

2018-07-17 Thread Kasper Adel 
Copying Kenneth.

On Tue, Jul 17, 2018 at 11:47 AM, Kasper Adel  wrote:

> Saucy question indeed!
>
> Good stuff here : https://www.reddit.com/r/netwo
> rking/comments/3fulng/vxlan_vs_vpls/ and https://blog.ipspace.net/2018/
> 02/evpn-with-mpls-data-plane-in-data.html
>
> Also https://plus.google.com/+KennethDuda/posts/2tnVCHkeVyZ
>
> Good question,
> Kim
>
> On Sun, Jul 15, 2018 at 2:10 AM,  wrote:
>
>> > Pete Lumbis
>> > Sent: Saturday, July 14, 2018 8:41 PM
>> >
>> > Dinesh Dutt, the co-author of VxLAN wrote two books you can get for
>> free*
>> > They are both focused on the datacenter, but the principals are the same
>> for
>> > both DC and non-DC use cases.
>> >
>> > BGP in the datacenter: http://cumulusnetworks.com/bgp EVPN in the
>> > datacenter:
>> > https://cumulusnetworks.com/lp/evpn-data-center-
>> > oreilly/?utm_source=social+media_term=EVPN_campaign=2018
>> > +EVPN+in+the+data+center+eBook
>> >
>> > * Behind a regwall. Disclaimer: I work for Cumulus
>> >
>> //rant//
>> I'd love to ask Dinesh why VXLAN???
>> -I mean what was wrong with MPLS labels for these DC folks?
>> If you think about it VXLAN is like VPN label directly on top of IP (just
>> a
>> tenant separator).
>> But there's no concept of stacking VXLAN headers unlike in MPLS, -that is
>> no
>> extensibility for other applications (e.g. TE = source routing = service
>> chaining, or other example would be micro services = VPNs),
>> The EVPN CP for VXLAN is just another patch borrowed from SP folks, they
>> still need ACLs for micro services and god knows what they will come up
>> with
>> for service chaining (PBR I guess) both utterly un-scalable solutions.
>> Looks like DC folks have the tendency of reinventing the wheel again and
>> again.
>> All of these DC "solutions" could have been solved by simple well
>> established MPLS:  FabricPath, TRILL, LISP, VXLAN, NVGRE, OTV and Shortest
>> Path Bridging (SPB).
>> Not mentioning all the crazy complexity where all these need to interface
>> with MPLS backbone at the DC boundaries (while preventing L2 loops).
>>
>> Finally with the latest generation of nexus switches they seem to finally
>> realize that MPLS is the path.
>> //rant//
>>
>> adam
>>
>> netconsultings.com
>> ::carrier-class solutions for the telecommunications industry::
>>
>> ___
>> cisco-nsp mailing list  cisco-nsp@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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] EVPN Book/paper recommendation

2018-07-17 Thread Kasper Adel 
Saucy question indeed!

Good stuff here : https://www.reddit.com/r/networking/comments/3fulng/
vxlan_vs_vpls/ and https://blog.ipspace.net/2018/
02/evpn-with-mpls-data-plane-in-data.html

Also https://plus.google.com/+KennethDuda/posts/2tnVCHkeVyZ

Good question,
Kim

On Sun, Jul 15, 2018 at 2:10 AM,  wrote:

> > Pete Lumbis
> > Sent: Saturday, July 14, 2018 8:41 PM
> >
> > Dinesh Dutt, the co-author of VxLAN wrote two books you can get for free*
> > They are both focused on the datacenter, but the principals are the same
> for
> > both DC and non-DC use cases.
> >
> > BGP in the datacenter: http://cumulusnetworks.com/bgp EVPN in the
> > datacenter:
> > https://cumulusnetworks.com/lp/evpn-data-center-
> > oreilly/?utm_source=social+media_term=EVPN_campaign=2018
> > +EVPN+in+the+data+center+eBook
> >
> > * Behind a regwall. Disclaimer: I work for Cumulus
> >
> //rant//
> I'd love to ask Dinesh why VXLAN???
> -I mean what was wrong with MPLS labels for these DC folks?
> If you think about it VXLAN is like VPN label directly on top of IP (just a
> tenant separator).
> But there's no concept of stacking VXLAN headers unlike in MPLS, -that is
> no
> extensibility for other applications (e.g. TE = source routing = service
> chaining, or other example would be micro services = VPNs),
> The EVPN CP for VXLAN is just another patch borrowed from SP folks, they
> still need ACLs for micro services and god knows what they will come up
> with
> for service chaining (PBR I guess) both utterly un-scalable solutions.
> Looks like DC folks have the tendency of reinventing the wheel again and
> again.
> All of these DC "solutions" could have been solved by simple well
> established MPLS:  FabricPath, TRILL, LISP, VXLAN, NVGRE, OTV and Shortest
> Path Bridging (SPB).
> Not mentioning all the crazy complexity where all these need to interface
> with MPLS backbone at the DC boundaries (while preventing L2 loops).
>
> Finally with the latest generation of nexus switches they seem to finally
> realize that MPLS is the path.
> //rant//
>
> adam
>
> netconsultings.com
> ::carrier-class solutions for the telecommunications industry::
>
> ___
> cisco-nsp mailing list  cisco-nsp@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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/