LNS question asr 1002

Take a look on this page (Cisco didn’t update it with new models for a long time ) http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/chassis/asrswcfg/scaling.html

The 1002 is limited to 12K
We didnt test the 1002-x but on a 1004 with ESP-20 and RP2 we cross the 32K L2TP sessions without a problem (48K and even 64K for short time )  but it is not recommended to cross the limits

>
> BTW, any ideas  on the first question? 🙂 that is, realistic numbers
> of active broadband users on a 1002 with a 24K license?
>
> > You may actually want to look at summarizing this. The best practice
> would
> > be to have a per-LNS pool (either locally managed or from RADIUS)
> > and advertise the summary from the LNS up to the network.
> > You may need to redistribute also connected routes for “fixed IP”
> services
> > where a user may have a custom IP from the RADIUS.
> >
> > Not summarizing means that every connection (and disconnection) is a
> > BGP update driving your CPU utilization across the BGP domain…

> >> Secondly, how does one handle running two LNS servers? How does the
> >> border router know which edge (LNS) to forward too for a particular
> >> IP?
> >
> >      I do it with iBGP where my router is advertising individual /32’s.
> > Yes it makes the route tables longer but it works well in my environment.
> > YMMV.

ME3600 config help, Q in Q

Under each Ethernet service instance you can define the following.

1) What frames arriving from the trunk port are to be associated with the particular service instance.
-that is accomplished with the “encapsulation” command.
-in your case “encapsulation dot1q 1048” dictates that service instance 10 will accept only frames with top VLAN tag 1048 followed by any subsequent VLAN tag(s) or data(IP packet).

2) Ingres VLAN tag manipulation removing, adding or translating 1 or 2 topmost tags.
-that is accomplished with the “rewrite” command.
-in your case pop-ing the first/single topmost VLAN tag.

3) Bridging operation aka what to do next with the frame (complete frame i.e. data and possibly adjacent/remaining VLAN tags).
-that is accomplished with the “bridge-domain” command.
– in your case the frame ends within bridge-domain 10.

IP interface for bridge-domain 10 is interface vlan 10.
But as Pshem already mentioned IP operation can be done only on untagged frames.

Though I don’t understand, how the service is supposed to operate, from your other email.
Because if the provider is creating a platform for the hub and spoke setup than they are responsible for pop-ing the top tag 1048.

>
> I am trying to configure an interface on a ME3600 to accept Q in Q
> from a provider. The p-vlan the provider is using is 1048 and they are
> carrying customer vlans (c-vlan) 1058-1098, one from each site. I’m
> new to the 3600 and have not done Q in Q on it yet. I’ve worked up
> this much of the config but it does not seem right. Can anyone give me
> some pointers or links to help me along ? I’ve only got one customer site configed, there will be 14.
>
>
> !
> vlan 1048
>  name WINDSTREAM
> !
> vlan 1058
>  name WINDSTREAM-HOBBS
> !
> interface GigabitEthernet0/6
>  description Windstream VLS IP.LVXX.xxxxxx..WCI.001  port-type nni
> switchport trunk allowed vlan none  switchport mode trunk  service
> instance
> 10 ethernet
>   encapsulation dot1q 1048
>   rewrite ingress tag pop 1 symmetric
>   bridge-domain 10
>  !
> !
> interface Vlan1048
>  description Windstream VLS
>  no ip address
> !
> interface Vlan1058
>  description WINDSTREAM-HOBBS
>  ip address xxx.xx.xx.1 255.255.255.0
>
>
>
> Thanks,
>
> James

ME3600 does not automatically copy DSCP into COS

ME3600 does not automatically copy DSCP into COS and also does not automatically copy EXP into COS T-T

Hi all,

I found the problem my customer’s TOS is rewritten.
Topology:
Tester1 (Send CoS=5) — Gi0/0/1/0 ASR9k 0/0/1/0.3604 — xconnect — Gi0/9 ME-3600X Gi0/24 — Gi0/14 ME-3400 Gi0/5 — Tester2 (rx CoS=0)

