ASR9000 VPNv4 prefix limits

I'm seeing an odd issue that cropped up during testing of a new network. I was asked to inject at least 300K routes into a L3VPN instance configured across a new MPLS core of ASR9006 and 9001 routers.
I had a router that can inject some 425K routes, so used that as my source.
I have ebgp between ISP route injection and CE router.
Ebgp between CE router and PE at edge of L3VPN.
i see the 425K routes on the ISP, CE and PE. Looking at show bgp vpnv4 unicast summary shows 425K+ routes.
But, across the `other side' of the L3VPN on another PE-CE connection into that L3VPN I only see exactly 207000 routes, with show bgp vpnv4 unicast summary. And if I look on the the CE router there I see the same, 207000 routes.
I see there is a maximum-prefix command, with different defaults dpending on the address family, but non at 207000. Also I've not configured any aggregate addressing.
It looks like the L3VPN is droppong excess routes, but I've played around with the maximum prefix value, seems to have no effect on my network.
The other point, the core is using a pair of route reflectors, if that makes any difference to this.
Anyone seen this before, any ideas?
Code is 4.3.0 on all ASR's.

Similar Messages

View vpnv4 prefix and ip prefix

Hi there,
Normally, we use the command such as "sh ip bgp vpnv4 all" "sh ip route vrf" and etc to determine the prefix path.May I know what command in cisco devices that actually reflect vpnv4 prefix and IP prefix? Sound like a stupid question but I just want to confirm.
Thanks in advance.
maher

You are right about the command
show ip bgp vpnv4 ip-prefix
For more information on how the Routes are distinguished and the use of BGP extended communities (route targets)
Check the below URL (scroll down to the image 7-4 VPN-IP Address Format for a graphic explanation)
http://www.cisco.com/en/US/products/sw/ps2346/ps99/products_configuration_guide_chapter09186a00800ee111.html
an example
Router# show ip bgp vpnv4 all 10.22.22.0
BGP routing table entry for 10:1:22.22.22.0/24, version 19
Paths:(5 available, best #5)
Multipath:eiBGP
Advertised to non peer-group peers:
10.0.0.2 10.0.0.3 10.0.0.4 10.0.0.5
22
10.0.0.2 (metric 20) from 10.0.0.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
Extended Community:0x0:0:0 RT:100:1 0x0:0:0
Originator:10.0.0.2, Cluster list:10.0.0.4

Combining PE-CE eBGP VPNv4 prefix exchange with mVPN?

Background:
Present MPLS backbone based on 3750ME and 6504/Sup32 to all main locations.
Rigid (and stable) structure at each site with C - CE - PE, eBGP pr. VRF between CE and PE, static/HSRP between C and CE.
C typically 6500/Sup720, CE either 3560(G) or 3750(G).
Only backside to present design is that connectivity between to CEs at a site is via L2 in Cs, that is CE - C - C - CE.
That has provided some interesting failure scenarios :(.
Static configuration with many configuration steps for new networks also provides possible errors.
We're looking at removing the CE and combine the C/CE functionality into the 6500/Sup720 on each campus.
Then we can either run traditional eBGP pr. VRF between C/CE and PE or we could move to a solution with PE-CE eBGP VPNv4 prefix exchange, such as would be used when service providers exchange label info across AS boundaries.
The latter solution means all PEs will accept all VPNv4 routes rather than just the ones for which they have locally defined VRFs.
But it also provides flexibility combined with ease of the configuration, as the PEs are basically reduced to P functionality, and at the same time the usage of eBGP between C/CE and PE means we don't have to include the C/CEs in the IGP (IS-IS) of the backbone and convert them to full PEs, compromising the stability of the MPLS core, while maintaining all the control handles of BGP.
The C/CEs would need to BGP peer with the PEs in the global routing table for exchange of VPNv4 routes and next hop information.
Does this sound like a feasible solution? Caveats?
Next issue at hand is mVPN.
We'd like to support pr. VRF multicast across the MPLS backbone, and mVPN seems like the answer to that. Unfortunately it's not supported now nor will it apparently be so on the 3750ME.
The obvious answer is to move to e.g. 7604 as PE platform, which is a long term strategic option, but it's not gonna happen overnight.
Assuming we implement the PE-CE eBGP VPNv4 route exchange, would we be able to switch the mVPN functionality into the C/CE routers, this taking away the restraints of the 3750MEs?
We would run pr. VRF PIM on the C/CE and define default- and data-MDTs for each VRF on the C/CE.
Obviously we would need multicast routing in the global routing table, both on the PEs (based on PIM-SM, Bidir or SSM), and between the C/CEs and the PEs (based on PIM or perhaps MP-BGP?).
Would this work? Caveats?

Hi elawaetz
From the above I come to know that for the first solution actually you should go with the vrf lite, if you want to club your customers on 6500. For PE-CE a bgp instance is required and it will work only for vpnv4 not in global and its a feasible solution you can go with this.
Solution For MVPN:-
For MVPN you need not worry about the clinet end. You have to take care for the folowing points for mvpn:-
a) Use ip pim-spare-mode for your backhaul, so hat in case of rp failures your clients will not be affected.
b)Choose a suitable multicast protocol like autorp if you are having full cisco domain or BSR for mix breed.
c)If you r using auto-rp advertise your rp information with the help of acl which includes the 239 group becasue by default it takes 224 group.
d)For your cloud default mdt is required (unique for per vrf)and it is only in the global multicast routing table.
e)Data mdt can be used but its an optioal component.
f)Per vrf rp should be required.
g)MP-BGP update should be with one loopback only, if u r having multiple loopbacks for bgp peering then rpf failures problems will arise and you wonot be able to send or receive the streams.
h)3750is specially deisgned for ME; By defaut cisco switches forward the multicast traffic but if u want ot create the vrf then u need a router and 7600 is gud one becasue with this you can go with extranet also.
You last point i already cleared, in global multicast routing table only default mdt groups will be enterted.
regards
shivlu

Vpnv4 prefix dynamic update on export-map changes

Hi guys,
I have a 76k running 12.2(33)SRE9a with this vrf configuration:
ip vrf B
rd 2:2
export map RM-R3
route-target import 2:2
route-map RM-R3 permit 10
match ip address prefix-list PL-R3
set extcommunity rt 4:4 2:2 additive
route-map RM-R3 permit 15
set extcommunity rt 2:2
ip prefix-list PL-R3 seq 5 permit 172.3.3.3/32
ip prefix-list PL-R3 seq 10 permit 172.33.33.33/32
So I expect that prefixes matching prefix-list PR-R3 will have route-target 2:2 4:4, and all other prefixes will have route-target 2:2.
The question is: What happens if I remove this line of the prefix list?
no ip prefix-list PL-R3 seq 10 permit 172.33.33.33/32
Will there be any dynamic update? Do I have to clear bgp or ip routing table?
Thanks!
Diego.

Hi Diego,
I checked in IOU with SRE9a image and observed that there is no dynamic update and we need to do "clear ip bgp <as> soft out from CE side.
Topology
R1--ebgp--[vrf CUST-A] R3----vpnv4 ibgp -----R4
ip vrf CUST-A
rd 300:1
export map RM-R3
route-target export 300:1
route-target import 300:1
R3#show route-map RM-R3
route-map RM-R3, permit, sequence 10
Match clauses:
ip address prefix-lists: PL-R3
Set clauses:
extended community RT:300:1 RT:300:2 additive
Policy routing matches: 0 packets, 0 bytes
route-map RM-R3, permit, sequence 15
Match clauses:
Set clauses:
extended community RT:300:2
Policy routing matches: 0 packets, 0 bytes
R3#show ip prefix PL-R3
ip prefix-list PL-R3: 1 entries
seq 5 permit 172.16.17.0/24
seq 10 permit 172.16.19.0/24
R3#
R4#show ip b vpnv4 all 172.16.19.0/24
BGP routing table entry for 300:1:172.16.19.0/24, version 34
Paths: (1 available, best #1, table CUST-A)
Not advertised to any peer
100
3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:300:1 RT:300:2
mpls labels in/out nolabel/36
R4#
R3(config)#no ip prefix-list PL-R3 seq 10 permit 172.16.19.0/24
R3(config)#end
after 10 min
R4#show ip b vpnv4 all 172.16.19.0/24
BGP routing table entry for 300:1:172.16.19.0/24, version 34
Paths: (1 available, best #1, table CUST-A)
Not advertised to any peer
100
3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:300:1 RT:300:2
mpls labels in/out nolabel/36
R4#
R1#clear ip bgp 300 soft out
R1#
R4#show ip b vpnv4 all 172.16.19.0/24
BGP routing table entry for 300:1:172.16.19.0/24, version 50
Paths: (1 available, best #1, table CUST-A)
Not advertised to any peer
100
3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:300:2
mpls labels in/out nolabel/36
R4#
I hope it helps

Route Target Quantity limitation

anyone know how many(quantity) different RT's you can import into 1 central VRF. What the limitation is?

Hi,
import can be "any number", I myself tried more than 500 in a lab environment with no problem. RT export is different in that you may only have up to 128 extended communities in a single BGP update and additionally a maximum BGP update size of 4096 Bytes exists. Whichever limit you hit first will prevent you from announcing a VPNv4 prefix.
Hope this helps! Please rate all posts.
Regards, Martin

Maximum LSP on Inter-AS vpnv4/ipv4

Hi Luc
Thank you for your reply, in fact we are in the process of using Option B (ASBR-to-ASBR). We have all the configs in place just did not activate the neighbors pending confirmation. We are using Eng5; I would expect CAM/TFIB to be able to hold these prefixes, I seem to have noticed that the weakest processor can handle up to one million. Yet, it is not written anywhere on these specifics.
Thanks
FR

Hi Fernando,
In MPLS VPN networks, 17000 vpnv4 prefixes is not that much. You can have hundreds of thousand of vpnv4 prefixes.
You did not specifiy which option A,B, C or D you are running. For option A and D, the scalability could become an issue because you'll have many logical links between the ASBRs, one for every VPN shared between the 2 autonomous systems. This is a known limitation factor in these two designs and it is a pain to operate such a model, starting from a certain scale. Each new VPN shared between the 2 autonomous systems will lead to the creation of a new logical link on the ASBRs.
Option B and C do not have this and are hence more scalable and easier to maintain operationally. What inter-as MPLS VPN brings is the concentration of the LSPs on the ASBRs, instead of having them spread over many PE and P routers in a non-inter-as MPLS VPN network. But, 17000 prefixes should be ok on a 12k router.
Thanks,
Luc

Issue with multipath load-sharing of VPNv4 routes

Hi Sir,
Below is output of "show ip bgp vpnv4 all 10.1.36.0/24" on a PE router in an MPLS VPN environment:
KP1#sh ip bgp vpnv4 all 10.1.36.0/24
BGP routing table entry for 65001:202:10.1.36.0/24, version 1732
Paths: (2 available, best #1, no table)
Not advertised to any peer
Local
172.18.254.56 (metric 31) from 172.18.254.54 (172.18.254.54)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1200
Originator: 172.18.254.56, Cluster list: 172.18.254.54
Local
172.18.254.56 (metric 31) from 172.18.255.254 (172.18.255.254)
Origin incomplete, metric 0, localpref 100, valid, internal
Extended Community: RT:65001:1200
Originator: 172.18.254.56, Cluster list: 172.18.255.254
BGP routing table entry for 65001:203:10.1.36.0/24, version 2439
Paths: (2 available, best #2, no table)
Not advertised to any peer
Local
172.18.255.4 (metric 21) from 172.18.255.254 (172.18.255.254)
Origin incomplete, metric 0, localpref 100, valid, internal
Extended Community: RT:65001:1200
Originator: 172.18.255.4, Cluster list: 172.18.255.254
Local
172.18.255.4 (metric 21) from 172.18.254.54 (172.18.254.54)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1200
Originator: 172.18.255.4, Cluster list: 172.18.254.54
BGP routing table entry for 65001:204:10.1.36.0/24, version 2441
Paths: (2 available, best #2, table V1:TEST)
Multipath: iBGP
Not advertised to any peer
Local, imported path from 65001:202:10.1.36.0/24
172.18.254.56 (metric 31) from 172.18.254.54 (172.18.254.54)
Origin incomplete, metric 0, localpref 100, valid, internal
Extended Community: RT:65001:1200
Originator: 172.18.254.56, Cluster list: 172.18.254.54
Local, imported path from 65001:203:10.1.36.0/24
172.18.255.4 (metric 21) from 172.18.254.54 (172.18.254.54)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1200
Originator: 172.18.255.4, Cluster list: 172.18.254.54
KP1#
There are two RRs on the network: RR1 (172.18.254.54) and RR2 (172.18.255.254). All PE routers peer with these two RRs.
The VPNv4 prefix 10.1.36.0/24 is advertised by two PE routers; the first is 172.18.254.56 (hostname: SK1) using RD 65001:202, another is 172.18.255.4 (hostname: SK2) using RD 65001:203. This is an Intranet VPN with RT value of 65001:1200.
I understand why KP1 selects the path via SK2 as the best because it matches the BGP best-path selection criteria: "Prefer the path with the lowest IGP metric to the BGP next hop".
I want to load-balance traffic destined to 10.1.36.0/24 across SK1 and SK2. Thus, I modified the config on KP1 as follows:
router bgp 65001
address-family ipv4 vrf V1:TEST
maximum-paths ibgp 2
But still only one best path is selected and installed into the VRF routing tables, as follows:
KP1#sh ip route vrf V1:TEST
Routing Table: V1:TEST
10.0.0.0/24 is subnetted, 6 subnets
B 10.1.36.0 [200/0] via 172.18.255.4, 20:53:01
KP1#sh ip bgp vpnv4 vrf V1:TEST
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10081:204 (default for vrf V1:TEST)
* i10.1.36.0/24 172.18.254.56 0 100 0 ?
*>i 172.18.255.4 0 100 0 ?
KP1 only installs the two paths when I configured the following:
router bgp 65001
address-family ipv4 vrf V1:TEST
maximum-paths ibgp unequal-cost 2 (I can't exactly remember the command. It should be this one.)
Please advise if this is the correct way to install both routes.
Thank you.
B.Rgds,
Lim TS

Hi,
"maximum-path ... unequal-cost" means install two pathes EVEN IF paths have unequal IGP metric. If the metric is identical then the BGP path selection is identical to not configuring "unequal-cost".
This option is used to skip the normal BGP path selection step "closest IGP neighbor" when it comes to decide what to insert into the IP routing table.
So typically you would use "unequal-cost" as for the VPN customer your core network is not interesting (not even visible). So routing decisions based on your core network metrics are (often) not in the customers interest. The customer is usually interested in loading the redundant access lines. This would potentially not be possible because of the SP BGP selection mechanism.
Hope this helps!
Regards, Martin

VPNv4 aggregate address

Hi,
I am trying to reduce the routing table to our PE's which are currently 3750ME's. The 3750ME's only come with 128MB of DRAM so I am keen to reduce the size of the routing table amongst other things. Is there an equivalent to the aggregate-address ipv4 address family (within bgp) command for vpnv4 routes? Essentially I would like to filter, summarise or add default routes facing the PE's where possible. Being able to perform this level of granularity per vrf instance would be ideal.
I had read somewhere that vpn4 automatically summarises between P's and PE's but I wasn't 100% confident on the source of this information.

there's no auto summarization, in fact your P routers shouldn't be running BGP and they shouldn't see any VPNv4 prefixes. There's no aggregate-address command under "address-family vpnv4", you put it under "address-family ipv4 vrf x". In other words, you summarize routes coming in from CE's in a VRF. Use "summary-only" keyword. It will result only in a summary vpnv4 route sent to other PE's

TE and Inter AS material ???

Hi,
I am confuse in TE and Inter AS topics,please any one explain me these and give me easy material if have ????
I found something for Inter AS option A,B,C but was tuff and confusing couldnt clearly understand all
specially where to use "send-lable","next-hop unchanged"!!!!
Bye,

Hi,
"send-label" and "next-hop-unchanged" are not related to TE. They are related to InterAS.
By default, when BGP advertise a VPNv4 prefix with nexthop as self, it will assign a local label and advertise to neighbors. But with any otehr address-family, it needs to be explicitly mentioned. SO when a label needs to be advertised via BGP (for IPv6 Unicast or IPv4 unicast), we need to use "send-label" to instruct BGP to assign a local label.
"next-hop-unchaned" is used in Option C. Inter-As Option C is something used in operators where both AS opeators agrees to exchange their internal address details (can be limited to just the edge PE node loopback address). This is commonly seen in merge scenarios.
In such scenarios, we establish a VPNv4 session between RRs on each AS and mark it as next-hop-unexchanged. For example, assume the below simple scenario,
(PE1-AS1)-----(RR-AS1)-----(Edge-AS1)--------(Edge-AS2)------(RR-AS2)------(PE1-AS2)
Assume x-AS1 are in AS1 and x-AS2 are in AS2.
When Option C is used, PE1-AS1 address will be advertised to RR-AS1 adn Edge-AS1 via IGP used in AS1 (say IGP1) and PE1-AS2 address will be advertised to RR-AS2 and Edge-AS2 via IGP used in AS2 (say IGP2).
Now edge PE node details needs to be exchanged between AS. To be more specific, PE1-AS1 should be advertised to AS2 and PE1-AS2 to be advertised by AS1. This is simply done by BGP unicast session between Edge-AS1 and Edge-AS2 (this helps avoid anotehr instance of IGP between edge nodes). As mentioned by default only VPNv4 session assign and adveritise label while the session between Edge-AS1 and Edge-AS2 is IPv4 Unicast. So we need to explicitly mention "send-label".
All VPNv4 prefixes from PE nodes will be advertised to RR and in turn will be advertised to RR-AS2. eBGP will set the nexthop as self before advertiing. To overrule this, we use "nexthop-unchanged".
When VPN1 prefix is adverised by PE1-AS1 to RR-AS1, it set nexthop as self. RR-AS1 while advertising to RR-AS2 will NOT change teh nexthop (due to nexthop-unchanged). RR-AS2 will inturn advertise to PE1-AS2 without changing the nexthop (follows traditional iBGP behaviour).
PE1-AS2 will have in its local table the label advertised by PE1-AS1 and push it as bottom label. On top of it, it include the label to reach PE1-AS1 whcih was advertised by Edge-AS2 and middle label and top of it the IGP label to reach Edge-AS2.
HTH,
Nagendra

Closed port for torrent with no iptables.rules

I have a home system with internet connection over a router. Firewall in the router seems to be disabled. I had installed guarddog and selected all the protocols that I need. There is no iptables in deamons line of rc.conf nor there is any iptables.rules files. There are 2 files in /etc/iptables, empty.rules and simple_firewall.rules. So, I wonder if any firewall is working at all in my system since guarddog is a frontend to iptables (i guess) and also is there any need for firewall since almost all the ports are closed.
Secondly, the main issue. I was using ktorrent and it was working fine until a few days ago. Now, bittorrent is not working. its not connecting at all. I tried deluge from community repo and tested the ports with http://www.deluge-torrent.org/test-port.php?port=6881 and it gave me this result:
TCP port 6881 closed on 121.247.200.189
UDP port 6881 open on 121.247.200.189
121.247.200.189 seems to be the ip of my isp as I got a dynamic one.
I am able to reach surf net but not able to download using bitorrent, however, both is possible in windows.
Taking clue from forum, i did nmap.
nmap on my router
[shantanu@bluehead ~]$ nmap 192.168.1.1
Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-25 20:49 IST
Interesting ports on 192.168.1.1:
Not shown: 1679 filtered ports
PORT STATE SERVICE
21/tcp open ftp
23/tcp open telnet
53/tcp closed domain
80/tcp open http
443/tcp closed https
554/tcp closed rtsp
1755/tcp closed wms
2401/tcp closed cvspserver
5000/tcp closed UPnP
5001/tcp closed commplex-link
5050/tcp closed mmcc
6881/tcp closed bittorent-tracker
6969/tcp closed acmsoda
7070/tcp closed realserver
8000/tcp closed http-alt
8080/tcp closed http-proxy
8888/tcp closed sun-answerbook
11371/tcp closed pksd
Nmap finished: 1 IP address (1 host up) scanned in 27.653 seconds
nmap on my ip
[shantanu@bluehead ~]$ nmap 192.168.1.5
Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-25 20:48 IST
Interesting ports on 192.168.1.5:
Not shown: 1696 closed ports
PORT STATE SERVICE
6000/tcp open X11
Nmap finished: 1 IP address (1 host up) scanned in 0.519 seconds
nmap on isp's ip displayed above.
[shantanu@bluehead ~]$ nmap 121.247.200.189
Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-25 20:50 IST
Interesting ports on 121.247.200.189.bang-dynamic-bb.vsnl.net.in (121.247.200.189):
Not shown: 1679 filtered ports
PORT STATE SERVICE
21/tcp open ftp
23/tcp open telnet
53/tcp closed domain
80/tcp open http
443/tcp closed https
554/tcp closed rtsp
1755/tcp closed wms
2401/tcp closed cvspserver
5000/tcp closed UPnP
5001/tcp closed commplex-link
5050/tcp closed mmcc
6881/tcp closed bittorent-tracker
6969/tcp closed acmsoda
7070/tcp closed realserver
8000/tcp closed http-alt
8080/tcp closed http-proxy
8888/tcp closed sun-answerbook
11371/tcp closed pksd
Nmap finished: 1 IP address (1 host up) scanned in 30.573 seconds
Everywhere the bittorrent port seems to be closed. [b]How do I open this port?.[b/]
Last edited by ravisghosh (2007-06-25 21:09:55)

@madeye, first of all I used utorrent in Then I tried as you [shantanu@bluehead Chain INPUT (policy DROP)
target prot opt source ACCEPT 0 -- anywhere ACCEPT udp -- anywhere ACCEPT 0 -- 192.168.1.5 logaborted tcp -- anywhere ACCEPT 0 -- anywhere ACCEPT icmp -- anywhere ACCEPT icmp -- anywhere ACCEPT icmp -- anywhere nicfilt 0 -- anywhere srcfilt 0 -- anywhere Chain FORWARD (policy DROP)
target prot opt source ACCEPT 0 -- anywhere ACCEPT icmp -- anywhere ACCEPT icmp -- anywhere ACCEPT icmp -- anywhere srcfilt 0 -- anywhere Chain OUTPUT (policy DROP)
target prot opt source ACCEPT 0 -- anywhere ACCEPT udp -- anywhere ACCEPT 0 -- anywhere ACCEPT icmp -- anywhere ACCEPT icmp -- anywhere ACCEPT icmp -- anywhere s1 0 -- anywhere Chain f0to1 (3 references)
target prot opt source ACCEPT udp -- anywhere ACCEPT icmp -- anywhere ACCEPT tcp -- anywhere logdrop 0 -- anywhere Chain f1to0 (1 references)
target prot opt source ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT udp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT udp -- anywhere ACCEPT tcp -- anywhere ACCEPT udp -- anywhere ACCEPT icmp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere ACCEPT tcp -- anywhere logdrop 0 -- anywhere Chain logaborted (1 references)
target prot opt source logaborted2 0 -- anywhere LOG 0 -- anywhere Chain logaborted2 (1 references)
target prot opt source LOG 0 -- anywhere ACCEPT 0 -- anywhere Chain logdrop (4 references)
target prot opt source logdrop2 0 -- anywhere LOG 0 -- anywhere DROP 0 -- anywhere Chain logdrop2 (1 references)
target prot opt source LOG 0 -- anywhere DROP 0 -- anywhere Chain logreject (0 references)
target prot opt source logreject2 0 -- anywhere LOG 0 -- anywhere REJECT tcp -- anywhere REJECT udp -- anywhere DROP 0 -- anywhere Chain logreject2 (1 references)
target prot opt source LOG 0 -- anywhere REJECT tcp -- anywhere REJECT udp -- anywhere DROP 0 -- anywhere Chain nicfilt (1 references)
target prot opt source RETURN 0 -- anywhere RETURN 0 -- anywhere RETURN 0 -- anywhere logdrop 0 -- anywhere Chain s0 (1 references)
target prot opt source f0to1 0 -- anywhere f0to1 0 -- anywhere f0to1 0 -- anywhere logdrop 0 -- anywhere Chain s1 (1 references)
target prot opt source f1to0 0 -- anywhere Chain srcfilt (2 references)
target prot opt source s0 0 -- anywhere That means iptables I removed guarding Removed iptables and Last edited by thanks a lot for such elaborate help.
windows and u r very much right that it uses UPnP. In deluge (bt client on arch), UPnP was there but disabled (shaded). Hence, I tried running utorrent using wine and it gave a error message "Unable to map UPnP port' and is not able to connect. So, UPnP is not working in my box.
suggested "iptables -L" and it gave me the following results.
~]$ sudo iptables -L
destination
anywhere
anywhere udp spt:bootps dpt:bootpc
192.168.1.255
anywhere state RELATED,ESTABLISHED tcp flags:RST/RST
anywhere state RELATED,ESTABLISHED
anywhere icmp destination-unreachable
anywhere icmp time-exceeded
anywhere icmp parameter-problem
anywhere
anywhere
destination
anywhere state RELATED,ESTABLISHED
anywhere icmp destination-unreachable
anywhere icmp time-exceeded
anywhere icmp parameter-problem
anywhere
destination
anywhere
anywhere udp spt:bootpc dpt:bootps
anywhere state RELATED,ESTABLISHED
anywhere icmp destination-unreachable
anywhere icmp time-exceeded
anywhere icmp parameter-problem
anywhere
destination
anywhere udp dpts:6970:7170
anywhere icmp echo-reply
anywhere tcp spts:1024:65535 dpts:6881:6889 state NEW
anywhere
destination
anywhere tcp spts:1024:5999 dpt:6969 state NEW
anywhere tcp spts:1024:5999 dpt:http state NEW
anywhere tcp spts:1024:5999 dpt:http-alt state NEW
anywhere tcp spts:1024:5999 dpt:8008 state NEW
anywhere tcp spts:1024:5999 dpt:8000 state NEW
anywhere tcp spts:1024:5999 dpt:8888 state NEW
anywhere tcp spts:1024:5999 dpt:ftp state NEW
anywhere tcp spts:1024:5999 dpt:https state NEW
anywhere tcp dpt:rtsp state NEW
anywhere tcp dpt:7070 state NEW
anywhere tcp spts:1024:5999 dpt:cvspserver state NEW
anywhere tcp dpt:1755 state NEW
anywhere udp dpt:1755
anywhere tcp spts:1024:5999 dpt:11371 state NEW
anywhere tcp spts:1024:5999 dpt:5050 state NEW
anywhere tcp spts:1024:5999 dpt:telnet state NEW
anywhere tcp spts:1024:5999 dpts:5000:5001 state NEW
anywhere udp spts:1024:5999 dpt:5000
anywhere tcp dpt:domain state NEW
anywhere udp dpt:domain
anywhere icmp echo-request
anywhere tcp spts:1024:5999 dpt:5222 state NEW
anywhere tcp spts:1024:5999 dpt:5223 state NEW
anywhere tcp spts:1024:5999 dpts:6881:6889 state NEW
anywhere
destination
anywhere limit: avg 1/sec burst 10
anywhere limit: avg 2/min burst 1 LOG level warning prefix `LIMITED '
destination
anywhere LOG level warning tcp-sequence tcp-options ip-options prefix `ABORTED '
anywhere state RELATED,ESTABLISHED
destination
anywhere limit: avg 1/sec burst 10
anywhere limit: avg 2/min burst 1 LOG level warning prefix `LIMITED '
anywhere
destination
anywhere LOG level warning tcp-sequence tcp-options ip-options prefix `DROPPED '
anywhere
destination
anywhere limit: avg 1/sec burst 10
anywhere limit: avg 2/min burst 1 LOG level warning prefix `LIMITED '
anywhere reject-with tcp-reset
anywhere reject-with icmp-port-unreachable
anywhere
destination
anywhere LOG level warning tcp-sequence tcp-options ip-options prefix `REJECTED '
anywhere reject-with tcp-reset
anywhere reject-with icmp-port-unreachable
anywhere
destination
anywhere
anywhere
anywhere
anywhere
destination
192.168.1.5
192.168.1.255
bluehead.localdomain
anywhere
destination
anywhere
destination
anywhere
is not disabled and that firewall rules are setup by guarddog.
using "pacman -Rns guarddog" and rebooted. Still get the same results with utorrent and "iptables -L" and also the port test shows tcp 6881 is still closed.
now bt clients seems to be able to connect and it works; however, port test still shows tcp 6881 closed.
ravisghosh (2007-06-27 16:51:12)

Path Selection for Routes Across MPLS Network

Customer hub site has two CE routers with two links connected to two seperate PE routers in the Carrier's MPLS network. At the customer's remote site one CE router on a single link is connected to PE router in MPLS network.
How can I configure the CE routers at the hub site to advertised the same network across the MPLS network to the CE router at the remote site? Also, how can I configure the CE router at the remote site to select on of the router as the primary and the other as secondary? Can I use local-preference on the CE router at the remote site to selected on path over the other.
I'm not sure if this makes any sense. Any help will be appreciated. Thanks

Even with multiple RDs for VRFs belonging to the same VPN, you still need IBGP multipath, correct? Multiple RDs is just to get around the RR restriction.
Also, you posted this message a while back:
"If you have many VPN customers all using the same addresses (most likely rfc1918), the fact that they have different RDs and that the PE prepends the RD to the prefixes exchanged between PEs will make the same prefixes different in the MPLS VPN core
cust1 advertises 192.168.1.0/24 with RD 1:1 therefore
VPNv4 prefix is 1:1:192.168.1.0
cust2 advertises 192.168.1.0/24 with RD 1:2 therefore
VPNv4 prefix is 1:2:192.168.1.0"
My test lab does not support the IBGP multipath command, and thus even with different RDs, it still only installs one best path.
I understand that RD = make unique VPNv4 routes in SP space, and that RT = what to import into the VRF. However, I am having a hard time visualizing the scenario with mutiple RDs for the same VPN for load balancing purposes. I am trying to understand the logic behind it.
Per your example, if both 1:1 and 1:2 are received by the remote PE, assuming IBGP multipath is enabled, why would the remote PE load balance between the two links? Why would it assume that the hub subnets are reachable via two different PEs, and that it's not two different, isolated VPNs altogether?
Is it b/c you imported both 1:1 and 1:2 into a VRF at the remote PE?

Qu. about Deploying MPLS on Sup-2T VSS

Hi,
We are planning to deploy a new campus network comprising of a Core (Nexus 7K), 2 client aggregation modules (Catalyst 6500 /w Sup-2T VSS) and a single Data Centre module (Nexus 7k).
MPLS is being deployed to provide segregation of services. Now in a traditional MPLS campus deployment, we would have a pair of Core switches performing the P, or LSR function, and the aggregation devices each performing the role of the PE, or LER. Load balancing would be achieved by using different RDs for each PE.
In the world of VSS however we obviously change this model, with a pair of PE switches appearing as "one" to the Core or P node. In this scenario we would just use the one RD and use a Layer-3 Port channel from the VSS node to each P node to provide the resilience.
I have read a few posts about this type of deployment and the general consensus seems to be sticking with a non VSS deployment, mainly for simplicity and the ability to have greater visibility into what is going on under the hood.
Has anyone deployed MPLS using VSS ? Does anyone have any views or recommendations as to why one would choose one particular method over the other ?
I think my personal preference will be to go non VSS, then at least we have the same configuration across all aggregation modules (Nexus / Catalyst).
Any help would be greatly appreciated.
Chris.

Hi Alessio,
The underlying design will be a traditional Access - Distribution - Core - Distribution - Access model. With a hierarchical OSPF backbone design, i.e. area 0 for Core and backbone links, with the distribution switches configured as ASBRs. We are then planning to configure an iBGP overlay on this, and then MPLS VPN using MP-BGP to provide network segregation. This is something I have done before on a Catalyst / Nexus backbone and works well, I have just never used VSS to accomplish this. So I just wanted to understand if there are any best practice recommendations for VSS which may not be in the path isolation design doc.
For example, in a traditional non VSS deployment, load balancing is typical configured by configuring different RD's across a pair of PEs with the same RT which route a common subnet. Different VPNv4 prefixes are then advertised to the Core / P nodes for the same IPv4 subnets. In a VSS deployment, this isn't possible, because obviously there is only a single control plane, so load balancing is achieved by the hash algorythm used on the Layer 3 port channels connecting the PE to the Core - are there any other considerations such as this which I need to be aware of ?
I hope this helps explain the design a little better.
Chris.

Cat6500 + SUP-2T & MPLS Features

Hello all,
I have done quite a bit of research on the Catalyst 6500 and the SUP-2T. Historically the 7600/6500 series has had support issues and stringent requirements on certain hardware modules in order to support L2VPN/L3VPN (ES+ Card, SIP cards etc). Essentially this kept the Cat6500 as more of an enterprise switch.
With the release of the SUP-2T though, the box has been brought up to scale. We now have support for 1 million+ routes and supposedly support across the board for MPLS features regardless of line card type. With this being said, what we would like to do is move towards the 6500+SUP-2T as an aggregation-access box for our fiber customers. We have a need to support full VPLS featureset on 100meg fiber customer facing interfaces. We have accomplished this in the past by using ME3600s but would like to get to something a bit more scalable. Thoughts are to use a redundant SUP-2T Cat6500 with WS-X6148-FE-SFP cards. My concerns are the following:
1. Will all MPLS features really be available on this card? Looking to attach these ports as part of L2VPN VPLS and to perform port-based and VLAN-based xconnects (EVC/EFP configurations).
2. For those that have experience with both Cat6500 and ME3600/3800, are these two comparable from a configuration standpoint? We would be migrating from daisy chained ME3800s to this chassis if we went with it. I want to make sure that the configuration migration would be very straightforward and future provisioning would be similar to that of ME series switches.

Hi Alessio,
The underlying design will be a traditional Access - Distribution - Core - Distribution - Access model. With a hierarchical OSPF backbone design, i.e. area 0 for Core and backbone links, with the distribution switches configured as ASBRs. We are then planning to configure an iBGP overlay on this, and then MPLS VPN using MP-BGP to provide network segregation. This is something I have done before on a Catalyst / Nexus backbone and works well, I have just never used VSS to accomplish this. So I just wanted to understand if there are any best practice recommendations for VSS which may not be in the path isolation design doc.
For example, in a traditional non VSS deployment, load balancing is typical configured by configuring different RD's across a pair of PEs with the same RT which route a common subnet. Different VPNv4 prefixes are then advertised to the Core / P nodes for the same IPv4 subnets. In a VSS deployment, this isn't possible, because obviously there is only a single control plane, so load balancing is achieved by the hash algorythm used on the Layer 3 port channels connecting the PE to the Core - are there any other considerations such as this which I need to be aware of ?
I hope this helps explain the design a little better.
Chris.

Bgp multipath

Why does a bgp router (configured with multipath) advertise only one best path to its peers, even though it knows multiple paths to reach a destination and also installs them in its routing table? Can somebody help me understand this?

In a MPLS VPN scenario if a customer is multihomed to two PEs, load sharing can be achieved by using different Route Distinguisher (RD) for that VRF on each PE. The VPNv4 prefix is made up of 64 bit RD and 32 bit IPv4 address. This makes the prefix unique. If the RD is the same on both PEs then there can only be one best path because it would be the same prefix.
Like Peter described there are newer features like add path that enables BGP to send multiple paths to be used. Peter also described that BGP was designed to be a stable and higly scaling protocol. Announcing more than one path will lead to increased usage of RAM, RIB and FIB so these are factors that must be considered before enabling such features.
There is also a feature called diverse path that can be used on Route Reflectors (RR). Description from Cisco:
BGP Diverse Path Using a Diverse-Path Route Reflector
The BGP Diverse Path Using a Diverse-Path Route Reflector feature overcomes the lack of path diversity in an AS containing RRs. This feature is meant to provide path diversity within an AS, within a single cluster only. That is, an RR is allowed to advertise the diverse path to its client peers only.
For each RR in the AS, a shadow RR is added to distribute the second best path, also known as the diverse path. Figure 2 shows the shadow RR for RR2. The shadow RR improves path diversity because PE3 can now learn both P1 (from RR1/RR2) and learn P2 from the shadow RR
Most of these features are designed for RR scenarios. In an iBGP full mesh, optimal forwarding is easier to achieve.
Daniel Dib
CCIE #37149
Please rate helpful posts.

Deafult route propagation in MPLS

Hi,
(Default Route <------) CE1------PE1---P----PE2---CE2(--->Default Route)
In above, Let CE1 and CE2 have default static route monitored with IP SLA. CE and PE ospf running OSPF. The target is, if IPSLA on CE1 becomes invalid, the static default route shuld disappear from CE1 and it should get default route via CE2 and so on viceversa for IPSLA of CE2 is down...
I tried above scenario on GNS3 it worked but when i tried on real environment, i always needed to clear OSPF process of PE. I have IOS-XR with v3.9.2. If is do not clear OSPF process, i will still see PE pointing default route towards CE ( where static default route is invalid) but in CE, i see default route towards PE .
I guess it is bug of IOS-XR V 3.9.2.
CSCtq86051 BGP vpnv4 prefixes not imported into VRF table under special cases
Can anybody plz suggest?

Could you please share your configurations ?
I'm not sure if you are hitting this bug.

ASR9000 VPNv4 prefix limits

Similar Messages

Maybe you are looking for