I open the TAC both ASR and ME Switch Team and this is the answer from ME Switch Team:

ME3600 does not automatically copy DSCP into COS and also does not automatically copy EXP into COS as described in the following document which was presented on Cisco Live event (page 44 and 45):
http://d2zmdbbm9feqrf.cloudfront.net/2012/usa/pdf/BRKSPG-2209.pdf

Solution:
Please configure policy-map on interfaces to set a proper COS value basing on incoming DSCP.

ASR1000 BGP advertise best-external

>> > Is there any reason why RR running XE can’t advertise best external
>>to its
>> clients? That is nonsense!
>> > Why XR doesn’t have any problems with that?
>> > From a business point of view I understand it very well as you need
>>to buy
>> 4 instead of two routers but otherwise…
>>
>> i don’t use this feature, but the docs say it’s supported on RRs from
>>3.4S.
>>
>> Nick
>>
>Well yes it is but actually only for nonclients as one can’t advertise
>best external to a RR client.
>So if there’s a PE that happens to be a route reflector as well, then
>this feature is useless.
>On XR there’s no such limitation.

A RR needs to advertise the best path to each RR client, that’s its job.
If it should also send the best-external (which would be, by definition,
not the overall best path) to the clients, you need to use add-path as you
need to advertise more than one path. Have you enabled both? can you share
the config?
IIRC this is the same on XR, you also need to enable add-path on the RR..

 

ipv6 RA’s for learning default gateway for end systems (hosts)

> RA’s (router advertisements, aka, icmpv6 type 134)..
>
> Is the receipt of RA’s the only dynamic/automatic way for IPv6 clients to
> learn about their default gateway?
>
> Does DHCPv6 allow for default router option?  What are other ways to get
> default router into a ipv6 cpe ?

Right now, RAs and statically setting the info are the only way to do it.
DHCPv6 does not have a default router option.  Different people will have
different opinions on whether or not this is a fundamental flaw in the
design of DHCPv6.

Strange IOS as DHCP Client behevior

> My problem is that these routers are visible in DHCP binding database with
> very strange MAC:
>
> 10.2.2.140           0063.6973.636f.2d30.    Dec 20 2014 11:44 AM
> Automatic
>                     3035.302e.3536.6138.
>                     2e34.6132.622d.4769.
>                     302f.30
>
> Do you have idea why MAC is so weird ? Rest clients – Eg. Linux or Window
> boxes MACs is displayed correctly.

It’s not a MAC address, it’s a client identifier. And IOS by default
chooses a text string as client identifier. In your case it’s:

“cisco-0050.56a8.4a2b-Gi0/0”

> Anything to configure at Cisco clients to have proper MAC in binding
> database ?

The above example is completely proper. I’m not aware of any method for
making IOS not use a client identifier, but you can change the
identifier it sends via e.g. “ip dhcp client client-id …” interface
command.

 

next-hop-self under address-family vpnv4 also?

next-hop-self under address-family vpnv4 also?

BGP PIC Edge would be recommended but if it is not supported, use different RDs even for the same VPN. This would allow second best path to be installed for the same prefix.

Next-hop-self is enabled automatically under vpnvX AF.
If the code supports it I’d recommend:
address-family vpnv4
bgp advertise-best-external  <– enables best-external + pic(if supported).
no bgp recursion host <–disables recursive lookup for BGP NHs.
bgp nexthop route-map BGP_NHT <–specifies which prefixes qualify as BGP NHs.
bgp nexthop trigger delay 0 <–allows BGP to act on IGP events immediately(enable if FRR backup is available for the BGP NH).
route-map BGP_NHT permit 10
match ip address prefix-list PE_LOOPBACKS
match source-protocol “igp” <–if you are using hierarchical MPLS you need to add BGP there as well.
route-map BGP_NHT permit 20
match source-protocol connected
adam
> —–Original Message—–
> From: cisco-nsp [mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of
> CiscoNSP List
> Sent: Friday, September 19, 2014 3:32 AM
> To: Will Tardy; cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> Subject: Re: [c-nsp] next-hop-self under address-family vpnv4 also?
>
> Cheers.
>
> Any other “tweaks” to default config you recommend?  i.e. timers etc?
>
>
> > From: will.tardy@vocus.com.au<mailto:will.tardy@vocus.com.au>
> > To: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> > Date: Fri, 19 Sep 2014 00:42:23 +0000
> > Subject: Re: [c-nsp] next-hop-self under address-family vpnv4 also?
> >
> > It¹s not needed.
> >
> >
> > “address-family vpnv4” section is used to define which routers
> > participate in the VPNv4.  The underlying MPLS network will forward
> > labels between the
> > VPNv4 end-point CE’s. Next-hop-self isn¹t required. All that¹s
> > required is MPLS and IGP reachability between the CE¹s participating
> > in the vpnv4 domain.
> >
> > On 19/09/2014 10:31 am, “CiscoNSP List” <cisconsp_list@hotmail.com<mailto:cisconsp_list@hotmail.com>>
> wrote:
> >
> > >Is it recommended to add it under vpnv4 also?
> > >
> > >i.e.
> > >
> > >router bgp xxxxxx
> > >…
> > >neighbor iBGP-IPv4-PEERS update-source Loopback0 neighbor
> > >iBGP-IPv4-PEERS next-hop-self neighbor xxx.xxx.xxx.xxx peer-group
> > >iBGP-IPv4-PEERS…
> > >address-family vpnv4
> > >  bgp redistribute-internal
> > >  neighbor  iBGP-IPv4-PEERS send-community extended
> > >  neighbor iBGP-IPv4-PEERS next-hop-self
> > >  neighbor xxx.xxx.xxx.xxx activate
> > >
> > >Cheers.
> > >
> > >
> > >
> > >_______________________________________________
> > >cisco-nsp mailing list  cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> > >https://puck.nether.net/mailman/listinfo/cisco-nsp
> > >archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
> > ________________________________________

 

I-BGP/IGP design case

I-BGP/IGP question

Exactly what Mark said. The only design you’d have an issue with that is if you had routers that do not run BGP. Even then, you could solve that with MPLS ( not necessarily TE, a good old bgp-free core design with LDP would be just fine ) , but that’s really not a use case anymore as pretty much everything can run BGP.

Keep in mind that running BGP and having the full BGP table can be 2 separate things. You generally want all your routing boxes to run BGP, as you’d usually have customer nets and ptp nets ( if you want them ) in it. For everything else, a default ( or multiple defaults, depending on your topology ) should suffice. If you want to be scalable, you’ll design your IGP so that it only carries your loopbacks ( incidentally, those are the only addresses you probably want to label if you’re using LDP ).

Lately, there have been a few designs that offer extreme scalability, based on rfc3107 ( bgp-lu ) , but I’ve yet to hear of anyone actually implementing them . You can find cisco’s flavor here ( http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/116127-configure-technology-00.html ) or a relevant draft here ( https://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-07 )

My thoughts and words are my own.

Kind Regards,

Spyros

—–Original Message—–
From: cisco-nsp [mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of Mark Tinka
Sent: Tuesday, September 16, 2014 9:10 AM
To: cisco-nsp@puck.nether.net
Cc: Wes Smith
Subject: Re: [c-nsp] I-BGP/IGP question

On Tuesday, September 16, 2014 06:55:40 AM Wes Smith wrote:

> I’ve often wondered how large ISPs handle some basic IGP design issues
> re routing between I-BGP nodes in the network. For example ..  assume
> two BGP routers connected over a backbone running some kind of IGP
> I-BGP uses the local IGP to route to other I-BGP nodes within the
> ASThe I-BGP next-hop address is the Egress I-BGP node (normally) or
> the IBPG peer loopbackBest practice says to keep the IGP small, for
> example just the I-BGP loopbacks So a potential routing table entry in
> router
> BGP1 would be something like Rtr BGP1 can reach
> ‘8.8.8.8/32 via 10.10.10.10, where 10.10.10.10 is router BGP-2s
> loopback address and BGP-2 is the egress router So far so good. .. I
> understand all this part.  But my puzzle is .. for this to work, the
> IGP would also need
> to have a route for 8.8.8.8.   so it can route it to my
> other IBGP router at 10.10.10.10But my IGP doesn’t have a route for
> 8.8.8.8 as I don’t redistribute BGP into IGPSo catch-22 . I’ve
> resolved this internally using tunnels between my I-BGP routers and
> using
> next-hop-self. But I’m pretty small scale ..   How do
> larger organisations do it? I’m guessing MPLS TE or other tunnels
> between the POPs .. but would like to hear from some folks that have
> done it.Thanks WS (apologies for any dups..)

First, use NEXT_HOP=self; it’s good practice.

Your iBGP speakers will have 8.8.8.8/32 via 10.10.10.10 as an entry, for example.

Your router will then do a look-up for how to get to 10.10.10.10. It will see that this is known via the IGP (IS- IS, OSPF, Static, e.t.c.), which will have an exit interface (TenGigabitEthernet0/2, for example) toward the next-hop (10.10.10.20, for example).

And so it goes until the packet gets to 10.10.10.10.

It really is that simple.

Mark.

This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Rolaware Hellas SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication.

_______________________________________________
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/

Winfred Hofman <WMCHofman@routit.nl>

Bijlagen16 sep.

aan Winfred
Engels
Nederlands
Bericht vertalen
Uitschakelen voor: Engels

Van: Mark Tinka
Verzonden: ‎16-‎9-‎2014 09:10
Aan: Spyros Kakaroukas
CC: Wes Smith; cisco-nsp@puck.nether.net
Onderwerp: Re: [c-nsp] I-BGP/IGP question

On Tuesday, September 16, 2014 08:48:17 AM Spyros Kakaroukas
wrote:

> Exactly what Mark said. The only design you’d have an
> issue with that is if you had routers that do not run
> BGP. Even then, you could solve that with MPLS ( not
> necessarily TE, a good old bgp-free core design with LDP
> would be just fine ) , but that’s really not a use case
> anymore as pretty much everything can run BGP.

We still run a BGP-free core in our network (for IPv4), even
though the boxes can certainly handle BGP just fine (CRS
with the current generation RP’s).

IPv6 is still carried in the core for now, obviously.

> Lately, there have been a few designs that offer extreme
> scalability, based on rfc3107 ( bgp-lu ) , but I’ve yet
> to hear of anyone actually implementing them . You can
> find cisco’s flavor here (
> http://www.cisco.com/c/en/us/support/docs/multiprotocol-
> label-switching-mpls/mpls/116127-configure-technology-00.
> html ) or a relevant draft here (
> https://tools.ietf.org/html/draft-ietf-mpls-seamless-mpl
> s-07 )

RFC 3107 is certainly a consideration when scaling end-to-
end MPLS backbones, e.g., networks with Metro-E boxes
running IP/MPLS on things such as the ME3600X.

In these cases, BGP-LS could also be interesting.

Time will tell.

Mark.

Winfred Hofman <WMCHofman@routit.nl>

16 sep.

aan ikke
Engels
Nederlands
Bericht vertalen
Uitschakelen voor: Engels
—–Oorspronkelijk bericht—–
Van: cisco-nsp [mailto:cisco-nsp-bounces@puck.nether.net] Namens Nick Hilliard
Verzonden: dinsdag 16 september 2014 10:42
Aan: Rich Lewis; cisco-nsp@puck.nether.net
Onderwerp: Re: [c-nsp] I-BGP/IGP question

On 16/09/2014 09:27, Rich Lewis wrote:
> I know this is good practice, but only because I’ve heard lots of
> (very
> knowledgeable!) people *say* that it’s good practice.

next-hop-self + source-interface lo0 forces the next-hop of the BGP NLRI to be the loopback interface.  This means that:

1. you can fully delegate the business of optimum next-hop lookup to your IGP instead of ibgp.  This is a good deal faster.

2. if there is an intermediate interface flap, ibgp will take ages to route around it and in the interim, routing loops may occur.

3. the bgp best path algorithm uses the igp metric of the bgp next-hop as a tie-breaker, so you get slightly better control of route policy calculation.

iBGP is designed for heavyweight information carrying, not reacting quickly to network topology changes.  Best use an igp and depend on recursive route lookup for that.

Nick

Winfred Hofman <WMCHofman@routit.nl>

16 sep.

aan ikke
Engels
Nederlands
Bericht vertalen
Uitschakelen voor: Engels
—–Oorspronkelijk bericht—–
Van: cisco-nsp [mailto:cisco-nsp-bounces@puck.nether.net] Namens Nick Hilliard
Verzonden: dinsdag 16 september 2014 10:27
Aan: cisco-nsp@puck.nether.net
Onderwerp: Re: [c-nsp] I-BGP/IGP question

On 16/09/2014 05:55, Wes Smith wrote:
> I’ve often wondered how large ISPs handle some basic IGP design issues

Phil Smith’s “BGP for Internet Service Providers” presentation explains a standard approach:

> http://www.menog.org/presentations/menog-2/philip-smith-bgp-techniques
> .pdf

Nick

IPv6; MTU Problem?

> Can you pass me along a traceroute6 to 2a02:26f0:6a:18f::eed and I’ll pass
> it along to the Akamai NOC?
scamper is your friend here:

> cheesecake# scamper -I “trace -P udp -M 2a02:26f0:6a:18f::eed”
> traceroute from 2a03:8900:0:100::5 to 2a02:26f0:6a:18f::eed
>  1  2a03:8900:0:100::1  0.216 ms [mtu: 1500]
>  2  2a02:8900:0:200::209  0.216 ms [mtu: 1500]
>  3  2a01:258:8:3::1  0.634 ms [mtu: 1500]
>  4  2001:1900:5:2:2::2dd9  1.053 ms [mtu: 1500]
>  5  2001:1900:5:1::319  12.990 ms [mtu: 1500]
>  6  2001:1900:5:1::412  12.926 ms [mtu: 1500]
>  7  2001:1900:5:3::21e  11.290 ms [mtu: 1500]
>  8  2001:41a8:600::1e  26.975 ms [mtu: 1500]
>  9  2001:41a8:600:2::b6  27.529 ms [mtu: 1500]
> 10  *
> 11  2a02:26f0:6a::210:d9a3  25.227 ms [mtu: 1500]
> cheesecake#

This means no path mtu problems from as1197 to 2a02:26f0:6a:18f::eed.

Nick

 

IPv6 BGP peer info over SNMP

IPv6 BGP peers over SNMP

On 22/09/14 22:42, chiel wrote:
> So not yet for a 6500 with sup720? I believe 15.1 is the latest on that.

Looks to be the case….

7600 with SUP720 have 15.2, 15.3 & 15.4 releases:

http://software.cisco.com/download/release.html?mdfid=282201754&flowid=61102&softwareid=280805680&release=15.2.4S6&relind=AVAILABLE&rellifecycle=ED&reltype=latest

On 23/09/2014 04:05, Frank Bulk wrote:
> Do you happen to have the OIDs or MIB name for that info?

ftp://ftp.cisco.com/pub/mibs/v2/CISCO-BGP4-MIB.my

1 5 6 7 8